Compression Trade-offs

WiredTiger compresses data at the page level, not the document level. When a page is written to disk (during checkpoint or eviction), it is compressed. When read from disk into cache, it is decompressed. Data in the WiredTiger cache is always uncompressed. This means compression affects only disk I/O and storage size, not in-memory operations.

The default compression algorithm is Snappy for data and prefix compression for indexes.

Compression Algorithms

Snappy (default): Designed for speed over compression ratio. Compresses telemetry data at approximately 2.5:1. Decompression is nearly free: 500 MB/s on modern CPUs. Compression cost: 200 MB/s. The algorithm never wastes CPU trying to squeeze out the last few percent of compression.

Zstd (zstandard): Offers significantly better compression than Snappy with moderate CPU cost. Compresses telemetry data at approximately 5:1. Decompression: 400 MB/s (nearly as fast as Snappy). Compression: 100-200 MB/s depending on compression level. Available since MongoDB 4.2.

Zlib: The oldest option. Higher CPU cost than both Snappy and Zstd with compression ratios between the two. Compression: 80 MB/s. Not recommended for most workloads since Zstd achieves better ratios at lower CPU cost.

None: No compression. Data is written to disk in its uncompressed B-tree page format. Zero CPU overhead for compression. Maximum I/O bandwidth consumption. Useful only when CPU is the bottleneck and storage is plentiful.

# mongod.conf - collection-level compression
storage:
  wiredTiger:
    collectionConfig:
      blockCompressor: zstd
    indexConfig:
      prefixCompression: true

Per-collection compression can be set at creation time:

database.createCollection("readings",
    new CreateCollectionOptions().storageEngineOptions(
        new Document("wiredTiger",
            new Document("configString", "block_compressor=zstd"))
    ));