PostgreSQL tuning tools: calculator, dashboard, or advisor?

Three kinds of PostgreSQL tuning tools

PostgreSQL tuning tools differ by the question they answer, not by the length of their feature lists. There are three questions. A calculator answers what a sane start is for this hardware. A dashboard answers what happened on the server. An advisor answers what to change, how sure it is, and what proves it.

Each kind has a blind spot. A calculator never sees the workload. A dashboard shows the workload but leaves the decision to a person. An advisor decides only within the checks it has, so it must say which checks those are.

One product can sit in two columns. Percona Monitoring and Management is a dashboard and also ships advisors. Datadog Database Monitoring adds a Recommendations page to its query views. Judge the feature you will use, not the logo.

Calculators: PGTune and PGConfig

A configuration calculator gives a sane first configuration and nothing more. It is the right tool on the first day of a new server, before there is any workload to measure.

PGTune describes itself as a tool to “calculate configuration for PostgreSQL based on the maximum performance for a given hardware configuration.” It asks for the PostgreSQL version, the operating system, the type of application, total memory, the number of CPUs, the number of connections, the type of storage, and the data size relative to RAM. Its version list runs from 10 to 19, so it accepts PostgreSQL 18. The README on GitHub sums it up as “Tuning PostgreSQL config by your hardware.”

PGConfig “recommends PostgreSQL configuration values from the facts about a server”: memory, CPUs, version, workload, and storage. It writes the result as a postgresql.conf fragment, ALTER SYSTEM statements, StackGres, or JSON. It runs as a web app, a command-line tool, a REST API, and an MCP endpoint, and through MCP each value comes with the reason for it.

The PostgreSQL documentation itself contains calculator-style advice. For shared_buffers it says that on a dedicated server with 1 GB or more of RAM, “a reasonable starting value for shared_buffers is 25% of the memory in your system,” and that more than 40% of RAM is unlikely to work better. That is a start, written for every server at once. Source: PostgreSQL 18, resource consumption.

What a calculator cannot know

The settings that matter most depend on measurements that no input form asks for. The table lists what an advisor reads for three of them. The middle column comes from the Guardioz checks reference, which publishes the inputs of every settings check. The right column comes from the PostgreSQL 18 documentation.

Take max_wal_size. Its right value depends on how fast the server writes WAL and how often a checkpoint starts because WAL filled up instead of because the timer ran out. A form with RAM and CPU count cannot hold that number. Guardioz explains the setting in depth in max_wal_size, explained.

Use a calculator once. Then measure the server and move to a tool that reads what it measures.

Dashboards: pgwatch, Percona PMM, Datadog, cloud insights

A dashboard answers what happened. It records metrics over time and draws them. It does not choose the change. A person who knows which graph matters still has to read it, and on a team without a DBA that person is missing.

• pgwatch, by Cybertec, calls itself “a scalable and flexible PostgreSQL-specific monitoring solution.” It collects metrics on query performance, index usage, disk I/O, CPU and memory, and locks and waits, plus custom SQL metrics. It stores them in a sink such as PostgreSQL, TimescaleDB, Prometheus, or JSON files, and shows them in Grafana dashboards.
• Percona Monitoring and Management is, in Percona's words, “an open source database observability, monitoring, and management tool” for MySQL, PostgreSQL, MongoDB, and the servers they run on. For PostgreSQL it captures connections, tuples, tuple activity, and vacuum monitoring, with deeper query insight through pg_stat_monitor.
• Datadog Database Monitoring provides “deep visibility into databases across all of your hosts” with query metrics for normalized queries, query samples, and explain plans. Its Recommendations page “highlights problems and optimization opportunities.”
• Amazon RDS Database Insights is the managed-service view on RDS. AWS says RDS enables it by default in Advanced mode, “which includes lock diagnostics, execution plan capture, and fleet-level monitoring.”

