Cassandra's default compaction settings choke under sustained write throughput above 5,000-10,000 writes per second per node, and most teams discover this the hard way when pending compactions pile up during a traffic spike. This guide walks through the exact configuration changes that keep compaction ahead of write load in 2026 production clusters.

TL;DR

• SizeTieredCompactionStrategy (STCS) outperforms LeveledCompactionStrategy for pure write-heavy inserts without deletes or TTL.
• Set compaction_throughput_mb_per_sec above the default 64 MB/s once disk I/O headroom exceeds 50% on SSD-backed nodes.
• Pending compactions above 20 per node is the threshold where read latency starts degrading in 2026 workloads.
• Concurrent_compactors should match available CPU cores, not the Cassandra default of 2.
• TimeWindowCompactionStrategy (TWCS) beats STCS for any table using TTL or time-series inserts.

Why this matters

Compaction is the process that merges SSTables and reclaims disk space, and on a write-heavy node it competes directly with flush threads for I/O and CPU. Get the tuning wrong and you end up with hundreds of small SSTables, rising read latency, and a compaction backlog that never clears even during quiet hours. Mydbops' remote DBA team has walked into more than one cluster in 2026 where the fix wasn't more hardware — it was three lines changed in cassandra.yaml.

Write-heavy workloads show up constantly in remote DBA services for online gaming platforms, where leaderboard updates and event logging generate continuous inserts, and in remote DBA services for logistics companies, where GPS pings and shipment status updates hit the cluster every few seconds per vehicle. The tuning below applies to both.

What you'll need

• Cluster access with sudo or admin rights to edit cassandra.yaml on each node
• nodetool installed and reachable (bundled with Cassandra)
• Baseline metrics: current write throughput, disk I/O utilization, and SSTable count per table
• A maintenance window or rolling-restart plan — most changes require a node restart
• JMX or a monitoring agent (Prometheus, DataStax OpsCenter, or equivalent) to watch compaction stats post-change

The steps

1. Diagnose the current compaction backlog

Run nodetool compactionstats on each node before touching anything. This accomplishes one thing: it tells you whether you actually have a compaction problem or a different bottleneck (disk saturation, GC pauses, undersized heap).

Look at the "pending tasks" count. Anything consistently above 20 pending compactions per node means compaction is falling behind write volume. Also run nodetool tablestats <keyspace>.<table> and check SSTable count — a healthy write-heavy table with STCS typically sits under 50-80 SSTables per table per node; anything climbing past that without leveling off signals trouble.

Common mistake: teams jump straight to changing compaction strategy without checking whether the real bottleneck is disk throughput. If disk I/O is already at 90%+, changing the strategy won't help until you address storage.

2. Confirm you're on the right compaction strategy

For pure insert-heavy tables with no deletes and no TTL, SizeTieredCompactionStrategy (STCS) — Cassandra's default — is usually correct. It merges similarly-sized SSTables together, which is cheap for write-only patterns.

If your table uses TTL or writes are naturally time-bucketed (sensor data, event logs, time-series metrics), switch to TimeWindowCompactionStrategy (TWCS) instead. TWCS groups SSTables by time window and drops entire expired windows without a merge, which is dramatically cheaper than STCS for TTL-heavy tables.

LeveledCompactionStrategy (LCS) is built for read-heavy tables with frequent updates — it costs more write amplification and isn't the right call for insert-only, write-heavy patterns. Skip it here.

Common mistake: switching strategies on a large existing table without planning for the one-time rewrite cost — expect elevated disk I/O for hours to days depending on data volume.

3. Raise concurrent_compactors to match your CPU cores

Cassandra defaults concurrent_compactors to a low value regardless of hardware. On a write-heavy node with 8+ cores, set it explicitly in cassandra.yaml:

This lets more compaction tasks run in parallel instead of queuing. Under-provisioning this setting is the single most common cause of a growing pending-compactions count on otherwise healthy hardware. Restart the node (rolling, one at a time) after the change.

Expected outcome: pending compaction count should trend down within 1-2 hours of the restart under steady write load.

4. Increase compaction throughput once disk headroom allows it

The default compaction_throughput_mb_per_sec is 64 MB/s — deliberately conservative to protect read latency on spinning disks. On SSD or NVMe-backed nodes with disk utilization under 50%, push this to 128-256 MB/s:

Setting it to 0 disables throttling entirely — only do this temporarily to clear an emergency backlog, never as a permanent setting, since unthrottled compaction will starve read I/O.

Common mistake: raising throughput on spinning disks without checking I/O headroom first, which tanks read latency for live traffic.

5. Tune memtable flush behavior

Compaction backlogs often start upstream, at the flush stage. If memtable_flush_writers is left at the default of 2 while write throughput is high, flushes queue up and generate a burst of small SSTables that compaction then has to chew through.

Increase it to match your write concurrency, generally 4-8 on a write-heavy node with adequate heap:

Expected outcome: fewer, larger SSTables produced per flush cycle, which reduces the total compaction work downstream.

6. Adjust STCS min_threshold and max_threshold

STCS's default thresholds are min_threshold: 4 and max_threshold: 32. On extremely write-heavy tables generating hundreds of SSTables per hour, a higher min_threshold (6-8) triggers compaction less frequently but merges more SSTables per run, which is more efficient for sustained write bursts.

