Apache Cassandra 6: Cursor-Based Compaction Explained

Compaction is one of Apache Cassandra’s most important background processes. It is the mechanism by which the database merges SSTables, removes tombstones, enforces TTLs, and maintains read performance over time. When compaction runs cleanly, it is invisible. When it runs badly, it shows up as GC pauses, latency spikes, and degraded throughput, often at the worst possible moment.

Cassandra 5.0 took a major step forward with Unified Compaction Strategy (UCS), which replaced the fragmented landscape of STCS, LCS, and TWCS with a single adaptive strategy. Cassandra 6 builds on this foundation with cursor-based compaction, a new internal execution path that processes SSTable data in a more streaming-oriented, low-allocation way.

The result is less heap pressure, fewer GC pauses, and smoother cluster behaviour during background compaction, especially on large datasets.

Why Compaction Creates GC Pressure in the First Place

Compaction is fundamentally a data merge operation. It reads multiple SSTables, reconciles row versions across them, drops tombstones and expired TTLs, and writes new merged SSTables. At scale, this involves processing enormous volumes of data.

In the traditional compaction model, this processing creates large numbers of short-lived in-memory objects, including row wrappers, column iterators, and merge buffers. Each of these objects is allocated on the heap and collected by the garbage collector. For clusters running large compactions on big tables, the cumulative effect is significant:

• GC pause frequency increases: the JVM spends more time reclaiming memory from short-lived compaction objects
• Heap pressure spills over: compaction competes with read and write paths for heap space, forcing more frequent full GCs
• Latency variance grows: GC stop-the-world pauses introduce unpredictable latency spikes that affect foreground query performance
• Node throughput degrades: sustained GC pressure during heavy compaction periods can noticeably reduce overall node throughput

These effects are well known in the Cassandra operator community. Tuning JVM heap settings, GC algorithms, and compaction throughput limits is a standard part of production Cassandra operations. Cursor-based compaction reduces the need for these workarounds by addressing the source of heap churn directly. Because Cassandra runs on the JVM, garbage collection behaviour is a recurring theme across different Cassandra distributions, not just the open-source project.

What Cursor-Based Compaction Does Differently

Cursor-based compaction introduces reusable, cursor-like reader and writer objects that process SSTable data in a streaming-oriented way. Instead of creating new in-memory objects for each row or column during processing, the same cursor objects are reused across the entire compaction operation.

The conceptual shift is from an allocation-heavy batch model to a streaming model:

This is a fundamentally different approach to the same operation. The output, merged SSTables with tombstones removed and TTLs enforced, is identical. The difference lies in how efficiently the database uses memory to get there.

How This Pairs with Unified Compaction Strategy

Unified Compaction Strategy (UCS, Cassandra 5.0) and cursor-based compaction are complementary improvements that address different aspects of compaction:

UCS decides what to compact. Cursor-based compaction decides how that compaction runs. Clusters upgrading to Cassandra 6 with UCS already enabled will get the full combined benefit of both improvements.

Read our blog to learn more about Cassandra 6 Dictionary Compression

Operational Impact: What Changes for Operators

GC Tuning Becomes Less Critical

One of the most common Cassandra operational tasks is tuning JVM GC settings to manage compaction-induced heap pressure, such as adjusting G1GC heap regions, tuning pause time targets, or increasing heap size to reduce full GC frequency. Cursor-based compaction reduces the heap allocation rate during compaction, which means these tuning parameters have less work to do. Clusters that previously needed aggressive GC tuning to handle large compaction jobs may find that their existing settings handle the load more comfortably.

More Consistent Performance on Large Datasets

The benefit of cursor-based compaction is most visible on clusters running large compactions: tables with billions of rows, heavy tombstone accumulation from delete-heavy workloads, or wide rows with many column versions. These are the compactions that previously caused the most noticeable GC pressure and latency variance. With lower allocation rates, those same compactions run with a smaller heap footprint and less GC interference.

Compaction No Longer Dominates Heap Headroom

On write-heavy clusters, compaction can consume a significant fraction of heap headroom, leaving less room for read caches, memtables, and other foreground operations. Cursor-based compaction’s reduced allocation rate means compaction takes up less of the shared heap budget, improving the memory headroom available for read and write paths during busy periods.

Better Efficiency on Memory-Constrained Nodes

For clusters running in cost-constrained environments, such as cloud instances with limited memory, edge deployments, or development clusters, cursor-based compaction’s reduced memory footprint is particularly valuable. Less heap consumption per compaction means more room to run compaction concurrently with other background tasks without the risk of an out-of-memory error.

What Has Not Changed

It is worth being precise about what cursor-based compaction does not change:

• It does not checkpoint or resume compaction. If a compaction is interrupted by a node restart, it still restarts from the beginning. Resumability is not part of this improvement.
• It does not change compaction scheduling. UCS or your configured strategy still determines what gets compacted and when.
• It does not reduce compaction I/O. The same amount of data is read and written. The improvement is in heap allocation efficiency, not I/O volume.
• It does not change output correctness. The resulting SSTables are identical to those produced by traditional compaction. This is a performance improvement, not a behavioral change.

Ksolves Guidance for Upgrade Planning

When advising clients on Cassandra 6 upgrades, we position cursor-based compaction as a performance dividend: an improvement that arrives with the upgrade without any specific action required. That said, a few areas are worth paying attention to:

• Benchmark GC metrics before and after the upgrade: Establish a baseline for GC pause frequency, GC duration, and heap utilisation during compaction on your current version. Post-upgrade, compare these metrics to quantify the improvement. This is the clearest way to demonstrate the value of cursor-based compaction to stakeholders.
• Revisit JVM heap sizing: If you previously increased heap size specifically to handle compaction-induced GC pressure, you may be able to reduce it post-upgrade. A smaller heap means smaller GC pauses and a better overall latency profile.
• Combine with UCS if not already done: If you are still running STCS or LCS, migrate to UCS as part of your Cassandra 6 upgrade. UCS and cursor-based compaction together deliver the full compaction improvement stack.
• Target high-write, high-tombstone tables first: The tables that benefit most from cursor-based compaction are those with the heaviest compaction workloads. Identify these tables before the upgrade and monitor them specifically afterward.

Conclusion

Cursor-based compaction is one of the clearest engineering wins in Apache Cassandra 6. It does not change what compaction produces or how it is scheduled, but it changes how efficiently the database gets there, with less heap churn, fewer garbage collection pauses, and more predictable performance under load.

For teams running large, delete-heavy, or memory-constrained clusters, this improvement can meaningfully reduce the operational tuning burden that has long been part of running Cassandra at scale. Paired with Unified Compaction Strategy, it gives Cassandra 6 the most complete compaction stack the project has shipped to date.

Upgrading itself requires no special preparation, but capturing before-and-after GC metrics remains the best way to see and prove the difference for your own workload.

FAQs