ScyllaDBadvanced

ScyllaDB Compaction

Compaction strategies in ScyllaDB, including incremental compaction, and how repair works with the built-in manager.

2 min readAdvancedUpdated 31 Jul 2026Edit this page

ScyllaDB supports the Cassandra compaction strategies and adds one of its own. The trade-offs described in Cassandra Compaction Strategies carry over.

Strategies

Strategy	Notes
`SizeTieredCompactionStrategy`	Default; needs substantial free space for large merges
`LeveledCompactionStrategy`	Lower read amplification, higher write amplification
`TimeWindowCompactionStrategy`	Time series with TTL
`IncrementalCompactionStrategy`	ScyllaDB-specific; size-tiered behaviour with much lower space overhead

Incremental compaction splits SSTables into fragments so a merge does not need room for a full duplicate of the largest table. On storage-constrained deployments this is the main reason to choose it over size-tiered.

ALTER TABLE shop.events
WITH compaction = {'class': 'IncrementalCompactionStrategy'};

Self-tuning schedulers

ScyllaDB meters compaction against user traffic through its I/O and CPU schedulers rather than a fixed throughput setting. In practice this means you should not start by pinning throughput limits — observe first, and intervene only if the scheduler is not achieving the balance you need.

nodetool compactionstats
curl -s localhost:9180/metrics | grep scylla_compaction_manager

Repairs

The obligation is identical to Cassandra's: replicas diverge, and only anti-entropy repair reconciles everything. Every table must be repaired within gc_grace_seconds, or deleted data can reappear — see Tombstones.

nodetool repair -pr shop
nodetool repair -full shop events

ScyllaDB Manager is the supported way to schedule this. It handles segmentation, parallelism, retries and progress tracking across the cluster:

sctool cluster add --host 10.20.1.10 --name prod
sctool repair --cluster prod --interval 7d --start-date now
sctool task list --cluster prod
sctool progress --cluster prod repair/<task-id>

Repair-based operations

ScyllaDB can use the repair mechanism for node operations such as bootstrap, decommission and replace, rather than the older streaming path. The benefit is resumability: an interrupted operation continues rather than restarting from the beginning, which matters when moving terabytes.

Verify which mechanism your version uses by default, and prefer the repair-based path for large nodes where a restart from zero would be expensive.