Free tool

How much memory can these settings actually claim?

work_mem is per operation, and one connection can hold many of them at once while most connections hold none. This multiplies it out, adds the autovacuum workers, and checks what the planner has been promised.

Run it on your numbers

RAM on the server(GB)

What the machine has, not what the container is limited to. If they differ, the container limit is the one that kills you.

shared_buffers(GB)

work_mem(MB)

max_connections(connections)

hash_mem_multiplier(x work_mem)

Defaulted to 1.0 through PostgreSQL 14 and to 2.0 from 15. Nobody has to change it for the exposure to double.

Hash or sort nodes in one plan(nodes)

Each one may hold its own allocation at the same time. Count the Hash, HashAggregate and Sort nodes in the worst plan you actually run.

max_parallel_workers_per_gather(workers)

Every worker under a Gather gets its own allocation for each node, and so does the leader.

Queries like that running at once(queries)

Not max_connections. The number of genuinely heavy queries you would expect at the same moment, which is what a report hour or a retry storm decides.

maintenance_work_mem(MB)

autovacuum_work_mem(MB)

-1 means each autovacuum worker uses maintenance_work_mem instead, which is the default and is usually a surprise.

autovacuum_max_workers(workers)

temp_buffers(MB)

Per session, allocated on first use of a temporary table and never given back for the life of the session.

effective_cache_size(GB)

A promise to the planner, not an allocation. This tool checks whether the promise can be kept.

Everything else on the box(GB)

The kernel, the pooler, the exporter, the backup agent, the log shipper. Zero here is a claim, not a default.

Healthy Computed in your browser. Nothing is sent anywhere.

The worst case is 24.3 GB of 64.0 GB, and one backend alone can hold 776 MB

Worst case, everything at once

24.3 GB

of 64.0 GB, leaving 39.8 GB for the page cache
One backend can hold

776 MB

4 nodes x 64.0 MB x 3 processes, plus temp_buffers
The naive work_mem x max_connections

3.1 GB

quoted everywhere, and wrong in both directions
Hash exposure at the PostgreSQL 17 default multiplier

6.0 GB

3.0 GB on the other side of the 15 boundary, with no setting changed
Autovacuum workers, concurrently

192 MB

3 x 64.0 MB, held alongside everything above
Page cache the planner is promised

4.0 GB

55.8 GB can exist, so the promise holds

The worst case is 24.3 GB of 64.0 GB, leaving 39.8 GB for the page cache on top of shared_buffers. That is the number to keep an eye on, not the average. Read more
work_mem times max_connections is 3.1 GB, and it is the wrong sum in both directions. One connection running 4 hash or sort nodes under 2 parallel workers can hold 776 MB on its own, which is 24.3 times work_mem rather than one; most of your connections meanwhile hold nothing at all. Read more
PostgreSQL 17 defaults hash_mem_multiplier to 2.0 and every major through 14 defaulted it to 1.0. At this work_mem that is 3.0 GB of hash exposure before the upgrade and 6.0 GB after it, with nothing in postgresql.conf different. It is the quietest reason a server starts getting killed after a major upgrade. Read more
effective_cache_size claims 4.0 GB and there is room for 55.8 GB, so the planner's assumption survives the worst case. It allocates nothing either way — it only changes which plan looks cheaper. Read more
Autovacuum is the part that runs beside all of it: 3 workers at 64.0 MB each is 192 MB held at the same time as the backends, and autovacuum_work_mem is -1, so each worker takes maintenance_work_mem. Raising maintenance_work_mem for a one-off index build raises it for every autovacuum worker too. Read more
Changing autovacuum_max_workers on PostgreSQL 17 is a restart, not a reload: it is a postmaster setting until 18, where autovacuum_worker_slots took that role. Multiply it by maintenance_work_mem before you decide the window is worth booking. Read more

Apply it

Read it before you run it. A setting marked as needing a restart is a maintenance window, not a reload.

