Qdrant Deletion Disk Full Compaction
Deleting millions of Qdrant points does not immediately return proportional PVC space. Deleted vectors become optimizer and vacuum work, and a nearly full volume can prevent the very segment rewrites that would reclaim disk. Treat this as a vector database headroom incident, not a simple delete-more incident.
Do not keep deleting into a 100% PVC; create optimizer headroom first.
Use this when a Qdrant collection turns red, point deletion frees little space, or startup fails while writing segment state such as an .atomicwrite... file.
expand PVC -> restart -> trigger optimizer -> wait -> shrink later
Capture PVC headroom, collection status, optimizer pressure, and segment bytes.
These checks avoid vector payloads and private documents. They show whether the incident is raw PVC fullness, optimizer starvation, segment rewrite overhead, snapshot growth, or WAL/raft state pressure.
df; du storage; collection info; optimizer/status; segment sizes
Runbook: Make Space For The Reclaimer
- Pause bulk delete jobs once Qdrant reports low disk capacity or the PVC is nearly full. More deletes can create more optimizer work before they create usable free space.
- Temporarily grow the PVC or attach a larger volume. Qdrant needs working room for internal structures, optimizer rewrites, and atomic segment-state writes.
- Restart only after emergency headroom exists. A restart at 100% disk can fail while loading a shard or flushing segment metadata.
- Trigger or wait for optimizer/vacuum work. Deleted points are reclaimed asynchronously; monitor collection status until the optimizer backlog is drained.
- Separate capacity classes: live vectors, segments, WAL/raft state, snapshots, temp/atomicwrite files, and orphaned outputs from failed writes.
- Add a hard policy for future deletes: required free-space reserve, max points per batch, pause threshold, and post-delete optimizer completion check.
- Only shrink storage or resume normal ingestion after collection reopen, optimizer status, and PVC free bytes are stable.
Use this when point deletion does not free Qdrant disk immediately.
This frames the bug as a headroom and optimizer safety policy: grow first, recover, wait for vacuum, then set future delete limits.
I would treat this as a Qdrant optimizer/headroom incident first. Deleting points marks work for the optimizer; it does not guarantee immediate proportional filesystem reclaim.
Public-safe checks I would collect:
- PVC free bytes and inode usage at the time Qdrant turns red.
- Collection status before/after deletion and after restart.
- Segment, WAL/raft, snapshot, and temp/atomicwrite file sizes under the collection path.
- Delete batch size and whether optimizer/vacuum work had time and headroom to complete.
Operationally I would stop the delete job, temporarily grow the PVC, restart with headroom, trigger/wait for optimizers, and only shrink later after collection reopen and optimizer completion are verified. For the future I would add a reserve threshold, max delete batch size, and an alert when optimizer backlog cannot run because disk is too full.Turn one Qdrant deletion incident into a reusable vector database storage policy.
The $99 policy is for vector databases, RAG systems, Kubernetes PVCs, and embedding stores where delete, vacuum, optimizer, snapshot, and segment rewrite behavior can consume disk before reclaiming it. You get a headroom model, batch-delete guardrail, recovery checklist, and alert thresholds for one representative collection.
Do Not Delete First
- Segment files, WAL/raft state, or collection metadata just to make room for optimizers.
- Snapshot files before confirming restore coverage and retention rules.
- Temporary or atomicwrite files before identifying whether Qdrant is still using or retrying them.
- More points in larger batches while the optimizer cannot run due to low disk capacity.