In Cassandra and ScyllaDB, data is written to in-memory structures called Memtables, which are periodically flushed to immutable on-disk files called SSTables (Sorted String Tables). Because SSTables are immutable, an UPDATE creates a new SSTable entry with a newer timestamp, and a DELETE creates a special entry called a tombstone. Over time, you accumulate many SSTables containing overlapping data and tombstones.
Compaction is the process of merging multiple SSTables into fewer, cleaner ones — discarding superseded versions and expired tombstones in the process. Unlike PostgreSQL's autovacuum (which has one strategy), Cassandra gives you a choice of compaction strategies, and picking the wrong one for your workload is a significant performance mistake.
1. Size-Tiered Compaction Strategy (STCS)
STCS is the default strategy. It groups SSTables by size and merges them when enough similarly-sized files accumulate (default: 4 files). Four small files merge into one medium file; four medium files merge into one large file; and so on.
- Pros: Write-optimized. Each write goes to a small SSTable immediately, and compaction happens lazily. Write amplification is low.
- Cons: Read-heavy workloads suffer because a query may need to check many SSTables to find the latest version of a row. Disk space usage spikes during compaction (you temporarily need 2x space). Tombstones from deletes can persist for a long time before being cleaned up.
- Use Case: Write-heavy workloads where reads are less frequent, or as a general-purpose default when you haven't profiled your workload yet.
2. Leveled Compaction Strategy (LCS)
LCS organizes SSTables into levels (L0, L1, L2, ...). Each level has a size limit, and within each level (except L0), SSTables have non-overlapping key ranges — meaning any given row exists in at most one SSTable per level. Files are kept small (default: 160 MB).
- Pros: Read-optimized. A query for a specific row touches at most one SSTable per level, typically just 1–2 files total. Space is reclaimed quickly because tombstones are resolved during frequent compactions.
- Cons: High write amplification. The database constantly rewrites files to maintain the level structure. This generates significantly more I/O than STCS, which can wear out SSDs faster and increase CPU usage.
- Use Case: Read-heavy workloads, or when disk space is constrained and you need fast tombstone resolution.
3. Time-Window Compaction Strategy (TWCS)
TWCS is purpose-built for time-series data. It groups SSTables into time buckets (e.g., one bucket per day). Within each bucket, it uses STCS-style compaction. Crucially, it never compacts data across time boundaries — Day 1 data never merges with Day 2 data.
- Pros: When a time window's TTL expires, the entire SSTable file for that window can be dropped in one operation — no compaction needed, no tombstone scanning. This is dramatically more efficient than STCS or LCS for TTL-based deletion.
- Cons: Requires that your data has a consistent TTL and is written in roughly time-sequential order. If you backfill old data or write out-of-order timestamps, TWCS degrades badly because it cannot compact across windows.
- Use Case: Time-series data (logs, metrics, IoT sensor readings, events) with a defined TTL. This is the correct strategy for any Cassandra table that uses
WITH TTL.
Changing a table's compaction strategy in Cassandra is a single ALTER TABLE ... WITH compaction = {...} statement naming the strategy class and, for TWCS, the time-window unit and size. The compaction_window_size should match your TTL granularity. If you keep data for 30 days, a window of 1 day means you'll have 30 SSTable files, each of which drops cleanly when its day expires.