Can ChatGPT tune PostgreSQL? What an assistant cannot see

What an assistant sees when you ask it to tune postgresql.conf

An assistant sees the prompt and nothing else. A typical tuning prompt says how much RAM the server has, how many processors, and what kind of workload it runs, for example "a web app". Every value that comes back is built from those three facts plus general knowledge of PostgreSQL.

A PostgreSQL setting can depend on four kinds of facts:

1. Hardware: total RAM and the processor count. A typical prompt carries both.
2. Configuration: the values PostgreSQL runs with, in the pg_settings view. A prompt carries them only if you paste them.
3. Server sizes: the size of each database, the largest table and index, and the free space on the data disk. A typical prompt carries none of them.
4. Workload counters over time: how often the cache evicts blocks, how much data queries write to temporary files, how much WAL the server generates, and how many checkpoints were requested instead of scheduled. These live in the cumulative statistics views. No prompt carries them by default.

The fourth kind does not fit in one paste. The cumulative statistics views count from the last reset. pg_stat_io, pg_stat_database, pg_stat_wal, and pg_stat_checkpointer record its time in a stats_reset column. One reading gives totals over that whole period, an average that hides this week's peaks. A rate needs two readings and the time between them. The Guardioz documentation states the same for its own checks: max_wal_size and a raise of work_mem come from measurements taken between two collections.

Eight PostgreSQL settings and the facts each one needs

Half of the eight performance settings that Guardioz judges need facts that no hardware prompt carries. The table lists, for each setting, the inputs the Guardioz performance tuning check uses, where PostgreSQL 18 keeps each input, and what a prompt with RAM, CPU, and workload type contains.

Read the table in three groups. S4 and S5 follow from hardware and the current value, so any prompt with RAM and CPU reaches them. S7 and S8 follow from configuration alone, so a pasted pg_settings covers them. S1, S2, S3, and S6 need sizes or counters from the running server. Guardioz sizes three of them from measured workload: shared_buffers, a raise of work_mem, and max_wal_size. For those three, its documentation says the confidence percentage starts low and rises as the agent collects more history.

Four settings an assistant should never change on its own

Four settings trade durability or cleanup for speed, and a person decides each one. Keep them out of any change list an assistant proposes. Part 1 of this series puts the first one at the top of its ten checks for this reason.

1. N1fsync. The PostgreSQL 18 documentation says that turning it off “can result in unrecoverable data corruption in the event of a power failure or system crash.” It adds: “High quality hardware alone is not a sufficient justification for turning off fsync.”
2. N2full_page_writes. Turning it off “might lead to either unrecoverable data corruption, or silent data corruption, after a system failure,” per the same page.
3. N3synchronous_commit. Off does not corrupt the database, but “some recent allegedly-committed transactions” can be lost in a crash. Whether a payment or an order may vanish after the client saw success is a business decision.
4. N4autovacuum. The documentation calls it “an optional but highly recommended feature” and says it needs track_counts to work. Guardioz reports both settings as Critical when either one is off.

Guardioz treats fsync the same way: its Reliability settings check raises a Critical finding when fsync is not on.

Six rules for using an AI assistant on PostgreSQL

An assistant is useful on PostgreSQL when it works from measurements and a person keeps the decisions. These six rules make that the default.

1. R1Give it measurements, not only hardware. Paste the counters each setting depends on, from the table above, with two readings and the time between them. An assistant connected through an MCP server can read statistics views directly. The Postgres MCP Pro README describes a restricted mode that “Limits operations to read-only transactions” and calls it suitable for production environments.
2. R2Ask for the evidence behind each value. A value without the counter that justifies it is a rule of thumb. Ask which number from your server moved the recommendation, and what number would change it.
3. R3Ask what each change needs to take effect. shared_buffers and max_worker_processes “can only be set at server start,” per the PostgreSQL 18 documentation. After a change, the pending_restart column of pg_settings shows which values wait for a restart.
4. R4Never paste statement text with customer data. pg_stat_activity shows the statement each session runs. The Guardioz documentation notes that a value written in the text, such as WHERE email = 'anna@example.com', travels with it. The same holds for server logs.
5. R5Apply one change at a time, then measure the same counter. Two changes at once leave no way to tell which one moved the number.
6. R6Keep the four settings above out of scope. fsync, full_page_writes, synchronous_commit, and autovacuum are decisions about risk, and a person makes them.

