Queries on a particular table have been getting slower for weeks. The plan is unchanged, the row count has grown modestly, and nothing in the application changed.
The table occupies three times the space its live rows require. Every sequential scan reads three times as many pages, the buffer cache holds a third as much useful data per page, and other queries suffer for the memory it wastes.
None of that appears in row counts, query plans, or application metrics.
What changed in 2026
- Managed platforms surfaced it. More hosted database services began reporting bloat estimates directly.
- Ratio-based alerting became standard. Alerting on the proportion rather than the absolute size became the norm.
- Index bloat got equal attention. Recognition that indexes bloat worse than tables and are checked less often.
- Estimation methods stabilised. Widely-used estimation queries became well-known enough to be treated as standard tooling.
What bloat costs
Disk is the least of it.
Cache pressure is the real cost. A database's speed comes from serving reads out of memory. A table occupying three times the necessary space fills the cache with pages that are mostly dead rows, evicting data other queries needed. The visible symptom is frequently other queries slowing down, which makes diagnosis harder.
Scan cost rises directly. A sequential scan reads every page, including the ones that are mostly dead.
Maintenance cost rises. Vacuum, backups, and replication all process more data.
Index effectiveness falls, since a bloated index means more pages traversed per lookup — see index bloat.
| Symptom |
Bloat as cause |
| Gradual slowdown, no plan change |
Likely |
| Other queries slower after one table grew |
Cache pressure |
| Backups taking longer |
Contributing |
| Disk growth exceeding row growth |
Direct signal |
| Sequential scans slower than expected |
Direct signal |
Measuring it
The metric is a ratio: actual size divided by the size the live rows would require.
Around 1.2 is normal and healthy — some slack is expected and useful, since it gives new rows somewhere to go. Meaningfully above 2 warrants attention. Above 4 is a problem worth acting on.
Estimation is approximate. Computing exact bloat requires reading the whole table, which is expensive, so the standard approach estimates from average row width and page counts. It can be off, particularly on tables with highly variable row sizes, and it is reliably good enough to distinguish a healthy table from a badly bloated one.
Track the ratio over time rather than sampling once. A stable ratio is fine at almost any level; a rising one means cleanup is losing the race and will keep losing it.
Also track dead row counts and time since last vacuum per table, which tell you why — see autovacuum tuning.
Acting on it
First, find out why. Bloat is a symptom. The usual causes are cleanup falling behind on a high-churn table, or a long-running transaction preventing reclamation entirely. Rebuilding without addressing the cause means doing it again in a month.
Check the oldest transaction age. If a transaction has been open for hours, nothing can be reclaimed and no rebuild will hold — see MVCC explained.
Tune cleanup for that table specifically. High-churn tables need per-table settings; global defaults systematically underserve them.
Rebuild only what needs it. A rebuild reclaims the space and costs I/O and, depending on method, locking. Rebuilding on a schedule regardless of measurement wastes I/O on tables that were fine.
For indexes, concurrent rebuilds avoid the write-blocking lock — see index bloat.
Common mistakes
- Not measuring at all. The default state, and bloat is invisible without it.
- Alerting on absolute size. Growth is normal; ratio is the signal.
- Rebuilding without fixing the cause. It returns.
- Ignoring indexes. They bloat worse and are checked less.
- Treating estimates as exact. They are approximations.
- Scheduled rebuilds. I/O spent on healthy objects.
- Missing the long-transaction cause. Tuning cannot fix it.
FAQ
What ratio should trigger action?
Around 2 is a reasonable investigation threshold, 4 an action threshold. More important is the trend — a steadily rising ratio needs attention regardless of the current value.
How accurate are the estimates?
Good enough to distinguish healthy from problematic, and not precise. Do not treat a change from 2.1 to 2.3 as meaningful.
Does bloat ever resolve itself?
The space is reused for new rows once reclaimed, so a table with steady churn reaches an equilibrium. It does not shrink back without a rebuild — reclaimed space stays allocated to the table.
Should I monitor every table?
Monitor everything, alert on the ones that matter — high-churn tables and anything large. Small stable tables will not surprise you.
Where to go next
For keeping cleanup ahead of churn, read autovacuum tuning. For the index-specific case, index bloat, and for the mechanism producing dead rows, MVCC explained.