Same zstd wire. Memory-safe.
A memory-safe SIMD-optimized Zstandard encoder + decoder. RFC 8478 wire-format compatible - encoder output decodes via libzstd and ruzstd byte-for-byte. Every sample in our benchmark corpus round-trips cleanly through the reference libzstd - on both AVX2 and NEON, single- and multi-threaded.
Drop-in for libzstd (Facebook reference C zstandard, RFC 8478). SIMD backends: AVX2, NEON. ABI-level shim exports the ZSTD_* symbols GDAL, libtiff, rasterio, Zarr, Python zstandard, and Java zstd-jni import — replace the system libzstd binary, no recompile.
Headline
Faster encode from L5 up. Faster decode almost everywhere. Memory-safe drop-in.
Stated plainly, because honest benchmarks are the whole point: TurboZstd encodes faster than libzstd from level 5 upward — the lead grows through L5 and L9 and reaches several-fold at the archival L19–L22 levels — and decodes faster at every level except L1, where it sits at parity. The trade-offs we don't bury: at L1 and L3 the single-thread encoder is slower than libzstd's (those levels are already microseconds-fast, and at L1 we spend that time on a smaller file); and at the maximum-compression L19–L22 levels — plus optical at every level and AI-mask imagery above L1 — output runs a few percent larger, where libzstd's deeper match-finder still leads. We're smaller at L1 and L9, competitive in between. The win column differs by data type — find yours in the per-domain charts below.
than libzstd on AVX2 (L5 1.35×, L9 1.94×) at parity-to-smaller size — L9 lands 2.3% smaller. This is the crossover where we pull ahead on speed without giving up compression.
than libzstd on AVX2 (L19 5.64×, L22 11.23×). The trade-off, stated: archival output runs ~4% larger aggregate, where libzstd's deeper match-finder still leads.
than libzstd-ZSTDMT (par-vs-par) on NEON at L22 — libzstd's multi-thread barely parallelizes archival job sizes while encode_all_par splits cleanly (sar_vid 74×, most raster domains 16-40×).
L1 just below parity (0.97×), then ahead from L3 up — 1.10× at L3 to 1.28× at L22. NEON decode trails today (0.77-0.99×); that's Mac's lane and closing.
Every row of the 9-domain corpus round-trips clean through the reference libzstd — AVX2 and NEON, single- and multi-thread. The output is real RFC 8478 zstd.
Throughput at-a-glance
Several-fold faster on archival. Decode wins from L3 up.
Single-thread encode and decode vs libzstd across the 804-sample corpus. The encoder is slower than libzstd at L1-L3 - those levels are already microseconds-fast - then pulls ahead at L5 and wins several-fold at the archival L19/L22 levels. The decoder sits at roughly parity at L1 on AVX2 (0.97×) and wins from L3 upward. The multi-thread (parallel) view is the next chart; the per-domain breakdown is further below.
Speed vs libzstd by compression level
Log Y-axis so the full dynamic range fits - sub-1× on L1-L3 encode through several-fold at L22 encode. Dashed = NEON; solid = AVX2.
Multi-thread throughput at-a-glance
Parallel: we beat libzstd's own multi-thread from L3 up.
The deployed config for tiled raster: encode_all_par against libzstd's own ZSTDMT at the same worker count (8). TurboZstd's parallel encoder beats libzstd's multi-thread from L3 upward, and the lead compounds at archival sizes — AVX2 reaches 43× at L22, NEON 39× — because ZSTDMT barely parallelizes archival job sizes while encode_all_par splits cleanly. L1 trails in both (ZSTDMT barely-compresses fast there). NEON trails AVX2 in raw magnitude but wins the identical shape.
Parallel encode throughput vs libzstd ZSTDMT (8 workers)
encode_all_par vs libzstd ZSTDMT, 8 workers, par-vs-par. Our labeled corpus (16/domain; NEON L22 n=8), TurboZstd v0.0.4, 0 par-interop failures. Log Y-axis; dashed = NEON, solid = AVX2. Parallel is encode-only.
New in v0.0.4 · Negative levels
Throughput-first "fast" levels. Faster encode and decode, near-parity size.
TurboZstd now supports the full libzstd negative range (-1 … -131072) — the throughput-first tier that trades a little ratio for speed. On AVX2 it wins encode throughput at every negative level (1.19× → 1.47×) and decodes faster (1.17× → 1.31×), at near-parity size (+0.2% to +1.0% aggregate — byte-identical across both ISAs). On NEON, decode is the story — competitive-to-winning from -5 up (hyperspectral decode hits 2.0×); NEON negative-encode trails libzstd here (the compute-bound Apple-silicon finder — that encode win is AVX2-specific). Per-domain, hyperspectral/multispectral/RGB/quicklook/SAR-video lead; AI-inference and optical are the slower-at-shallow exceptions (optical also trades more ratio on the generic path). Output round-trips through the reference libzstd in both directions across the full range — zero interop failures.
Negative-level throughput vs libzstd (single-thread)
Single-thread, our labeled corpus (16 samples/domain, median), TurboZstd v0.0.4, 0 interop failures. Log Y-axis; dashed = NEON. NEON negative-encode trails (compute-bound) and is omitted to avoid implying a win it doesn't have — NEON is shown via its decode strength; see text.
Per-domain ROI
Your data type. Your win column.
Compression ratio and throughput against libzstd for each data type we benchmark. AVX2 (Intel Arrow Lake) and NEON (Apple M3) shown side-by-side; multi-thread shows TurboZstd's encode_all_par against libzstd's ZSTDMT with the same worker count. Above 1× = TurboZstd faster. Positive size = TurboZstd smaller.
AI Inference
Model inference output tensors (asphalt, vegetation, etc.)
Digital Surface Models
LiDAR-derived terrain elevation grids
Hyperspectral Imagery
100+ narrow spectral bands per pixel
Multispectral Imagery
Landsat / Sentinel-2 multi-band raster
Optical Imagery
RGB satellite + aerial photography (DOQQ, NAIP)
RGB Orthoimagery
High-resolution ortho-rectified RGB tiles
SAR CSI SLEDP
Synthetic-aperture radar complex single-look data
SAR CSI Quicklook
SAR amplitude quicklooks for browse imagery
SAR VID SLEDP
Video synthetic-aperture radar frames
Measured on the full Bitruvius corpus - 804 samples across nine diverse imagery types - single- and multi-threaded, on Intel (AVX2) and Apple Silicon (NEON). The multi-threaded figures run both TurboZstd and libzstd at 8 threads.
Why switch
A library swap. Not a migration.
- - Size where it's read most: ~5% smaller at L1, ~2.3% smaller at L9 aggregate, with parity through L3-L5; several domains post double-digit L1 wins (dsm 16.5%, sar_csi 11.5%). The honest trade: archival L19-L22 and optical/AI-mask imagery run a few percent larger.
- - Archival single-thread: 5.6× / 11.2× faster than libzstd on L19 / L22 (AVX2). Per-domain peaks: dsm L19 7.33×, ai_inference L22 22.4×, sar_vid L22 14.4×.
- - Archival multi-thread:
encode_all_parextends the lead far past single-thread — per-domain L22 runs 7-74× over libzstd-ZSTDMT on NEON (sar_vid 74×, most raster domains 16-40×). - - L9 multi-thread runs ~3.1× over libzstd-ZSTDMT (NEON, par-vs-par) at ~2% smaller output;
encode_all_parbeats libzstd's own ZSTDMT from L3 up (1.21× → 38×), while L1 still trails in both modes. - - Memory-safe: no C build dependency on developer workstations, CI runners, or customer build farms.
- - Permissive licensing chain: TurboZstd is independent (RFC 8478 only, no libzstd code) — binary attribution graph is just LICENSE + NOTICE.
- - Deterministic output: same input + same level always yields the same bytes, and the parallel encoder is worker-count-invariant (1 thread or 16, identical output) - so content-addressed dedup and cache keys stay stable.
Compatibility
Bit-exact on the wire.
- - RFC 8478 frame format — any libzstd / ruzstd / zstd-cli consumer accepts TurboZstd output unchanged.
- - Real Niantic SPZ point-cloud payloads (hornedlizard, racoonfamily) compress at L3 and round-trip byte-for-byte through the reference libzstd - validated every run.
- - Per-level single-thread size (aggregate): ~5% smaller at L1, ~2.3% smaller at L9, parity through L3-L5; L19/L22 a few percent larger - the trade for several-fold encode speed.
- - Every sample in the 804-sample corpus round-trips cleanly via the reference libzstd; zero failures across AVX2 + NEON, single-thread + multi-thread.
- - ISAs: AVX2 (x86_64) and NEON (ARM64), each benchmarked on its own native hardware with full per-ISA result artefacts.
libzstd.
Just faster, safer.
Existing pipelines, existing data, existing tooling. Swap the implementation, keep everything else.
Zstandard, zstd, and libzstd are products of Meta Platforms, Inc. References here identify the products and formats being compared; no affiliation, sponsorship, or endorsement is implied. libzstd is published by Meta under a dual BSD-3-Clause / GPLv2 license. The Zstandard frame format is openly specified in RFC 8878 (which obsoletes RFC 8478) and freely usable. TurboZstd is an independent, clean-room implementation of that specification. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware.