Key Features of Cassandra 5.x: Unified Compaction Strategy (UCS)

Compaction is one of the most critical background processes in Apache Cassandra, directly influencing read latency, write throughput, disk utilization, and overall cluster stability. It governs how SSTables are merged, how efficiently tombstones are purged, and how many files must be scanned during read operations, making compaction strategy selection a decisive factor in Cassandra performance.

With the release of Cassandra 5.x, the introduction of the Unified Compaction Strategy (UCS) fundamentally redefines this decision. Instead of choosing and managing multiple compaction strategies such as Size-Tiered, Leveled, or Time-Windowed, UCS provides a single, flexible framework that dynamically adapts to changing workload patterns. Whether your tables are write-heavy, read-optimized, or a mix of both, UCS intelligently balances throughput, latency, and storage efficiency—simplifying operations while delivering consistent performance at scale.

Why Compaction Matters

Compaction is a core internal process in Apache Cassandra that governs how SSTables are merged, how tombstones are reclaimed, and how many files a read operation must scan. These factors directly influence read amplification, write amplification, query latency, and disk utilization, making compaction one of the most impactful performance levers in the system.

Historically, Cassandra operators were required to choose a compaction strategy, Size-Tiered (STCS), Leveled (LCS), or Time-Windowed (TWCS), at table creation time. This decision was difficult to reverse and often carried long-term operational consequences as workloads evolved. The Unified Compaction Strategy (UCS) was introduced in Cassandra 5.x to eliminate this rigid trade-off, providing a single adaptive strategy that adjusts dynamically to workload behavior without constant retuning or disruptive maintenance.

What is Unified Compaction Strategy (UCS)?

The problem: multiple compaction strategies and operational overhead

In previous Cassandra versions, you had to choose among strategies like

• SizeTieredCompactionStrategy (STCS): good for write-heavy workloads, but suffers for reads when many SSTables accumulate.
• LeveledCompactionStrategy (LCS): good for read-heavy workloads, but more write amplification and complexity.
• TimeWindowCompactionStrategy (TWCS): tailored for time-series/TTL data.

The solution: UCS in Cassandra 5.x

The UnifiedCompactionStrategy (UCS) is recommended for most workloads, whether read-heavy, write-heavy, mixed read-write, or time-series. There is no need to use legacy compaction strategies, because UCS can be configured to behave like any of them.

Key benefits of UCS:

• You can configure it to behave like tiered (STCS) or leveled (LCS), or mix behavior across levels.
• It introduces sharding, enabling parallel compactions by splitting token ranges/SSTable groups.
• It’s stateless for decision-making (less metadata overhead) and more adaptable.
• You can change parameters in flight (without full compaction) to shift behavior.

In short, UCS gives you a single unified solution for compaction that simplifies operations and gives flexibility across workload types.

Why the ROI Matters: Operations, Performance, Simplicity

Let’s look at how UCS delivers tangible ROI for Cassandra deployments.

Operational Simplicity

• Previously, you needed to decide on a strategy at table creation, and migrating strategies required full major compaction or heavy operations. With UCS, you can adjust parameters later.
• One strategy to monitor and tune (instead of multiple) reduces cognitive load on operators and simplifies documentation/training.

Adaptive Performance

• UCS allows tuning the trade-off of read amplification (RA) vs write amplification (WA) via a single scaling parameter (W or scaling_parameters).
• For example, lowering W moves behavior toward leveled compaction (good for reads); raising W moves toward tiered compaction (good for writes).
• Sharded parallel compactions mean better utilization on high-density nodes (many disks/volumes) and less compaction bottleneck.

Storage Efficiency

• Because you reduce unnecessary SSTable overlaps and can better tune size/density, UCS helps keep the read path efficient (fewer SSTables) and the write path under control (less unnecessary merging).
• While not always a “magic storage reduction number,” the simpler compaction behavior and better tuning can lead to lower I/O, less compaction backlog, and better storage utilization.
  

Summary of ROI

Comparing Legacy Strategies vs UCS-Enabled

Legacy STCS

ALTER TABLE ks.tbl WITH compaction = {

  ‘class’:’SizeTieredCompactionStrategy’,

  ‘min_threshold’:’4′,

  ‘max_threshold’:’32’};

• Good for write-heavy workloads, poor for read-heavy patterns when many SSTables accumulate.

Legacy LCS

ALTER TABLE ks.tbl WITH compaction = {

  ‘class’:’LeveledCompactionStrategy’,

  ‘sstable_size_in_mb’:’160′

};

• Good for low read amplification, but higher write amplification and more I/O.

UCS (basic example)

• scaling_parameters encodes the density/fanout decisions (expressed as T/L/N tokens in the official syntax).

ALTER TABLE ks.tbl WITH compaction = {
  'class':'UnifiedCompactionStrategy',
  'scaling_parameters':'T4', -- tier-like with fanout 4
  'target_sstable_size':'1GiB',
  'base_shard_count':'4'
};

UCS (read-opt/leveled-like)

ALTER TABLE ks.tbl WITH compaction = {

  ‘class’:’UnifiedCompactionStrategy’,

  ‘scaling_parameters’:’L10′,        — leveled-like parameters

  ‘target_sstable_size’:’256MiB’,

  ‘base_shard_count’:’8′

};

UCS encodes the tradeoff between read amplification (RA) and write amplification (WA) via scaling_parameters and other knobs, so a single strategy can mimic STCS/LCS behavior as needed.

Data Modeling & Compaction Best Practices with UCS

Things you should do

1. Use UCS as the default for most tables unless special cases (e.g., pure time series,  though UCS handles that too).
2. Choose initial parameters based on workload profile:
   • Write‐heavy: higher T value (tiered-like)
   • Read-heavy: lower/negative W (level-like)
3. Monitor key metrics: pending compactions, number of SSTables per partition, compaction throughput, and read latencies.
4. Use sharding (base_shard_count) wisely when you have many disks/volumes to leverage parallelism.
5. Plan for SSTable size and density: set target_sstable_size, min_sstable_size, etc., for your node hardware and I/O capacity.

Things to avoid/trade-offs

• Do not assume “set and forget.” Although UCS simplifies, you still need to monitor and tune for your workload.
• If you have a very narrow, special workload (e.g., pure TTL time series with strict windowing), it may still make sense to evaluate TWCS or special configs, but UCS covers most cases reliably.
• Be aware that compaction tuning influences resource use: aggressive compaction may increase I/O or CPU usage and risk latency if not aligned with hardware.
• Migration from legacy strategies to UCS still needs planning: existing SSTables may need upgrades, and behavior may differ initially until SSTables are aligned.

Example: full walkthrough (create, tune, observe)

Create a table with UCS (write-heavy start)

CREATE TABLE demo.events (

  event_id uuid PRIMARY KEY,

  ts timestamp,

  user_id uuid,

  payload text

) WITH compaction = {

  ‘class’:’UnifiedCompactionStrategy’,

  ‘scaling_parameters’:’T4′,

  ‘target_sstable_size’:’1GiB’,

  ‘base_shard_count’:’4′};

Load data: generate high write throughput (millions of rows).

Monitor

• nodetool compactionstats—check active compactions.
• Measure reads (table histograms), and SSTables touched.

Convert/retune for read-heavy queries.

ALTER TABLE demo.events WITH compaction = {

  ‘class’:’UnifiedCompactionStrategy’,

  ‘scaling_parameters’:’L10′,

  ‘target_sstable_size’:’256MiB’,

  ‘base_shard_count’:’8′

};

• Observe reduced read amplification and the number of SSTables per read over time.

Capture metrics before and after tuning to quantify RA/WA differences for your workload.

Wrapping Up

The Unified Compaction Strategy is a major step forward in Cassandra 5.x- giving you one highly configurable, flexible, and performant compaction strategy that adapts across workload types.

• It simplifies operations (fewer strategies to understand and manage)
• It offers adaptive tuning (read vs write emphasis)
• It supports modern high-density hardware (sharding, parallel compactions)
• It reduces the risk of choosing the “wrong” compaction strategy upfront.

That said, it isn’t a “set it and forget it” feature. The workspace still needs monitoring and tuning. Also, special cases (extreme time series, legacy tables) may need special consideration.

If you are running Cassandra 5.x or planning an upgrade and managing multiple tables or mixed workloads, UCS should be your default compaction strategy of choice. Ksolves provides end-to-end Cassandra upgrade and migration services, helping enterprises move seamlessly from Cassandra 3.x or 4.x to 5.x with expert UCS implementation. Contact Ksolves to ensure a secure, zero-downtime Cassandra upgrade optimized for performance and scalability.