What does CouchDB actually store when you DELETE a document, and what does compaction reclaim?

## A delete is a write In CouchDB, deleting is just another edit. `DELETE /db/{docid}?rev=3-abc` appends a child revision `4-…` to the revision tree, sets `_deleted: true` on it, and discards the document's fields. The `_id` remains, the ancestry remains, and the document still exists as far as the storage engine is concerned — it simply reads as gone: a plain `GET` returns `404 Not Found` with reason `deleted`, and the document disappears from `_all_docs` and from view results. ## Why the tombstone has to survive CouchDB replicates by comparing revision trees. If a delete were an erase, a node would see the document present on the peer and absent locally, conclude it was missing, and copy it back — deletions would never converge, and any old replica reconnecting after a month would resurrect everything it remembered. The tombstone is the positive statement "this document was deleted at revision 4-…", and it is what actually travels. That means the cost of deletion in CouchDB is not zero and never reaches zero: every document you have ever deleted leaves a permanent, small record behind. ## What compaction does `POST /db/_compact` rewrites the database file, copying forward only what is still needed. It removes: - the **bodies of superseded revisions** — the old versions along each branch that are no longer leaves; - storage overhead from the append-only file layout, since CouchDB never updates in place. It keeps: - all current leaf revisions and their bodies; - the **revision identifiers** of the discarded ancestors, up to the retention limit, because replication needs to compare ancestry; - **every tombstone**. A practical consequence: after compaction you can usually no longer fetch an old revision by `?rev=`, even though its id still appears in `_revs_info`. This is why revision history must never be used as an audit trail — compaction is expected to run, and it deletes exactly the thing an audit trail would need. View indexes are compacted separately with `POST /db/{db}/_compact/{ddoc}`, and stale index files left behind by removed or edited design documents are removed by `POST /db/{db}/_view_cleanup`. ## Revision history retention Each database has a `_revs_limit` — how many revision identifiers to keep in a document's history — readable and writable at `GET`/`PUT /db/_revs_limit`, defaulting to 1000. Once history is trimmed past that point, two replicas can hold revisions whose common ancestor has been forgotten; they can then no longer prove one descends from the other and may register a conflict instead. Lowering the limit aggressively on a database with heavy edit churn saves space and buys conflicts. Raising it does the opposite. ## Purging `POST /db/_purge` takes a map of document ids to revisions and removes them from the database entirely, tombstones included. It exists mainly for regulatory erasure and for cleaning up accidentally written giant documents. Its caveats are severe: a purge applies to the node you sent it to and does not travel through normal replication the way a deletion does, so a peer that still holds the document can replicate it straight back; and purging a document that a replication checkpoint depends on can force replications to restart. Treat purge as a deliberate operational procedure with the topology in mind, never as routine cleanup. ## Deleting while keeping fields A `DELETE` throws the body away, which is inconvenient when replication is filtered — a filter function cannot route a deletion it cannot inspect. The idiom is to `PUT` the document yourself with `_deleted: true` **and** the few fields your filter or downstream consumers need, such as a tenant id or type. The document is just as deleted, but the tombstone still carries enough information to be examined. ## Operational shape CouchDB 3.x runs compaction automatically according to a configurable schedule, and administrators typically constrain it to off-peak windows because it rewrites the file and competes for disk I/O. Databases dominated by create-then-delete traffic — job queues, session stores, anything ephemeral — accumulate tombstones without bound; the usual remedy is not purging but rotation: use a fresh database per period and drop the whole database when it ages out, since deleting a database really does free everything. ## Interview framing Say it in one line: deletion writes a tombstone, compaction reclaims superseded bodies, and tombstones are forever because replication needs them. Then show the operational instinct — rotate databases rather than purge, and never plan around revision history surviving compaction.