The arithmetic tells you what the 169:1 is measured against. The projection Uber's team rejected was linear: ten times the retention, ten times the bill, $180K to $1.8M a year [4][3]. HDFS billed per byte, and nobody expected cross-job deduplication to help. Divide the rejected figure by the published ratio and you get about $10,650, which is the "roughly $10K a year" the writeup reports [1]. The ratio carries the whole cost outcome, and it is measured against the already-compressed corpus rather than raw text. Per day of retention, that is $60K before and $333 after [2].
A generic compressor cannot get there by tuning. zstd finds repetition with a sliding window over bytes and entropy-codes the remainder, without knowing which bytes are a timestamp and which are an order ID [8]. CLP splits the line before compression happens: the static template that comes from the call site, the variable values that differ per occurrence, and a dictionary per field type [9]. What reaches the compressor afterwards is a small set of unique templates plus one column per field, and a column of order IDs is far more repetitive on its own than it was interleaved with the prose around it [10]. The dev.to post calls this the Parquet intuition applied to log semantics [11], which is fair: group like with like, then pick an encoding per group.
Which is where 169:1 stops being portable. That number describes Uber's Spark logs, roughly 250,000 jobs a day emitting up to 200TB from a fixed set of call sites in a fixed set of binaries [2]. Template extraction pays in proportion to how many lines share a template. For the ratio to move to your cluster you would need the same shape: a handful of call sites producing most of the volume, variables that are numeric or low-cardinality, and not much free text. A stream dominated by stack traces with distinct frames, user-supplied strings, or JSON carrying UUIDs and base64 has less scaffolding to factor out. The figure worth measuring is unique templates per million lines in your hottest stream, which you can count locally in an afternoon.
The adoption side goes unpriced. The writeup reports the storage outcome and confirms it was lossless, with no sampling and no dropped DEBUG lines [6][7]. It does not quantify CPU at ingest, decode latency on read, or what happens to every tool that assumed it could grep a text file. Those costs land on the platform team, and they are the ones that decide whether the encoder is worth wiring into the write path.
The framing the post argues against, "we need a cheaper log platform," is worth taking seriously as a diagnosis rather than a slogan [12]. Uber's three-day retention was a budget expressed in days [3]. On this evidence, when someone proposes cutting retention, the encoder is the cheaper thing to examine first, and the number that settles the argument is one you own.
