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.

Runbook: Make Space For The Reclaimer

1. 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.
2. Temporarily grow the PVC or attach a larger volume. Qdrant needs working room for internal structures, optimizer rewrites, and atomic segment-state writes.
3. Restart only after emergency headroom exists. A restart at 100% disk can fail while loading a shard or flushing segment metadata.
4. Trigger or wait for optimizer/vacuum work. Deleted points are reclaimed asynchronously; monitor collection status until the optimizer backlog is drained.
5. Separate capacity classes: live vectors, segments, WAL/raft state, snapshots, temp/atomicwrite files, and orphaned outputs from failed writes.
6. Add a hard policy for future deletes: required free-space reserve, max points per batch, pause threshold, and post-delete optimizer completion check.
7. Only shrink storage or resume normal ingestion after collection reopen, optimizer status, and PVC free bytes are stable.

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.

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.