Dashboards are the right tool when the team wants history, alerting, and query-level views. Most of them center on queries. When the problem is a slow query, that is exactly what you need.

Advisors: what they read and what they output

An advisor names the change and shows the evidence for it. Advisors differ in what they read, how much they cover, and whether they act on their own. The table describes each one in the words of its own documentation, checked on November 4, 2026.

Three patterns stand out. Query advisors such as the pganalyze Index Advisor read pg_stat_statements and focus on indexes. Automatic tuners such as DBtune and Azure intelligent tuning change parameters themselves. Recommendation-only advisors such as Guardioz hand you the statement and leave the change to you.

If you are looking for OtterTune, its own site now reads “OtterTune is Dead (2020-2024)” and describes it as “a database tuning service start-up out of Carnegie Mellon University.”

The evidence test: five questions for any tuning tool

Ask any PostgreSQL tuning tool five questions before you trust a single recommendation. They work for calculators, dashboards, advisors, and AI assistants alike.

1. E1Does it show the measurement behind each recommendation? A recommended value with no evidence is a calculator result with a nicer screen. Ask to see the counter or the size that produced it.
2. E2Does it say how sure it is? Confidence should rise as the tool measures more of your workload. Guardioz, for example, gives a confidence percentage that starts low after the install and rises as history accumulates.
3. E3Does it say when to leave a setting alone? A tool that never says “leave it” gives you no way to tell a measured value from a rule of thumb. A good advisor lists the checks that passed, so you can see what it verified. The Guardioz post max_wal_size, explained covers when to leave that setting alone.
4. E4Does it flag restarts and disk limits? Some settings take effect only after a restart. The PostgreSQL docs state that shared_buffers “can only be set at server start.” A larger max_wal_size needs free disk. The advisor should say both before you run anything.
5. E5Does it list what it does not check? Every tool has a boundary. A tool that does not publish it leaves you to assume coverage you do not have.

The same five questions apply when you ask ChatGPT or Claude to tune postgresql.conf. Part 3 shows what an assistant cannot see from a prompt.

Which PostgreSQL tuning tool fits your setup

Match the tool to your setup and to the question you have today. Most teams need two kinds over the life of a server: a calculator on the first day, then a dashboard or an advisor.

Where Guardioz fits, and where it does not

Guardioz is an advisor for self-managed PostgreSQL 18. It fits teams that run PostgreSQL themselves and have no database administrator. The scope below comes from the Guardioz documentation, checked on November 4, 2026.

What it does

• An agent runs on the database server, connects over the local Unix socket, and reads settings, system catalogs, and statistics views with a role that has pg_monitor. Its sessions are read-only. It never reads the rows of your tables. Source: Requirements.
• It collects about once an hour, sends the data out over HTTPS, and opens no inbound port.
• It runs ten check groups: reliability settings, autovacuum, monitoring visibility, eight performance settings, invalid indexes, duplicate indexes, tables behind on cleanup, replication slots, transaction log archiving, and open transactions. Part 1 walks through all ten in the order they can hurt you.
• Each settings finding gives the current value, the recommended value, and an ALTER SYSTEM SET statement followed by SELECT pg_reload_conf();. For shared_buffers, work_mem, and max_wal_size it shows the measured data behind the value. When the data disk has no safe room for a larger max_wal_size, it says to add disk space first and gives no statement.

What it does not do

• It changes nothing on your server. You run every statement.
• It is not real-time monitoring and not an uptime monitor. It draws no second-by-second graphs.
• It does not analyze slow queries or query plans today. Query analysis is planned.
• It does not support managed services such as Amazon RDS or Azure Database for PostgreSQL, PostgreSQL run by a Kubernetes operator, replicas, or versions other than PostgreSQL 18.
• It does not check transaction ID wraparound, locks, unused or missing indexes, bloat, or whether a backup can be restored. The full list is on the checks page.

Guardioz is in beta, early, and without an SLA. The Free plan covers one user and up to three servers, with no card.

