Why do we use tombstones in ScyllaDB?

Because SSTables are immutable once written, ScyllaDB can't simply erase a row or column in place the way an update-in-place database would. Instead, a delete (explicit, or implicit via TTL expiration) is recorded as a tombstone, a special marker written like any other mutation, that tells later reads "ignore any older value you find for this row/column."

Tombstones let deletes be fully consistent with ScyllaDB's replication and compaction model: they replicate to other nodes exactly like a write would, and they get merged and eventually purged during compaction once the deleted data is safely older than gc_grace_seconds across all replicas. The trade-off is that a workload with heavy deletes (or short TTLs) accumulates many tombstones, and reads that must scan past a large number of tombstones to find live data suffer degraded latency, which is why tombstone-heavy access patterns get specific attention in schema and compaction strategy design.