Cassandra TTL and Space Reclamation: Understanding Automatic Deletion and Data Cleanup in 2025

Apache Cassandra is a powerful distributed NoSQL database designed for handling massive amounts of data across many commodity servers. One of its most useful features for time-series or ephemeral data is the TTL (Time-To-Live) mechanism. TTL enables automatic data expiration without the need for manual cleanup, making it ideal for use cases like logs, session data, metrics, and temporary events.

However, a common question among Cassandra users is:

“When TTL expires, does the space get reclaimed automatically? If not, how can we reclaim it?”

In this blog post, we will explore:

1. What TTL is and how it works in Cassandra.
2. What happens when TTL expires.
3. How Cassandra handles space reclamation.
4. Best practices to ensure efficient space usage.
5. Steps to manually trigger cleanup if necessary.

1. What is TTL in Cassandra?

TTL (Time-to-Live) in Cassandra allows you to set an expiration time on data. Once the TTL expires, the data is marked for deletion and becomes inaccessible from queries.

You can set TTL at:

• Column-level: During insert/update of a specific column.
• Table-level default: A default TTL can be defined at the table schema level.

Example:

INSERT INTO user_sessions (user_id, session_id) VALUES ('123', 'abc') USING TTL 2678400; -- 31 days in seconds

2. What Happens When TTL Expires?

When the TTL for a row or column expires:

• The data becomes logically deleted.
• Cassandra marks it with a tombstone.
• The actual disk space is not immediately reclaimed.

These tombstones remain until they are purged during compaction, which is a background process in Cassandra that merges SSTables and removes obsolete or deleted data.

3. Does Cassandra Automatically Reclaim Space After TTL?

Short answer: Not immediately.

Expired data marked with tombstones is removed only when the compaction process runs and merges SSTables. Until then:

• The data still occupies disk space.
• Read performance may degrade due to excessive tombstones.

Cassandra is designed for eventual consistency, and space is only freed after certain conditions are met.

4. How Compaction Works in Cassandra

Compaction is the process of merging SSTables and cleaning up deleted/expired data.

There are different types of compaction strategies:

• SizeTieredCompactionStrategy (STCS) – Default for most use cases.
• TimeWindowCompactionStrategy (TWCS) – Best for time-series data with TTL.
• LeveledCompactionStrategy (LCS) – Ideal for read-heavy workloads.

When compaction runs, it:

1. Reads data from multiple SSTables.
2. Identifies expired data and tombstones.
3. Rewrites only valid data to new SSTables.
4. Deletes old SSTables, reclaiming space.

However, compaction is not instant. It depends on system activity, disk I/O, and compaction thresholds.

5. How Long Do Tombstones Stay?

Cassandra has a setting called gc_grace_seconds, which determines how long tombstones are retained before they are eligible for permanent deletion.

Default is 864000 seconds (10 days).

This delay is crucial to prevent resurrecting deleted data during repairs or node recovery. After this period, compaction will safely remove expired data.

6. Best Practices for Efficient TTL and Compaction

1. Use TTL for Ephemeral Data Only: Don’t use TTL for permanent records or business-critical data.
2. Use TimeWindowCompactionStrategy (TWCS) for Time-Series Data:

CREATE TABLE metrics (
  metric_id text,
  timestamp timestamp,
  value double,
  PRIMARY KEY (metric_id, timestamp)
) WITH compaction = {
  'class': 'TimeWindowCompactionStrategy',
  'compaction_window_unit': 'DAYS',
  'compaction_window_size': 1
};

3. Set gc_grace_seconds Smartly: For TTL-based data with no deletes/updates, set gc_grace_seconds = 0 to allow faster cleanup.
4. Monitor Tombstone Counts:

nodetool cfstats keyspace.table

Check for high tombstone counts which can impact read performance.

5. Manually Trigger Major Compaction (Caution):

nodetool compact keyspace table

Use with care — compaction is I/O intensive and can impact performance.

7. Manual Cleanup Steps (If Needed)

If you want to expedite space reclamation manually:

1. Check Disk Usage:

df -h

2. Flush Memtables to Disk:

nodetool flush keyspace table

3. Trigger Compaction:

nodetool compact keyspace table

4. Run Cleanup (If topology changed):

nodetool cleanup keyspace table

5. Repair (Optional):

nodetool repair keyspace table

8. Summary

TTL in Cassandra is a great tool to auto-expire data, but the deletion is not instantaneous in terms of space reclamation. Actual disk cleanup happens during compaction after gc_grace_seconds.

Checklist for managing TTL data:

• Use appropriate compaction strategy.
• Monitor tombstones and disk space.
• Set gc_grace_seconds wisely.
• Manually compact only when needed.

With the right setup, TTL + TWCS + monitoring ensures optimal performance and disk usage.

Follow me on Linkedin

By understanding how TTL works and how Cassandra reclaims space, you can design more efficient, automated, and cost-effective data retention strategies.

Stay tuned for more DevOps & Cassandra tips. Have questions or want a script to automate TTL and compaction monitoring? Let me know!