Skip to content
dbexplore

Question: Monitoring

How do I find what is using all my disk space?

Answered in the first paragraph. Last updated .

Check four places, in this order, because they fail for different reasons and on different timescales: the write-ahead log directory, the temporary file area, the server log directory, and only then the tables. Relations are almost always the largest number and almost never the thing that changed today. The three directories are small until something goes wrong, at which point they grow faster than anything else on the volume.

The three that grow suddenly

The log directory grows because segments are being retained, not because writes increased, and there are only a few reasons a segment is retained. That is its own question, in why pg_wal is filling up, and it is the first thing to check because it is the one that can take the server down.

Temporary files come next. One query whose sort or hash does not fit in memory spills to disk, and a badly estimated join can write tens of gigabytes in a single statement. There is a per-session cap available and it is off by default, which means one query can genuinely consume the volume. Temporary files covers what makes a query spill and how to see it happening.

Then the server log itself, which is usually somebody’s fault rather than the database’s: statement logging turned on for an investigation and never turned off, or an error loop writing the same line a thousand times a second.

The one that grows slowly

For relations, rank by total size including indexes and out-of-line storage rather than by the table’s own heap, because on a table with several indexes the heap is frequently the smaller half. The ranking is what matters; the absolute number rarely tells you anything on its own.

Then remember that some of the space inside those files is not data. Space that was freed and is waiting to be reused looks identical from outside, which is bloat, and no directory listing can show it. A table whose file is twice the size of its live rows has a maintenance problem rather than a capacity problem, and autovacuum and table bloat covers the three reasons space stops being reused.

One operational note that outranks all of the above. Keep headroom on the volume, because every remedy here needs some: a rewrite needs room for a second copy, an index rebuild needs room for the new index, and a full disk removes both options at once while the server is still trying to write its log.

Put every Postgres you run on autopilot.

We onboard teams in small batches. Tell us about your fleet and we will reach out when a seat opens. One email, no drip campaign.