How Does Vector Database Compaction Reclaim Space After Document Deletion?
Vector database compaction reclaims deleted space by rewriting live records into clean segments and retiring older segment files that still contain removed vectors.
Deleting a household document from a local RAG library can make it disappear from search immediately while disk usage barely changes. That is not necessarily a failed delete. Many vector databases separate logical visibility from physical storage cleanup so foreground writes remain fast and readers can continue using immutable or append-oriented segments. Compaction is the later maintenance path that turns those logical deletions into a smaller physical representation.
A Delete Usually Changes Visibility Before It Rewrites Stored Bytes
Physically editing a large index file for every delete would create expensive random writes and complex concurrency. Many engines instead record a deletion marker, tombstone, or delete log that tells search to ignore the vector.
HNSW tombstones let deleted objects become ineligible for graph search before background maintenance physically removes all of their index state.
The user-facing result and the disk-level result therefore happen at different times. The record can stop appearing in nearest-neighbor results while its old bytes remain inside an existing segment.
This separation also gives the database room to coordinate concurrent queries, replicas, snapshots, and retention rules before destroying historical storage structures.
Deleted Records Accumulate Inside Segments Until a Cleanup Threshold Is Reached
A segment can contain both live vectors and records that are no longer eligible for search. As updates and deletes accumulate, the ratio of useful data to obsolete data falls.
A deleted-vector threshold can delay expensive cleanup until enough obsolete points have accumulated for a segment rewrite to be worthwhile.
Waiting for a threshold amortizes maintenance work. Rewriting a segment to recover one tiny deleted record would cost more I/O than the space saved. On a home server with frequent re-indexing, the visible amount of stale physical storage can therefore rise for a while before the optimizer decides cleanup is worthwhile.
Compaction Copies Live Data Into New or Merged Segments
Once maintenance begins, the database reads eligible source segments, skips logically deleted records, and writes the surviving vectors and payloads into a new compact representation.
compaction as segment merging and delete cleanup rewrites surviving data into cleaner segments while omitting records that are already logically deleted or expired.
Small segments can be merged at the same time, which reduces the number of separate structures search must consult. The new segment represents the live state rather than carrying every historical mutation forward.
This rewrite can temporarily need extra free space because old and new segments may coexist until the replacement is verified and made active.
Indexes Are Rebuilt Around the Surviving Vector Set
Removing vector payload bytes is only part of cleanup. Graph links, quantized structures, filters, and segment metadata may refer to records that no longer belong in the live segment.
A compaction path that rebuilds indexes during optimization ensures graph and auxiliary search structures correspond to the surviving vector set rather than retaining references to removed points.
For HNSW, that can change graph topology even when the remaining vectors themselves are unchanged. This is why compaction can affect approximate-neighbor traversal while still preserving the same logical dataset. The mechanism in this article is the storage lifecycle: obsolete records are excluded from the rewritten index so their physical footprint can eventually disappear.
Old Segments Must Be Retired Before Their Storage Can Be Freed
After the compacted segment becomes the active representation, old segments are marked obsolete or dropped. The underlying files may still wait for a garbage-collection or retention period before actual disk blocks are released.
When garbage collection follows compaction, dropped segment files can remain temporarily after the compacted replacement is active, so filesystem space may be released later than query visibility changes.
Snapshots, backup retention, replication, or readers holding references can lengthen that delay in systems that preserve older segment generations.
Disk monitoring should therefore distinguish logical entity count, active segment size, temporary compaction space, dropped segments, and free filesystem capacity.
Compaction Is Background Maintenance With Its Own Resource Cost
Reading old segments, writing new ones, rebuilding indexes, and deleting obsolete files consumes CPU, disk bandwidth, memory, and sometimes temporary duplicate storage.
tombstone cleanup metrics make delete repair observable as a maintenance workload with its own cycles, durations, and resource consumption.
Avoiding stale index records after file updates is an upstream requirement: a source deletion must first reach the vector database before compaction can reclaim the obsolete representation.
Recommended products
Tech & AI HUB
More to Read
What Is Plex State, and Which Parts Must Persist?
Persistent Plex state is the information that preserves the server experience across restart and rebuild; media and temporary transcode data are separate roles.
How Does Plex Handle Authentication Across Local and Remote Sessions?
Plex authentication starts with server and account identity, then local or remote network paths determine reachability and secure connection behavior.
Why Can Plex Search Slow Down as Library Data Grows?
Library growth alone is not the diagnosis. Test query shape, indexes, cache state, storage latency, and write activity before blaming database size.
