Database Vacuum or Compaction¶
Technical procedure — instantiates Accumulation Compaction
Reclaims space and reorganizes on-disk storage left bloated by obsolete row versions — running on a bloat trigger and a maintenance cadence, and staying crash-safe — without changing what any query returns.
Database Vacuum or Compaction is the storage-engine procedure that reclaims the physical space accumulated history leaves behind. In a system that keeps old versions of rows to serve concurrent readers — or that writes new data in append-only segments — deleted and superseded versions pile up as dead weight on disk long after any query needs them. Vacuum walks that storage, frees the dead space, and reorganizes the live data into a tighter layout. Its defining constraint is that it is logically invisible: unlike every summarizing sibling, it discards nothing a query can observe. The content of the database — every row a SELECT can return — is identical before and after. What changes is only the physical arrangement and the bytes on disk. Because it rewrites live storage, it must stay crash-safe, so that an interrupted vacuum leaves the data recoverable and unchanged.
Example¶
A busy Postgres-backed application runs millions of UPDATEs a day against an orders table. Under multi-version concurrency control, each update leaves the old row version in place until no transaction can still see it; those obsolete versions become dead tuples. Over weeks the table's on-disk size triples even though the number of live orders barely grew, and index scans slow down because the engine wades through bloat. Autovacuum is configured to fire when dead tuples exceed a fraction of the table — the trigger — and to run on a low-traffic nightly cadence for heavier passes. It reclaims the dead space and updates the visibility map; the table shrinks and scans speed up.
No order changed. A query for "orders placed yesterday" returns exactly what it returned before the vacuum ran. And because the operation is written through the engine's crash-recovery machinery, a power loss mid-vacuum rolls back cleanly, leaving the table intact. The database got smaller and faster while its meaning stayed frozen.
How it works¶
What distinguishes it from a content-reducing compaction is that its correctness test is observational equivalence:
- Fire on a bloat trigger. A threshold — dead-tuple ratio, segment count, fragmentation level — decides when accumulated dead storage justifies a pass.
- Reclaim and reorganize. Free the space held by obsolete versions and rewrite live data into a denser, better-ordered layout; optionally rebuild indexes.
- Run on a maintenance cadence. Light passes run continuously or on a schedule against live traffic; heavier reorganizations are timed for low-load windows.
- Stay crash-safe. The rewrite goes through write-ahead logging and transactional guarantees, so an interrupted run rolls back and the data is never left corrupt or altered.
Tuning parameters¶
- Bloat trigger threshold — how much dead space accumulates before a pass fires. Low thresholds keep tables tight but spend constant I/O and can vacuum data still churning; high thresholds let bloat grow and slow queries.
- Cadence and window — how often and when passes run. Frequent off-peak passes smooth the cost; rare aggressive passes reclaim more at once but can stall live traffic.
- Aggressiveness — an in-place light reclaim versus a full rewrite that returns space to the OS but takes an exclusive lock. The full rewrite recovers the most but blocks access while it runs.
- Concurrency budget — how much CPU and I/O the vacuum may consume against live load. A generous budget finishes sooner but competes with queries; a throttled one is gentle but lags behind accumulation.
When it helps, and when it misleads¶
Its strength is that it keeps a database sustainable without touching its meaning: bounded storage, fast scans, and reclaimed space, all while every query result stays identical. It is a first-class, automated feature of production engines precisely because the accumulation it fights is unavoidable under versioned concurrency.[n1]
It misleads when it is starved or over-driven. Let the trigger sit too high and dead tuples accumulate faster than passes clear them — the table bloats without bound, a state operators know as runaway bloat, and a belated full rewrite then needs a disruptive exclusive lock. Drive it too hard on a hot table and the vacuum competes with the very queries it is meant to speed up. The subtler misuse is confusing this lossless, physical operation with a content compaction: vacuum reclaims space from data the engine already considers obsolete, so pointing it at a stream where old versions still carry meaning is a category error — that keyed, content-aware retention is Log Compaction, which lives under a different archetype and decides what history to keep, not merely where to store it. The discipline is to size the trigger and cadence to the table's real write rate and let observational equivalence — not disk pressure — define what may be reclaimed.
How it implements the components¶
Database Vacuum or Compaction fills the physical-maintenance side of the archetype — reclaiming the cost of accumulation without altering its content:
compaction_trigger— the bloat threshold (dead-tuple ratio, fragmentation) that decides when a pass is due.compaction_cadence— the continuous or scheduled rhythm on which light and heavy passes run against live traffic.rehydration_or_rollback_path— the crash-recovery machinery that lets an interrupted rewrite roll back with the data unchanged and recoverable.
It does NOT produce a summary_layer standing in for the data — that is Snapshot Plus Archive — nor discard content under a loss_budget — that is Deduplication Pass; vacuum changes only physical layout, never what any query returns.
Related¶
- Instantiates: Accumulation Compaction — it is the archetype applied to the physical storage cost of accumulated row versions.
- Sibling mechanisms: Log Compaction · Deduplication Pass · Snapshot Plus Archive · Backlog Consolidation · Knowledge Base Pruning · Documentation Consolidation · Archival Summarization · Retrospective Synthesis · Retention Schedule
Editorial Notes¶
Form Classification¶
Form family: Intervention, Treatment & Transformation
Rationale: Database Vacuum or Compaction operates as a direct treatment or transformation intended to change the target state or representation because it reclaims space and reorganizes on-disk storage left bloated by obsolete row versions — running on a bloat trigger and a maintenance cadence, and staying crash-safe — without changing what any query returns.
Independent corroboration: The frozen evidence defines Database Vacuum or Compaction as 'Reclaims space and reorganizes on-disk storage left bloated by obsolete row versions — running on a bloat trigger and a maintenance cadence, and staying crash-safe — without changing what any query returns', so its operative form is Intervention, Treatment & Transformation.
Nearest alternative: Protocol, Workflow & Routine — The pass directly reorganizes physical storage while preserving query-visible content; trigger and cadence organize that intervention.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Database-storage engineering cohered vacuum and compaction passes that reclaim obsolete versions and fragmented space created by update and deletion under persistent or multiversion storage.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
The reason vacuum can be fully automated where the summarizing siblings cannot is that it has no judgment calls: "obsolete" is defined by the engine's visibility rules, not by a curator's sense of value. Everything the operation removes is provably invisible to every legitimate query, which is exactly why it needs no loss budget, no provenance links, and no bias review — the things that make the content-compacting siblings inherently manual.
[n1] Under multi-version concurrency control (MVCC), an UPDATE or DELETE leaves the prior row version in place so that transactions already in flight still see a consistent snapshot; once no transaction can see them, those versions are dead space that a vacuum reclaims. The MVCC/autovacuum pairing in engines like PostgreSQL is referenced here as an established design, not as a cited authority. ↩