What causes "TombstoneOverwhelmingException" in apache/cassandra?

Run `nodetool compact` on the affected table to purge tombstoned data, or wait for compaction.

apache/cassandra · error · TombstoneOverwhelmingException

TombstoneOverwhelmingException

Error message

TombstoneOverwhelmingException

What it means

ReadCommand's tombstone-counting row/merkle iterator throws TombstoneOverwhelmingException when a single query touches more tombstones than tombstone_failure_threshold (default 100k). This protects the node from read explosions caused by mass deletes/expiring data; a client query is aborted rather than allowed to grind the coordinator down.

Source

Thrown at src/java/org/apache/cassandra/db/ReadCommand.java:701

            {
                countTombstone(marker.clustering());
                return marker;
            }

            private void countTombstone(ClusteringPrefix<?> clustering)
            {
                ++tombstones;
                if (tombstones > failureThreshold && respectTombstoneThresholds)
                {
                    String query = ReadCommand.this.toCQLString();
                    Tracing.trace("Scanned over {} tombstones for query {}; query aborted (see tombstone_failure_threshold)", failureThreshold, query);
                    metric.tombstoneFailures.inc();
                    if (trackWarnings)
                    {
                        MessageParams.remove(ParamType.TOMBSTONE_WARNING);
                        MessageParams.add(ParamType.TOMBSTONE_FAIL, tombstones);
                    }
                    throw new TombstoneOverwhelmingException(tombstones, query, ReadCommand.this.metadata(), currentKey, clustering);
                }
            }

            @Override
            protected void onPartitionClose()
            {
                int lr = liveRows - lastReportedLiveRows;
                int ts = tombstones - lastReportedTombstones;

                if (lr > 0)
                    metric.topReadPartitionRowCount.addSample(currentKey.getKey(), lr);

                if (ts > 0)
                    metric.topReadPartitionTombstoneCount.addSample(currentKey.getKey(), ts);

                lastReportedLiveRows = liveRows;
                lastReportedTombstones = tombstones;
            }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Run `nodetool compact` on the affected table to purge tombstoned data, or wait for compaction.
Raise tombstone_failure_threshold / tombstone_warn_threshold temporarily in cassandra.yaml if reads are legitimately tombstone-heavy.
Redesign schema: avoid unbounded deletes, delete by partition, use shorter gc_grace_seconds deliberately, prefer TTL over explicit deletes.
Add LIMIT / narrower partition-key predicates to the query so fewer tombstones are scanned.

Example fix

// before
session.execute("SELECT * FROM events"); // scans millions of tombstones
// after
session.execute("SELECT * FROM events WHERE day = ? AND bucket = ? LIMIT 1000", day, bucket); // partition-scoped

Defensive patterns

Strategy: try-catch

Validate before calling

// Pre-check table health: watch `nodetool tablestats` tombstone counters; alert when
tombstones_scanned per read approaches tombstone_warn_threshold.

Try / catch

try { rs = session.execute(query); } catch (DriverException e) {
    if (e.getMessage() != null && e.getMessage().contains("tombstones")) { runCompactOrNarrowQuery(); } else throw e;
}

Prevention

Always scope reads by partition key; avoid full-table scans on delete-heavy tables.
Prefer TTL-based expiry over mass DELETE statements.
Schedule compaction and monitor SSTable tombstone density.
Review gc_grace_seconds and repair cadence.

When it happens

Trigger: SELECT (or secondary-index/compaction-adjacent reads) over partitions containing more than tombstone_fail_threshold tombstones — e.g. queries against tables with heavy deletes, frequent TTL expiry of non-local-expiry data, or very old un-compacted SSTables.

Common situations: Time-series tables where old partitions are deleted but never fully compacted; queries without partition keys (full-table scans) hitting tombstone-rich SSTables; tombstone_gc delays plus repair-lag leaving resurrection risk un-compacted.

Understand the failure class

Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/efb4c2316d33ead1. Report an issue: GitHub.