Is your Cassandra cluster suffering from high read latency or disk pressure? Often the culprit is an ill-fitting compaction strategy. We don't pick strategies "by eye" — we analyze your workload profile, TTL, update frequency, and SSTable sizes. A wrong choice can degrade read latency 2-3x, cause disk overflow, or trigger TombstoneOverwhelmingException. Our team has over 7 years of Apache Cassandra experience and more than 50 performance optimization projects. In 1-3 days we audit, select the right strategy (STCS, LCS, TWCS), and switch without downtime.
We specialize in Cassandra compaction strategies and compaction tuning. Our experts help you choose and implement the best strategy for your workload.
STCS, LCS, and TWCS are the three main mechanisms, each with its own physics. STCS merges SSTables of similar size when a threshold is reached (default 4). Write amplification is minimal, but reads suffer from many scattered SSTables. LCS arranges data in levels: each read touches at most one SSTable per level, giving excellent read performance at the cost of tenfold write amplification. TWCS is designed for time-series: it splits data into time windows and finalizes each window; when TTL expires, the entire SSTable is dropped — no per-row scanning. In our benchmarks, TWCS reduces write amplification up to 8x compared to LCS for time-series data — that's 8 times more efficient.
| Characteristic | STCS | LCS | TWCS |
|---|---|---|---|
| Write amplification | Low | High (~10x) | Low |
| Read performance | Medium | Excellent | Good |
| Disk space | Requires ~2x peak | ~1.1x | ~1.1x |
| TTL handling | Poor | Fair | Excellent |
| Recommended workload | Append-only, write-heavy | Read/write, updates | Time-series with TTL |
How to Choose for Your Workload
For insert-only tables without deletions — STCS. For balanced read/write with frequent updates — LCS. For metrics, logs, and other time-series with TTL — TWCS. In practice, different strategies coexist in one cluster. Example: events (append-only, TTL) -> TWCS; user_profiles (frequent queries and updates) -> LCS; raw_data (bulk insert, no TTL) -> STCS. We help tune each table individually. Understanding the interplay between compaction strategy, bloom filters, and partition pruning is crucial for performance.
What If Compaction Falls Behind?
The nodetool compactionstats command shows pending tasks. If they grow, compaction isn't keeping up with writes. A short-term fix: increase compaction_throughput_mb_per_sec to 64-128 MB/s (depends on disk subsystem). Long-term: reconsider strategy or add nodes. A common mistake is keeping the default for SSDs (16 MB/s), leading to rising read latency. In our practice, we raised throughput to 200 MB/s on NVMe without stability loss.
Tombstones are another performance killer. A single partition read may encounter over 100,000 tombstones, triggering TombstoneOverwhelmingException. Cause: frequent DELETE or UPDATE without timely compaction. Solution: choose the right strategy and tune gc_grace_seconds. In LCS tombstones are removed faster, in STCS slower. For time-series with TTL, tombstones are virtually absent. Our audits have reduced read latency by an average of 55% and disk usage by 35%.
| Scenario | Recommended Strategy | Reason |
|---|---|---|
| High write, no deletes | STCS | Low write amplification |
| Read-intensive, updates | LCS | Minimal SSTables per read |
| Time-series, TTL | TWCS | Automatic deletion of expired SSTables |
Why Tombstones Kill Read Latency
Tombstones are markers for deleted rows. When reading a partition, Cassandra scans all SSTables, collecting live data and ignoring tombstones. If there are many (e.g., frequent DELETEs without timely compaction), latency spikes. TWCS solves this for time-series: expired SSTables are dropped as a whole, leaving no tombstones. For other cases, tuning gc_grace_seconds and selecting the right strategy helps.
Our Process: From Audit to Deployment
- Audit — analyze
nodetool tablestats, compaction and load metrics, identify bottlenecks. - Design — for each table, select strategy and parameters (min/max threshold, bucket size for TWCS).
- Implementation — apply
ALTER TABLEduring off-peak hours. If needed, runnodetool compactbefore switching. - Testing — verify read/write latency, disk usage, tombstone count.
- Deploy and Monitor — set up alerts on pending tasks and tombstone ratio in Prometheus/Grafana.
Case Study
For a time-series table with 1 billion rows, TTL = 30 days, we switched from LCS to TWCS. Write amplification dropped from 8x to 1.5x, read latency decreased by 40%. Disk usage fell by 30%, saving approximately $500/month in storage costs. The entire process took 2 days with no downtime.What's Included in Our Compaction Optimization Service
- Documentation with new settings and recommendations.
- Monitoring of compaction post-change (1 week support).
- Team training on diagnosing compaction issues.
- Access to a Grafana dashboard with compaction metrics.
- Satisfaction guarantee — if performance doesn't improve, we re-audit for free.
Our compaction audit costs $1,500 and typically saves clients $6,000 per year in storage costs.
Timeline: 1 to 3 days depending on table count and restructuring complexity. We estimate after the audit — contact us for a consultation.
Common Compaction Configuration Mistakes
- Using STCS for tables with frequent deletes — tombstones accumulate.
- Switching to TWCS without first compacting old SSTables.
- Ignoring
compaction_throughput_mb_per_sec— leaving the default value. - Applying LCS on write-heavy loads — burns disk I/O.
If your cluster needs compaction tuning, get in touch — we'll audit and propose optimal settings for your workload. The result: predictable read latency and up to 40% disk savings. Schedule a compaction audit today to avoid downtime. Learn more about compaction strategies in the official Apache Cassandra documentation.