Vacuum & bloatintermediatePro runbook

Reclaim table bloat: plain VACUUM vs VACUUM FULL

Dead tuples leave a table larger than its live data. Plain VACUUM clears dead rows without blocking readers and keeps the file size; VACUUM FULL rewrites it smaller, here 26 MB down to 10 MB, under an exclusive lock. Online shrink needs pg_repack or pg_squeeze, not FULL.

Problem

What you're actually looking at

The symptom as it shows up on a real server.

PostgreSQL's MVCC leaves dead row versions behind after UPDATE and DELETE. VACUUM marks that space reusable so the table stops growing, but it does not return space to the operating system. Only VACUUM FULL (or an online rewrite tool) actually shrinks the file, FULL takes an exclusive lock; plain VACUUM does not.

Meridian's parcel_ledger has churned to 160,000 live rows but 240,000 dead ones, holding 26 MB. The team needs to see what plain VACUUM fixes in place, when FULL is worth a maintenance window, and when an online tool is the right call.

Simple terms

When you UPDATE or DELETE a row, PostgreSQL does not erase the old version straight away, it leaves it behind as a "dead" row so other transactions still see a consistent picture. Over time those dead rows pile up and the table file stays big even when the live data is small (here 26 MB of file for 160,000 real rows). A normal VACUUM lets that dead space be reused so the table stops growing, but it does not hand space back to the disk. Only VACUUM FULL actually shrinks the file, but it locks the whole table while it rewrites, so you run it in a quiet window.

ProCaptured evidence where the run produced it

Full runbook for this incident

The scenario above is free. What Pro unlocks is the fix: how to identify reclaim table bloat: plain vacuum vs vacuum full, the exact SQL to trace it, PostgreSQL 18 output for the steps we captured, the resolution path, and how to stop it recurring.
  • The full identify checklist, the exact signals that tell you it's this incident
  • Every diagnostic query; lab output is attached only to the steps we actually captured
  • The resolution path and the pitfalls that make it worse
  • Mitigation steps to stop it recurring, plus a verify-you're-done query

Card required. Cancel before day 7 and you are not charged.

Compare plans

Connected

How this connects to the rest of the library

A live view of this page's real cross-references, what explains it, what fixes it, what to tune, and where to go next. Every link is an authored relationship, not a guess.

Open in the interactive map →
ShareLinkedInX

Need the full procedure?

Pro runbooks finish the incident path

Free runbooks teach the shape. Pro opens the full step transcript, edge cases, and prevention depth.

FollowSubstackLinkedInnew errors · lab notes · hiring loops