Skip to main content

Overview

RocksDB supports multiple compression algorithms to reduce storage space and I/O. Compression is applied at the block level and can be configured per-level for optimal trade-offs between space, CPU, and performance.
Proper compression configuration can reduce storage costs by 3-10x while maintaining good read/write performance.

Compression Types

From compression_type.h:18-166, RocksDB supports these algorithms:

Algorithm Comparison

ZSTD (recommended): Best balance of compression ratio and speed for most workloads.

Basic Configuration

Single Compression Type

Per-Level Compression

From advanced_options.h:505-534:
Optimize by using fast compression for hot levels, strong compression for cold levels:
If the vector is smaller than num_levels, the last value is used for remaining levels.

Compression Options

From compression_type.h:169-317, configure algorithm-specific parameters:

Compression Level

From compression_type.h:175-195:
LZ4 negative levels configure acceleration (speed over ratio):

Parallel Compression

From compression_type.h:229-244:
Parallel compression adds overhead. Not recommended for lightweight algorithms like Snappy or LZ4.
Restrictions:
  • Only works with BlockBasedTable
  • Disabled if using partition filters without decoupling

Dictionary Compression

From compression_type.h:200-220, use dictionaries for better compression on small values:

Dictionary Training

Two approaches: 1. ZSTD Trainer (better compression, more CPU):
2. Direct Finalization (faster, less compression):

Dictionary Buffering

From compression_type.h:255-272:
Dictionary building requires buffering SST data in memory. Limit with max_dict_buffer_bytes to prevent excessive memory usage.
Memory is charged to block cache when available:

Compression Ratio Threshold

From compression_type.h:288-299:
Blocks that don’t meet the threshold are stored uncompressed.

ZSTD-Specific Options

Checksum

From compression_type.h:301-307:
Adds a checksum verified during decompression for additional data integrity.

ZSTD Level Guidelines

Bottommost Level Compression

Apply stronger compression to the bottommost level:

Compression Statistics

From statistics.h:251-283, monitor compression effectiveness:
Calculate compression ratio:

Advanced Patterns

Tiered Compression Strategy

Sample-Based Compression Testing

From advanced_options.h:943-947:

Performance Tuning

Write-Heavy Workloads

Read-Heavy Workloads

Balanced Workload

Troubleshooting

Poor Compression Ratio

  1. Check BYTES_COMPRESSION_REJECTED: Too many blocks failing threshold
  2. Enable dictionaries: Helps with small, similar values
  3. Increase compression level: More CPU for better ratio

High Write CPU

  1. Use faster algorithms: Switch from ZSTD to LZ4
  2. Disable parallel compression: May add overhead
  3. Lower compression level:

Slow Reads

  1. Profile decompression time: Check DECOMPRESSION_TIMES_NANOS histogram
  2. Consider lighter compression: Trade space for speed
  3. Increase block cache: Cache uncompressed blocks

Best Practices

Start with ZSTD level 3: Good default for most workloads. Tune based on profiling.
  1. Use per-level compression: Match compression to data temperature
  2. Monitor statistics: Track compression ratio and CPU time
  3. Test with your data: Compression effectiveness varies by data characteristics
  4. Enable dictionaries for small values: Especially effective for similar records
  5. Profile before optimizing: Measure CPU overhead vs. space savings

See Also