Cassandra DELETE Data

The DELETE statement removes rows or specific columns from a Cassandra table. Because Cassandra is a distributed system, deletion works differently from a traditional database. Instead of immediately erasing data, Cassandra writes a tombstone — a special marker that says "this data was deleted." The actual data disappears during the next compaction cycle.

Why Tombstones Exist

Consider a three-node cluster where Node B is temporarily offline. You delete a row on Nodes A and C. When Node B comes back online, it has no idea the deletion happened. Without tombstones, that row would resurface on reads from Node B. Tombstones travel to offline nodes during the repair process and prevent deleted data from reappearing.

Deletion on a 3-node cluster:

Node A ──▶ receives DELETE ──▶ writes tombstone ✓
Node B ──▶ OFFLINE           ──▶ tombstone delivered during next repair
Node C ──▶ receives DELETE ──▶ writes tombstone ✓

Read result: deleted row does NOT appear (tombstone wins over old data)

DELETE a Full Row

DELETE FROM customers
WHERE customer_id = 11111111-1111-1111-1111-111111111111;

DELETE with Clustering Columns

When a table uses clustering columns, you can delete a single row, a range of rows, or all rows in a partition.

-- Delete one specific order:
DELETE FROM orders_by_customer
WHERE customer_id = [uuid]
  AND order_date   = '2024-05-01 10:00:00'
  AND order_id     = [order-uuid];

-- Delete all orders for a customer placed before April 2024:
DELETE FROM orders_by_customer
WHERE customer_id = [uuid]
  AND order_date < '2024-04-01';

-- Delete the entire partition (all orders for the customer):
DELETE FROM orders_by_customer
WHERE customer_id = [uuid];

DELETE Specific Columns

You can delete individual column values without removing the entire row. This places a tombstone on only that column.

DELETE phone FROM customers
WHERE customer_id = [uuid];

Before:
customer_id | first_name | email             | phone
──────────────────────────────────────────────────
uuid-A      | Alice      | alice@example.com | 555-1234

After:
customer_id | first_name | email             | phone
──────────────────────────────────────────────────
uuid-A      | Alice      | alice@example.com | null

DELETE with TIMESTAMP

You can attach a custom timestamp to a DELETE so it is treated as having occurred at a specific point in time. This is useful when replaying historical events.

DELETE FROM events USING TIMESTAMP 1709999999000000
WHERE event_id = [uuid];

DELETE from Collections

Remove a MAP Entry

DELETE settings['notifications'] FROM user_prefs
WHERE user_id = [uuid];

Remove a LIST Element by Index

DELETE songs[0] FROM playlists
WHERE playlist_id = [uuid];

Clear a Whole Collection Column

DELETE tags FROM articles WHERE article_id = [uuid];

DELETE IF EXISTS (Conditional)

The DELETE IF EXISTS clause deletes the row only if it currently exists. This uses a lightweight transaction and returns an [applied] boolean.

DELETE FROM customers
WHERE customer_id = [uuid]
IF EXISTS;

 [applied]
───────────
 True      -- row was found and deleted
 False     -- row did not exist

TRUNCATE — Delete All Rows

TRUNCATE removes all rows from a table but keeps the table structure. It is faster than issuing a DELETE for every row because it drops SSTables directly.

TRUNCATE orders_by_customer;

Managing Tombstone Accumulation

Too many tombstones slow down reads because Cassandra must scan through them to determine the current state of the data. The following practices keep tombstone counts healthy.

Best Practice                          Reason
──────────────────────────────────────────────────────────────────────
Use TTL instead of DELETE for          TTL tombstones are compacted
  temporary data                       more predictably
Tune gc_grace_seconds                  Shorter grace = tombstones
  appropriately                        removed sooner
Run nodetool repair regularly          Ensures tombstones reach all
                                       replica nodes before expiry
Avoid deleting individual column       Row-level deletes create fewer
  values repeatedly                    tombstones overall

Tombstone Warning in Logs

When a read query scans more tombstones than a configured threshold, Cassandra writes a warning to the system log. The default threshold is 1,000 tombstones per query. If you see these warnings, redesign the table or adjust the data lifecycle strategy.

WARN  [ReadStage] Read 1234 live rows and 5678 tombstone cells...

Summary

DELETE in Cassandra writes tombstones instead of immediately removing data. You can delete entire rows, row ranges within a partition, or individual column values. Use TRUNCATE to clear a full table quickly. Avoid excessive column-level deletes to prevent tombstone accumulation. Regularly run repairs and tune gc_grace_seconds to keep tombstone lifetimes under control. Use TTL as an alternative to DELETE wherever data has a natural expiration time.