DBExplore watches the numbers behind this on every collection cycle, so the check happens continuously rather than when someone remembers. See what a pilot involves.

Where these numbers come from on your server

One statement, read-only, and it changes nothing. It follows the version selector above, because the settings and views it reads did not all exist on every major.

SELECT json_build_object(
  'mem_shared_buffers_blocks', (SELECT setting::bigint FROM pg_settings WHERE name = 'shared_buffers'),
  'mem_work_mem_kb', (SELECT setting::bigint FROM pg_settings WHERE name = 'work_mem'),
  'mem_hash_mem_multiplier', (SELECT setting::float8 FROM pg_settings WHERE name = 'hash_mem_multiplier'),
  'mem_maintenance_work_mem_kb', (SELECT setting::bigint FROM pg_settings WHERE name = 'maintenance_work_mem'),
  'mem_autovacuum_work_mem_kb', (SELECT setting::bigint FROM pg_settings WHERE name = 'autovacuum_work_mem'),
  'mem_autovacuum_max_workers', (SELECT setting::bigint FROM pg_settings WHERE name = 'autovacuum_max_workers'),
  'mem_temp_buffers_blocks', (SELECT setting::bigint FROM pg_settings WHERE name = 'temp_buffers'),
  'mem_effective_cache_size_blocks', (SELECT setting::bigint FROM pg_settings WHERE name = 'effective_cache_size'),
  'mem_parallel_workers_per_gather', (SELECT setting::bigint FROM pg_settings WHERE name = 'max_parallel_workers_per_gather'),
  'max_connections', (SELECT setting::bigint FROM pg_settings WHERE name = 'max_connections')
) AS memory_budget;

Per operation is doing a lot of work in that sentence

The documentation for work_mem says it is the memory allowed for each sort or hash operation before the work spills to disk. Very few people then multiply it by the number of such operations one plan runs at the same time, by the parallel workers that each get their own copy, and by the number of those plans that can be in flight at once. A query with four hash joins under two parallel workers holds twelve allocations, not one.

The figure normally quoted instead is work_mem times max_connections, and it is wrong in both directions at once. Far too large, because most of your connections are idle and hold none of it; far too small, because one connection running the plan above holds many multiples. Neither error cancels the other, and what you are left with is a number that describes nothing that happens.

What the total above is actually counting

Four things, all of which can be claimed at the same moment. The shared memory, which is taken at startup and never given back. The backends, at the multiplied-out worst case for as many heavy queries as you said could overlap. The autovacuum workers, each holding maintenance memory, which is the part people forget because it happens on its own schedule rather than in response to traffic. And whatever else lives on the box, never zero once you count the pooler and the exporter.

Then there is the part that allocates nothing at all. effective_cache_size is a promise to the planner about how much of a table it expects to find in cache, and the planner costs index scans against that promise. Take the four things above out of RAM and what remains is the page cache that can physically exist under load. When the promise is bigger than the remainder, plans that were chosen on a quiet server are being chosen for a cache that will not be there at the busy hour.

The setting that doubled without anyone touching it

hash_mem_multiplier defaulted to 1.0 through PostgreSQL 14 and defaults to 2.0 from 15. It is a user setting, so nothing about it needs a restart and nothing about it appears in a diff of postgresql.conf. A server that came through a major upgrade with an identical configuration file can therefore expose twice the hash memory it did the week before, and the first sign is a backend being killed during a report that had always been fine.

Flip the version selector across that boundary and the exposure figure moves while every input stays where it was. If you are planning the upgrade, the cheap fix is to halve work_mem in the same change, which keeps the worst case where it is and leaves the plan shapes alone. Sorts are unaffected either way: the multiplier applies to hash operations, and this tool assumes every node is one because that is what a worst case means.

Nobody wants to be the one who ran the query too late.

DBExplore watches the numbers behind these checks on every cluster it is pointed at, and asks before it changes anything. We onboard design partners in small batches.

Request early access Book a demo