How to check an assistant's advice on your own server

Treat every proposed value as a claim to test against the same counters before and after the change. Six steps cover it.

1. Write down the claim. Name the setting, the new value, and the counter it should move. A higher work_mem should lower temp_files and temp_bytes. A larger shared_buffers should lower evictions by client backends. A larger max_wal_size should lower num_requested relative to num_timed.
2. Take a baseline. Run the query below twice, at the start and the end of a fixed window of normal traffic, for example the same 24 hours on a working day. Keep the timestamps.
3. Prepare the rollback before the change. Record the current value from pg_settings. The statement that undoes an ALTER SYSTEM SET is ALTER SYSTEM RESET with the setting name, or a second ALTER SYSTEM SET to the old value.
4. Apply the one change. Run ALTER SYSTEM SET, then SELECT pg_reload_conf();, or restart when the setting needs it. Check pending_restart.
5. Measure the same window again. Take two readings over a window of the same length and the same kind of traffic. Compare the change per hour, not the totals.
6. Keep it or roll it back. Keep the change only when the counter moved the way the claim said. Write down the result next to the claim.

The baseline query reads only statistics views. A role with pg_monitor can run it on PostgreSQL 18.

SELECT now() AS taken_at,
       (SELECT sum(temp_files) FROM pg_stat_database) AS temp_files,
       (SELECT sum(temp_bytes) FROM pg_stat_database) AS temp_bytes,
       (SELECT sum(evictions) FROM pg_stat_io
         WHERE backend_type = 'client backend'
           AND object = 'relation'
           AND context = 'normal') AS client_evictions,
       (SELECT wal_bytes FROM pg_stat_wal) AS wal_bytes,
       (SELECT num_timed FROM pg_stat_checkpointer) AS checkpoints_timed,
       (SELECT num_requested FROM pg_stat_checkpointer) AS checkpoints_requested;

The current values and their restart state come from one more read-only query:

SELECT name, setting, unit, context, pending_restart
FROM pg_settings
WHERE name IN ('shared_buffers', 'work_mem', 'maintenance_work_mem',
               'effective_cache_size', 'max_worker_processes',
               'max_wal_size', 'checkpoint_completion_target', 'log_hostname');

A statistics reset between two readings breaks the comparison. Check that stats_reset did not change inside the window.

Rules measure, the model explains

Dr. Kot's position is a split of work. A deterministic check measures and decides what to report. A language model explains the finding and drafts the statement. A check gives the same answer for the same server state, and every answer can be audited against the counter it rests on. A chat answer depends on the prompt, and the prompt holds none of the counters unless someone pastes them.

Research on LLM-based tuning points the same way. λ-Tune, by Victor Giannakouris and Immanuel Trummer, presented at SIGMOD 2025, has a model generate whole configuration scripts from “a large input document, describing the tuning context.” It then picks “the best configuration, out of a small set of candidates” by evaluating them on the system. The model proposes. The measurement decides.

Guardioz is built on the measuring side of that split. Its documentation describes a fixed set of checks, each finding with the measured data it rests on, and a confidence percentage that rises as history accumulates for values sized from the workload. It applies nothing: “You run every command.” Its pricing page answers the chatbot question in one line: “A chatbot answers the question you ask, from what you paste into it.” Guardioz, by contrast, “keeps checking your server, snapshot after snapshot, including the problems you did not think to ask about.”

The two sides work together. Paste a measured finding into an assistant and ask it to explain the setting, the risk, and the rollback. That is the job a language model does well. To compare the tools that sit on the measuring side, from calculators to advisors, read Part 2: calculator, dashboard, or advisor?

Key facts at a glance

