Network (wire) compression
Parent: Storage and Data-Lifecycle Cost Levers · Published reference · snapshot 2026-10-30
↓ Facts as markdownall context files
Source-anchored research for Network (wire) compression. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- Compression is not automatically a net performance improvement: evaluate network savings alongside client and database CPU, throughput, and response time under representative load. MongoDB warns that compression trades bandwidth for CPU. (high confidence) [source]
How it works
- Wire compression reduces driver-server message bytes and can lower Atlas data-transfer charges; performance benefits are especially relevant when network bandwidth constrains the workload. (high confidence) [source]
Measurements and reference values
- MongoDB's July 2026 synthetic M50 study used roughly 51 KB documents and separate read, write and mixed workloads. Its mixed-workload table shows higher throughput without compression than with zstd, illustrating that bandwidth reduction can accompany a throughput loss. (low confidence) (verified as of 2026-07-08) [source]
- Already-compressed payloads may provide little bandwidth reduction: Google reports approximately 1.0x Snappy compression for JPEGs, PNGs, and other compressed input in its benchmark suite. This is a codec benchmark, not a MongoDB workload measurement. (low confidence) [source]
- MongoDB's July 8, 2026 study used synthetic roughly 51 KB documents on an Atlas M50 replica set. Its mixed-workload table reports higher operation throughput without compression than with the compressed configurations, despite lower network use with compression. These results scope claims that compression always increases throughput. (low confidence) (verified as of 2026-07-08) [source]
Problems, failure modes and limitations
- If client and server have no common compressor, the specification requires the client to continue without a compression-negotiation error. Negotiation therefore does not guarantee compressed traffic. (low confidence) [source]
Comparisons and alternatives
- Percona's March 2025 article reports approximately 2.33 MB/s outbound without compression versus about 1 MB/s with zstd for its simple-find experiment; this is a workload example, not a general savings estimate. (low confidence) (verified as of 2025-03-03) [source]
Facts and statements
- Wire compression reduces client-server transfer volume and can lower costs on charged network paths; it is distinct from storage block compression. (medium confidence) [source]
- Drivers negotiate compressors during the handshake and choose the first client-preferred algorithm also supported by the server; no common algorithm permits an uncompressed connection. (medium confidence) [source]
- An explicit connection-string compressors list enables driver compression, for example compressors=zstd,snappy,zlib; the wire-compression specification defaults to no configured compressor. Check the actual driver and application configuration before assuming compression is active. (high confidence) [source]
- Snappy prioritizes speed over maximum compression. Its upstream benchmarks show input-dependent ratios and little reduction for already compressed JPEG or PNG payloads. (low confidence) [source]
- The Java driver accepts compressors in its connection URI; Snappy and Zstandard require their respective Java dependencies, while zlib is built in. (low confidence) [source]
- The wire-compression specification excludes hello and authentication-related commands from client compression, and permits uncompressed responses even after negotiation. Do not assume every message on a compressed connection is compressed. (low confidence) [source]
- SERVER-79842 recorded that network.compression counters combined application and replication traffic, preventing application-only attribution from those counters; the issue was resolved Won't Fix in August 2023. (low confidence) (verified as of 2023-08-18) [source]
- Drivers advertise compressors during the initial handshake and use the first client-preferred algorithm supported by the server for requests; configuring a list is a preference order, not simultaneous use of multiple algorithms. (high confidence) [source]
- Snappy prioritizes speed over maximum compression. MongoDB recommends it for latency-sensitive applications, and Percona describes it as a low-overhead choice that generally compresses less than zstd or zlib. (high confidence) [source]
- The zlibCompressionLevel setting ranges from -1 to 9; higher levels favor smaller requests over compression speed. The specification applies this setting to client compression, not server response compression. (high confidence) [source]
Children
- Compressor negotiation and fallback (frontier)
- Payload compressibility (frontier)
- Client and server compression CPU cost (frontier)
- Compression observability and billing attribution (frontier)
Frontier under this node: Client and server compression CPU cost, Compression observability and billing attribution, Compressor negotiation and fallback, Payload compressibility