Why can excessive tombstones degrade Cassandra performance?

A tombstone is not free — it still takes up space and, more importantly, the read path has to scan past it to figure out that a value was deleted.

• A read touching a partition with thousands of tombstones must iterate over all of them in memory before it can return the small number of live rows underneath, driving up read latency and heap pressure.
• Cassandra tracks a per-query tombstone count and enforces tombstone_warn_threshold and tombstone_failure_threshold — crossing the failure threshold aborts the query outright to protect the node.
• Patterns like using a table purely as a queue, or repeatedly deleting and re-inserting rows in the same partition, are classic ways to accumulate huge tombstone counts quickly.

Mitigations include modeling deletes with TTLs so expiration is predictable, using Time Window Compaction Strategy for time-series data so whole SSTables age out together, avoiding "delete-heavy" partition designs, and running repairs regularly so tombstones can actually be purged once gc_grace_seconds passes instead of piling up indefinitely.