Common mistake: raising max_threshold too aggressively — very large compaction batches need proportionally more temporary disk space (up to 50% of the table's data size during the merge).

7. Monitor and iterate for two full write cycles

One pass of tuning isn't enough. Watch nodetool compactionstats and SSTable counts across at least two peak-traffic cycles (daily or weekly, depending on your traffic pattern) before declaring victory.

Fintech platforms processing transaction logs and e-commerce platforms handling order-event streams both see write spikes tied to business hours or promotional windows — tuning validated only against off-peak traffic will fail the first real spike. If you're running Cassandra behind a managed database services for fintech platforms setup, validate against your actual transaction peak, not average load.

Troubleshooting

• Pending compactions keep climbing despite tuning: check whether disk I/O is already saturated — no amount of throughput or thread tuning fixes an I/O-bound disk. Consider adding nodes to spread write load instead.
• SSTable count exceeds 100+ per table and keeps rising: you're likely under-provisioned on concurrent_compactors or flush writers, or the compaction strategy doesn't match the write pattern. Revisit steps 2 and 3.
• Read latency spikes right after a compaction throughput increase: you raised throughput past your disk's actual headroom. Drop compaction_throughput_mb_per_sec back down by 30-50% and re-measure.
• Node runs out of disk space mid-compaction: STCS needs temporary space during large merges, roughly up to 50% of the table's on-disk size. Keep at least 50% free disk space on every node running STCS on large tables.
• OOM errors during heavy compaction periods: memtable_heap_space_in_mb and JVM heap settings are too tight for the flush writer count you configured. Scale heap alongside flush writer increases, not independently.
• Compaction falls behind only during specific hours: correlate with your traffic logs — logistics fleets and gaming platforms often see write spikes tied to specific hours, and throughput settings need headroom for the peak, not the average.

Reference thresholds

Tools and resources

• nodetool compactionstats and nodetool tablestats — built-in diagnostics, no extra install required
• cassandra.yaml — the single file holding concurrent_compactors, compaction_throughput_mb_per_sec, and memtable settings
• JMX metrics or a monitoring agent — needed to track pending compactions over time, not just a single snapshot
• Best database consulting services for compliance-heavy industries — relevant if your Cassandra cluster also needs audit trails alongside performance tuning
• Managed database services for e-commerce platforms — for teams running Cassandra alongside order and inventory systems with similar write patterns

What to do next

Compaction tuning is one piece of keeping a write-heavy Cassandra cluster healthy through 2026 — capacity planning, node sizing, and replication factor decisions matter just as much once write volume keeps growing quarter over quarter. If your cluster is already showing 20+ pending compactions under normal load, that's a signal to get a full performance audit before the next traffic spike, not after.

FAQ

What's the best compaction strategy for write-heavy Cassandra tables?

SizeTieredCompactionStrategy (STCS) is best for pure insert-heavy tables without deletes or TTL. Switch to TimeWindowCompactionStrategy (TWCS) if the table uses TTL or time-bucketed writes, since it drops expired data without a merge.

Is LeveledCompactionStrategy better than STCS for writes?

No, LeveledCompactionStrategy (LCS) is built for read-heavy, update-heavy tables and costs more write amplification. STCS is the correct default for write-heavy, insert-only workloads.

How many pending compactions is too many in Cassandra?

More than 20 pending compactions per node consistently signals compaction is falling behind write volume in 2026 workloads. Below that, occasional spikes during peak traffic are normal.

What is the default compaction_throughput_mb_per_sec in Cassandra?

The default is 64 MB/s, set conservatively to protect read latency on spinning disks. SSD or NVMe nodes with disk utilization under 50% can safely raise it to 128-256 MB/s.

How much free disk space does Cassandra compaction need?

Large STCS merges can temporarily need up to 50% of a table's on-disk data size. Keep at least 50% free disk on nodes running STCS on large tables to avoid running out of space mid-compaction.

Does raising concurrent_compactors help write-heavy workloads?

Yes, raising concurrent_compactors to match available CPU cores lets more compaction tasks run in parallel instead of queuing. This is the most common fix for a growing pending-compactions count on adequately provisioned hardware.

Why does Cassandra read latency spike after a write burst?

A write burst produces many small SSTables faster than compaction can merge them, and reads then have to check more SSTables per query. Tuning memtable flush writers and compaction throughput reduces SSTable buildup and brings latency back down.

Should compaction throughput be set to unlimited?

Setting compaction_throughput_mb_per_sec to 0 disables throttling and should only be used temporarily to clear an emergency backlog. Running unthrottled permanently starves read I/O and degrades live query latency.

One last thing

The change teams skip most often isn't in cassandra.yaml at all — it's re-checking SSTable count and pending compactions after a schema change adds new write-heavy tables. A cluster tuned correctly for today's write pattern drifts out of tune the moment a new table with a different access pattern gets added, and by 2026 most Cassandra incidents Mydbops' DBA team traces back trace to exactly that: tuning done once and never revisited.

Conclusion

Compaction keeps pace with a write-heavy Cassandra workload when four things line up: a strategy that matches the write pattern (STCS for insert-only tables, TWCS for TTL and time-series data), enough compaction threads for the hardware, a throughput cap sized to real disk headroom, and flush settings that avoid floods of small SSTables. Diagnose first with nodetool compactionstats and nodetool tablestats so the fix targets the actual bottleneck instead of a guess.

Treat every value in this guide as a starting point rather than a fixed answer. Validate each change across at least two peak-traffic cycles, and re-check pending compactions and SSTable counts whenever a schema change introduces a new write-heavy table.

Related guides

• Managed database services for SaaS startups
• How to prepare a database for a PCI-DSS compliance audit
• Remote DBA services for online gaming platforms