Compression configuration is per column family.

Use to specify the compression to use. By default it is Snappy. We believe LZ4 is almost always better than Snappy. We leave Snappy as default to avoid unexpected compatibility problems to previous users. LZ4/Snappy is a lightweight compression algorithm so it usually strikes a good balance between space and CPU usage.

If you want to further reduce space and have some free CPU to use, you can try to set a heavy-weight compression by setting options.bottommost_compression. The bottommost level will be compressed using this compression style. Usually the bottommost level contains majority of the data, so users get an almost optimal space setting, without paying CPU for compressing all the data at any level. We recommend ZSTD. If it is not available, Zlib is the second choice.

With a countermanded legacy setting options.compression_per_level, you can have an even finer control of compression style of each level. When this option is used, is ignored, while options.bottommost_compression still applies. But we believe there are very few use cases where this tuning will help.

Be aware that when you set different compression to different levels, compaction “trivial moves” that violate the compression styles will not be executed, and the file will be rewrite using the expected compression.

The specified compression type always applies to both of index and data blocks. You can disable compression for index blocks by setting .

Users can choose to compress each SST file of their bottommost level with a dictionary stored in the file. In some use cases, this can save some space. See .

If you pick a compression type but the library for it is not available, RocksDB will fall back to no compression. RocksDB will print out availability of compression types in the header of log files like this:

Check the logging for potential compilation problems.