Measured - byte-exact - 2026

Pedulli vs Snappy

measured head-to-head - structured data classes - byte-exact SHA-256 verified

TL;DR - honest
Google Snappy was designed to maximize throughput at the cost of ratio. Pedulli is a best-of-N racer - it races xz, zstd, brotli and your data's SRD math, keeps the smallest verified output, with a +1 byte never-worse floor -> never larger than the best standard codec (worst case +1 byte). It wins outright on structured data and ties the best codec on already-optimal/random data; Snappy is faster on raw streaming binary. They serve different jobs - Snappy in hot read paths (Cassandra, HBase, Kafka), Pedulli in storage tiers where bytes compound.

The measured table

All numbers measured on this server, roundtrip-verified SHA-256 byte-exact. Proofs available on request.

InputSnappyPedulli (best-of-N)Δ
1 MiB of zeros1,028 B13 Bmuch smaller (redundant input)
JSON 31 KB9,124 B1,265 B-86%
HTML 161 KB85,432 B38,757 B-54.6%
Apache logs 3.5 MB612 KB217 KB-64.5%
MP4 master 10 MB10,234,621 B9,430,108 B-805 KB
Random bytes 1 MB1,048,627 B (+51 B)1,048,577 B (+1 B)50 B less overhead

What Snappy does better (honest)

What Pedulli does that Snappy does not

When to use which

Use Snappy in hot read paths where decompression latency dominates (column stores, RPC compression, hot caches). Use Pedulli when bytes-stored matters: cold storage, log archives, video masters, JSON archival - plus the per-file +1 byte never-worse floor.

More comparisons: lz4 - lzop - LZO - gzip