How does LanceDB handle deletes internally?

A delete in LanceDB is a non-destructive operation at the storage level: rather than immediately erasing the deleted rows' data, it writes a new version with deletion markers flagging those rows as removed, while the actual underlying data remains present on disk until a later, explicit cleanup step.

This design is what makes deletes participate cleanly in the same versioning and time-travel system as every other write: checking out a version from before the delete happened still shows the "deleted" rows exactly as they were, since nothing about that earlier version's manifest or files has changed.

The trade-off is that deletes alone don't reclaim disk space immediately; a table with heavy delete/update churn will accumulate old data files across versions until an explicit maintenance operation (compaction, combined with pruning old versions past a retention window) actually removes the now-unreferenced data and reclaims that storage.