Navan built the benchmark table in a Markdown file, because Navan believed that benchmark results that couldn't be read in a plain text editor weren't worth having. Twenty-two rows, one for each Zstd compression level from 1 to 22. Four columns: level, compression ratio, compression speed, decompression speed. The corpus was a representative sample of CXDB blobs—agent conversation turns, tool call payloads, structured output, error logs.
Level 1 was fast and sloppy. It compressed the corpus at 680 megabytes per second but only achieved a 2.1x ratio. Level 22 was thorough and glacial—a 3.8x ratio, but at 4 megabytes per second. Nobody was waiting that long to store a turn.
"The decompression speed is almost constant regardless of level," Navan noted, tapping the column. "That's the Zstd trick. You pay the cost once on write. Reads are always fast."
"So the question is only about write speed versus ratio," Jay said.
"Right. And look at the curve." Navan had plotted it, a simple scatter chart in his notebook, drawn by hand with a straightedge. "Levels 1 through 3, you get massive ratio improvements with minimal speed loss. Level 1 is 2.1x at 680 MB/s. Level 2 is 2.6x at 520 MB/s. Level 3 is 2.9x at 440 MB/s."
"And level 4?"
"Level 4 is 3.0x at 310 MB/s. You gain 0.1x of compression ratio and lose 130 megabytes per second of throughput. The marginal return drops off a cliff after level 3."
Jay studied the chart. The knee of the curve was unmistakable. Levels 1 through 3 climbed steeply—big ratio gains for small speed costs. After level 3, the curve flattened into a long, expensive plateau where each additional point of compression ratio cost disproportionately more time.
"Level 3," Jay said.
"Level 3," Navan confirmed. "At 440 megabytes per second, it's fast enough to keep up with port 9009's throughput without becoming the bottleneck. At 2.9x ratio, we're cutting storage by almost two-thirds. And decompression is 1.2 gigabytes per second regardless, so reads are effectively free."
"What about the content-addressed dedup? Does compression interact badly with CAS?"
"No. We hash before we compress. The BLAKE3 hash is computed on the uncompressed blob, so identical content always produces the same hash regardless of compression. Compression happens after dedup, only on unique blobs."
Jay nodded. "Hash, dedup, compress. In that order."
"In that order." Navan committed the configuration change. One line in the server config: compression_level = 3. The Rust server picked it up on the next restart, and the pack file immediately began growing more slowly.
Level 3. The sweet spot. Not the fastest, not the smallest, but the point where speed and size stopped arguing and shook hands.
The knee of the curve analysis is solid. Level 3 really is the sweet spot for Zstd in most workloads. And hashing before compressing is the right call—anything else breaks CAS invariants.