Key facts at a glance

Values and identifiers from each tool's own page, the PostgreSQL 18 documentation, and the Guardioz documentation, checked on November 4, 2026.

Frequently asked questions

What is the best PostgreSQL tuning tool?

The best tool is the one that answers your question. For a new server with no workload, a calculator such as PGTune gives a sane start. For history and graphs, a dashboard such as pgwatch or Percona Monitoring and Management fits. For what to change on a running server, use an advisor that shows the measurement behind each change. Test any tool with five questions: does it show the evidence, say how sure it is, say when to leave a setting alone, flag restarts, and list what it does not check.

Is PGTune accurate for PostgreSQL 18?

PGTune accepts PostgreSQL 18 as an input and computes settings from hardware facts: memory, CPUs, connections, storage, and workload type. The formula is not the problem. PGTune never sees your workload, so settings that depend on it, such as max_wal_size and work_mem, stay a starting point until you measure the server.

What replaced OtterTune?

OtterTune's own site says the company is dead and gives its years as 2020 to 2024. No single product replaced it. DBtune tests PostgreSQL parameter configurations against the workload and can apply the best one. Azure Database for PostgreSQL flexible server tunes four write parameters on its own. Advisors such as Guardioz recommend changes that you apply yourself.

Are there free PostgreSQL tuning tools?

Yes. PGTune and PGConfig are web calculators with public source code on GitHub. Percona describes Percona Monitoring and Management as open source. Postgres.AI offers a free health check. Guardioz has a Free plan for one user and up to three servers, with no card required.

Can a PostgreSQL tuning tool apply changes automatically?

Some can. DBtune can apply the best-performing settings automatically or after your approval. Intelligent tuning in Azure Database for PostgreSQL flexible server adjusts bgwriter_delay, checkpoint_completion_target, max_wal_size, and min_wal_size by itself. pganalyze states that its index recommendations require a human review by a database operator. Guardioz changes nothing on your server. You run every statement.

Do I need pg_stat_statements to tune PostgreSQL?

You need it for query tuning. Query-level tools such as the pganalyze Index Advisor read the query workload from pg_stat_statements. The module must be listed in shared_preload_libraries, so adding it needs a server restart. Settings, index health, and cleanup checks do not need it. Guardioz does not read pg_stat_statements.

What is the difference between PostgreSQL monitoring and tuning?

Monitoring records what happened on the server. Tuning decides what to change. A monitoring tool becomes a tuning tool only when it names the change, shows the measurement behind it, and says how sure it is.

Does Guardioz support Amazon RDS or Azure Database for PostgreSQL?

No. Guardioz supports PostgreSQL 18 on a server that you run yourself, on Linux with systemd or on FreeBSD, and it checks primary servers only. Managed services such as Amazon RDS and Azure Database for PostgreSQL, and PostgreSQL run by a Kubernetes operator, are not supported. Write to contact@guardioz.com with your version and platform.

Sources

Tool pages, checked on November 4, 2026.

• PGTune
• PGTune on GitHub
• PGConfig on GitHub
• pgwatch documentation
• pgwatch on GitHub
• Percona Monitoring and Management
• Datadog Database Monitoring
• Amazon RDS: Overview of Database Insights
• pganalyze Indexing Engine
• pganalyze VACUUM Advisor
• Postgres.AI free Postgres health check
• DBtune
• Postgres MCP Pro on GitHub
• Microsoft Learn: Intelligent tuning in Azure Database for PostgreSQL flexible server
• OtterTune

PostgreSQL 18 documentation, checked on November 4, 2026.

• Resource consumption: shared_buffers, work_mem
• Write-ahead log: max_wal_size, checkpoint_warning
• pg_stat_statements

Guardioz, checked on November 4, 2026.

• What Guardioz checks
• How Guardioz works
• Requirements
• What the agent reads and sends
• Pricing
• max_wal_size, explained (Guardioz blog)