From the PostgreSQL 18 documentation, docs.guardioz.com, guardioz.com/pricing, and arXiv, checked on November 4, 2026.

Frequently asked questions

Can ChatGPT tune PostgreSQL?

Partly. ChatGPT and other assistants can explain PostgreSQL settings and propose values from the facts in your prompt. They cannot read your server. Settings that follow from hardware, such as effective_cache_size and max_worker_processes, are within reach of a prompt that gives RAM and CPU count. Settings sized from measured behavior, such as shared_buffers, a raise of work_mem, and max_wal_size, need counters from PostgreSQL's statistics views that the assistant sees only if you hand them over.

Is it safe to apply postgresql.conf settings from ChatGPT?

Only after you check each one. Reject any change to fsync, full_page_writes, synchronous_commit, or autovacuum unless a person has decided it. Ask for the counter behind every value, apply one change at a time with the rollback statement ready, and measure the same counter before and after. shared_buffers and max_worker_processes take effect only after a restart.

What should I give an AI assistant to tune PostgreSQL?

Give it the hardware, the current values from pg_settings, the database and largest table and index sizes, the free space on the data disk, and two readings of the counters with the time between them: evictions from pg_stat_io, temp_files and temp_bytes from pg_stat_database, wal_bytes from pg_stat_wal, and num_timed and num_requested from pg_stat_checkpointer. Do not paste statement text from pg_stat_activity or logs, because it can carry values from your data.

Can AI replace a DBA for PostgreSQL?

Not on its own. An assistant explains settings and drafts statements, but it does not watch the server, and it decides nothing about durability, backups, or the risk a change carries. A team without a DBA needs a fixed set of checks that runs on the server itself, plus a person who decides. Part 1 of this series lists ten checks in the order they hurt.

Does Guardioz use AI?

The Guardioz documentation describes a fixed set of checks with rules for each one. Each finding shows the measured data it rests on, and a recommendation sized from the server's workload carries a confidence percentage that rises as the agent collects more history. Its pricing page answers the chatbot question directly: a chatbot answers the question you ask from what you paste into it, while Guardioz keeps checking the server and shows the measured data behind each recommendation.

Which PostgreSQL settings can an AI assistant size from RAM and CPU alone?

Of the eight performance settings in the Guardioz checks, two depend only on hardware and their current value: effective_cache_size uses total RAM, and max_worker_processes uses the processor count. Two more, checkpoint_completion_target and log_hostname, depend only on configuration you can paste. The other four, shared_buffers, work_mem, maintenance_work_mem, and max_wal_size, need sizes or counters from the running server.

Why does one paste of pg_stat views not show my workload?

The cumulative statistics views count from the last reset. pg_stat_io, pg_stat_database, pg_stat_wal, and pg_stat_checkpointer record its time in a stats_reset column. One paste gives totals over that whole period, an average that hides this week's peaks. A rate needs two readings and the time between them. The Guardioz documentation says the same of its own checks: max_wal_size and a raise of work_mem come from measurements taken between two collections.

Sources

PostgreSQL 18 documentation, checked on November 4, 2026.

• Write Ahead Log settings: fsync, full_page_writes, synchronous_commit, max_wal_size, checkpoint_completion_target
• Resource Consumption: shared_buffers, work_mem, maintenance_work_mem, max_worker_processes
• Query Planning: effective_cache_size
• Error Reporting and Logging: log_hostname
• Vacuuming: autovacuum
• Routine Vacuuming: the autovacuum daemon
• The Cumulative Statistics System: pg_stat_io, pg_stat_database, pg_stat_wal, pg_stat_checkpointer
• pg_settings

Guardioz, checked on November 4, 2026.

• What Guardioz checks
• What the agent reads and sends
• How Guardioz works
• Pricing and FAQ

Research and tools, checked on November 4, 2026.

• Victor Giannakouris and Immanuel Trummer, λ-Tune: Harnessing Large Language Models for Automated Database System Tuning, arXiv 2411.03500, presented at SIGMOD 2025
• Postgres MCP Pro README, crystaldba/postgres-mcp