As previously mentioned, a delete in Cassandra writes a tombstone. Therefore, it is fair to say that deletes are also treated as write operations. Tombstones can be written at both the row and the column level for a key. As the tombstones also need to be reconciled at read-time, queries for data that contain tombstones become cumbersome, and get slower over time.

It should be noted that one of the most common ways tombstones are created in Cassandra is through the explicit setting of null values. Cassandra's concept of null is slightly different from its relational counterpart. Each row is not required to contain a value for each column. Querying these columns may return null, but that is simply Cassandra's way of stating that it just doesn't have data for that column.

Writing an explicit null value to a column for a key tells Cassandra that that row doesn't need to concern itself with a value for that column. The only way it can do that is to write a tombstone. Application code that uses prepared statements containing empty values is an unfortunate yet common way that tombstones get propagated in a table.