Interview with Guardioz
Find out more about our sponsor Guardioz
Any views or opinions represented or expressed in this interview belong solely to the interviewee and do not necessarily represent those of the PGConf Poland 2026 organization, PostgreSQL Europe, or the wider PostgreSQL community, unless explicitly stated.
How does PostgreSQL fit into your products or services, and why did you choose it?
Guardioz is built only for PostgreSQL. It gives PostgreSQL performance guidance to teams that run PostgreSQL in production without a dedicated DBA. Guardioz turns signals from PostgreSQL into ranked findings, each with the reasoning behind it and a safe next step. Today it checks five areas: server settings, indexes, replication, autovacuum and WAL archiving. It works with PostgreSQL 18 on servers you run yourself.
An agent runs on the database server. It only reads, runs a fixed set of queries that we send you for review, connects to the database locally and opens the outbound connection to Guardioz itself. You do not open an inbound port or expose the database port. Each recommendation shows the measured data from your server that it is based on, and says if the change needs a restart.
Why PostgreSQL? It is the database we have worked with for years: tuning it, migrating to it and fixing it in production. PostgreSQL tells you a lot about itself through its statistics views, but reading them well takes time and experience. Guardioz is for the engineer who owns a production PostgreSQL database as one part of a bigger job.
What misconceptions about PostgreSQL do you encounter most often?
Three that we meet often. First: that autovacuum cleans the table that needs it most, first. In PostgreSQL 18 and earlier, it does not. Inside one database, a worker takes the tables that crossed their threshold in their physical order in pg_class, not by urgency. A table far over its threshold can wait behind tables that barely qualify. PostgreSQL 19 adds a scoring system that changes this order.
Second: that PostgreSQL adjusts its settings to the hardware. It does not. By default, shared_buffers is typically 128MB and work_mem is 4MB, on a small virtual machine and on a server with hundreds of gigabytes of memory. The defaults are a safe starting point for unknown hardware, not a mistake. Before you move to a bigger server, check if the current one is configured for its size.
Third: that no archiving errors means your backups are safe. PostgreSQL counts the archive command as successful when it returns exit status zero, and it cannot see what happened to the file after that. A command that returns zero without copying anything looks healthy in pg_stat_archiver. To know that your archive works, restore from it in a test.
What are your company's goals for PGConf.PL 2026?
We come to Gdańsk to listen. We want to meet people who run PostgreSQL in production, especially in teams without a dedicated DBA. What takes most of your time? What makes you unsure before you change a setting? What would you like a tool to explain better?
What we hear changes what we build. Query analysis is on the Guardioz roadmap because people who run PostgreSQL asked us for it, and it will come to Guardioz. Our customers have a real say in what we build next, during the beta and after it.
Guardioz is in beta. You can sign up, and the product is early - we say so up front. Always free for one user. Talk to us between sessions, come to "Huge Pages for PostgreSQL, Explained", the talk by Alicja Kucharczyk from Guardioz, or listen to our five-minute lightning talk.
