---
source: https://iinventedlight.com/library/notes/postgres-vacuum-mvcc.md
title: "PostgreSQL VACUUM and MVCC: why dead rows pile up"
license: CC-BY-4.0
license_url: https://creativecommons.org/licenses/by/4.0/
source_license: "PostgreSQL License; prose restates cited source lines"
attribution: "Summary by iinventedlight (AI-assisted). Sources: PostgreSQL Global Development Group, PostgreSQL: Documentation: 18: 24.1. Routine Vacuuming, PostgreSQL License; PostgreSQL Global Development Group, PostgreSQL: Documentation: 18: 13.1. Introduction, PostgreSQL License."
author: "iinventedlight (synthesis of cited sources); text drafted with AI assistance"
date: 2026-11-04
status: published
checked_on: 2026-11-04
as_of: 2026-11-04
confidence: medium
untested: "No code was run for this note; only the fetched documentation pages were read."
category: coding-references
topic_area: "code-ai-eng: PostgreSQL"
tags: postgresql, vacuum, mvcc, maintenance
sources:
  - id: S1
    title: "PostgreSQL: Documentation: 18: 24.1. Routine Vacuuming"
    publisher: PostgreSQL Global Development Group
    url: https://www.postgresql.org/docs/current/routine-vacuuming.html
    accessed: 2026-11-04
    license: "PostgreSQL License"
  - id: S2
    title: "PostgreSQL: Documentation: 18: 13.1. Introduction"
    publisher: PostgreSQL Global Development Group
    url: https://www.postgresql.org/docs/current/mvcc-intro.html
    accessed: 2026-11-04
    license: "PostgreSQL License"
---
# PostgreSQL VACUUM and MVCC: why dead rows pile up

## Short answer
PostgreSQL uses MVCC (multiversion concurrency control): an UPDATE or DELETE leaves the old row version in place so other transactions can still see it. VACUUM cleans them. [S1][S2]

## What VACUUM does
- Recovers or reuses space from updated or deleted rows. [S1]
- Updates planner statistics and the visibility map (which speeds up index-only scans). [S1]
- To protect against loss of very old data due to transaction ID wraparound or multixact ID wraparound. (S1)

If you have a table whose entire contents are deleted on a periodic basis, consider doing it with TRUNCATE rather than using DELETE followed by VACUUM. (S1)

## Claims
- id: C1
  claim: VACUUM recovers or reuses disk space from updated or deleted rows.
  source: S1
  evidence: "To recover or reuse disk space occupied by updated or deleted rows."
- id: C2
  claim: VACUUM updates the visibility map for index-only scans.
  source: S1
  evidence: "To update the visibility map, which speeds up index-only scans."
- id: C3
  claim: VACUUM protects against transaction ID wraparound data loss.
  source: S1
  evidence: "To protect against loss of very old data due to transaction ID wraparound"
- id: C4
  claim: Under MVCC reading never blocks writing.
  source: S2
  evidence: "reading never blocks writing and writing never blocks"

## Sources
- [S1] PostgreSQL: Documentation: 18: 24.1. Routine Vacuuming. PostgreSQL Global Development Group. https://www.postgresql.org/docs/current/routine-vacuuming.html . License: PostgreSQL License. Accessed 2026-11-04.
- [S2] PostgreSQL: Documentation: 18: 13.1. Introduction. PostgreSQL Global Development Group. https://www.postgresql.org/docs/current/mvcc-intro.html . License: PostgreSQL License. Accessed 2026-11-04.

License: this note is CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Summary by iinventedlight (AI-assisted).
