Skip to main content
Compaction is the background process that reorganizes data in RocksDB’s LSM tree. It merges sorted files from different levels, removes deleted entries, and maintains read performance as data grows.

Why Compaction?

As writes accumulate in RocksDB, several problems emerge without compaction:
  • Read amplification: More files to check for each read
  • Space amplification: Multiple versions of the same key
  • Write amplification: L0 files with overlapping key ranges
Compaction solves these problems by merging files, removing obsolete data, and maintaining the LSM tree invariants.

How Compaction Works

Compaction merges SST files from one level to the next:

Compaction Process

L0 to L1 compaction merges overlapping L0 files with L1:
L0→L1 compaction is the most expensive because L0 files can overlap with multiple L1 files.

Compaction Styles

RocksDB supports multiple compaction strategies:

Level Compaction (Default)

Data is organized into levels of increasing size:
Pros:
  • Lower space amplification (1.1-1.3x)
  • Predictable read performance
  • Works well for most workloads
Cons:
  • Higher write amplification (10-30x)
  • More background I/O
Best for: General-purpose workloads, read-heavy applications

Universal Compaction

Optimizes for write amplification:
Pros:
  • Lower write amplification (2-5x)
  • Higher write throughput
  • Simpler model (no levels)
Cons:
  • Higher space amplification (1.5-2x)
  • Variable read performance
  • Large compactions can cause latency spikes
Best for: Write-heavy workloads, time-series data

FIFO Compaction

Simple time-based deletion:
Pros:
  • Minimal write amplification (1x)
  • No compaction overhead
  • Simple space management
Cons:
  • No key updates or deletes (append-only)
  • High space amplification
  • Oldest data deleted when limit reached
Best for: Append-only logs, circular buffers, time-series with TTL

Compaction Priority

Control which files are compacted first:

Manual Compaction

Trigger compaction programmatically:
Manual compaction blocks until complete and can take significant time for large databases. Use CompactRangeOptions::exclusive_manual_compaction = false to allow parallel automatic compactions.

Compaction Configuration

Background Threads

Write Stall Protection

Prevent writes from overwhelming compaction:
When limits are exceeded, RocksDB slows or stops writes to allow compaction to catch up. Monitor these triggers to avoid write stalls.

Compaction Size Limits

Compaction Filters

Custom logic to drop keys during compaction:
Compaction filters run on every key during compaction. Keep logic simple to avoid slowing compaction.

Monitoring Compaction

Compaction Statistics

Compaction Events

Optimization Strategies

Optimize for write throughput:

Best Practices

  1. Use level compaction for general-purpose workloads
  2. Monitor L0 file count - too many indicates compaction falling behind
  3. Tune thread count based on CPU cores and I/O capacity
  4. Set appropriate triggers to prevent write stalls
  5. Use compaction filters for application-specific cleanup
  6. Profile compaction with statistics and event listeners
  7. Consider universal compaction for write-heavy workloads
  8. Manual compaction during off-peak hours for large databases

Next Steps

LSM Tree Design

Understand the LSM structure compaction maintains

Architecture

See how compaction fits in RocksDB architecture

Performance Tuning

Advanced compaction optimization techniques

Write-Ahead Log

Learn about WAL file management and compaction