Same LZ4 files. Memory-safe. Faster to read at every setting.
LZ4 is the fastest mainstream compression, inside Zarr arrays, GDAL, databases and caches. TurboLZ4 reads and writes the same files as liblz4, byte-for-byte standard LZ4, in memory-safe code, and gives back the same file sizes to within 0.03%.
It exports the LZ4_* and LZ4F_* functions numcodecs/Zarr, GDAL and C/C++ software call. Replace the system liblz4 library; no recompile.
The trade, up front: in the fastest write modes TurboLZ4 is about even with liblz4 on Intel (0.95×–1.04×) and slower on Apple silicon (0.87×–0.97×). Every setting is in the table below.
The 60-second version
LZ4 trades a little size for a lot of speed, and it's read constantly.
LZ4
The go-to compression when speed matters more than the last few bytes: chunked arrays, caches, databases and message queues.
liblz4
The official C library, linked by nearly everything that speaks LZ4. It is the bar any replacement has to clear, on the same data.
Read on every access
LZ4 data is decompressed every time an array chunk, cache entry or record is touched, so read speed is paid for constantly, and a C memory bug sits in every one of those paths.
A memory-safe drop-in
TurboLZ4 writes standard LZ4 that liblz4 reads, reads everything liblz4 writes, and replaces the library without a recompile, faster to read and the same size.
What it means for the bill
Safer, at no cost in speed or storage.
The measured figures, translated.
Illustrative, from the measured Intel figures. A pilot measures yours.
Every setting
Every setting, both machines, nothing hidden.
TurboLZ4 against liblz4 on the same 892 tiles at every setting, from the fastest mode to the smallest. Read and write speed are TurboLZ4 over liblz4 (above 1 is faster); size is TurboLZ4's file against liblz4's. Results below 1 are shown in amber.
| Setting | Read · Intel | Read · Apple | Write · Intel | Write · Apple | Size |
|---|---|---|---|---|---|
| Default | 1.04× | 1.09× | 1.04× | 0.97× | +0.00% |
| Fast, acceleration 3 | 1.04× | 1.12× | 1.00× | 0.94× | +0.00% |
| Fast, acceleration 9 | 1.04× | 1.16× | 0.95× | 0.87× | +0.00% |
| High compression 1 | 1.03× | 1.00× | 1.38× | 1.46× | +0.02% |
| High compression 3 | 1.05× | 1.02× | 0.99× | 0.93× | +0.01% |
| High compression 6 | 1.03× | 1.02× | 1.00× | 0.97× | +0.02% |
| High compression 9 (HC default) | 1.02× | 1.02× | 1.04× | 1.01× | +0.02% |
| High compression 10 | 1.03× | 1.02× | 1.08× | 0.99× | +0.00% |
| High compression 11 | 1.02× | 1.02× | 1.08× | 0.99× | +0.00% |
| High compression 12 (smallest) | 1.03× | 1.02× | 1.08× | 0.98× | +0.00% |
Medians over every tile (256², 512², 1024², 2048²). Inside a setting, a single tile size can fall either side of parity. The weakest single read result is 0.99× on Intel (High compression 9 (HC default), 512² tiles) and 0.99× on Apple silicon (High compression 1, 1024² tiles). Size is identical on both machines.
Your data type
The win column, by data type.
Read and write speed at the default setting, and high-compression level 9 writes, as a multiple of liblz4 on the same tiles. The dashed line is parity; bars past it mean TurboLZ4 is faster.
Medians over every tile size for that data type. Block format; the frame and streaming paths use the same code.
Drops into the pipeline
A library swap. Not a migration.
- - Drop-in C library. It exports the exact LZ4_* and LZ4F_* functions (block, frame, one-shot and streaming, high compression) with a ready-to-use C header. GDAL, numcodecs/Zarr and C/C++ software link it unchanged, proven by a real C program that links the library.
- - Standard LZ4, both ways. Every block, .lz4 frame, streamed frame and high-compression block it writes decodes byte-for-byte through the official C lz4, checked every build on Intel and ARM. It reads everything liblz4 and lz4_flex produce, across an edge-case battery, a fuzz suite and the full imagery corpus.
- - No size trade. File sizes stay within 0.03% of liblz4 at every setting. High-compression levels 10 to 12 include an optimal-parse stage; level 12 matches liblz4's smallest output.
- - Memory-safe. The decoder builds with no third-party dependencies.
- - SIMD backends: AVX2 and NEON, each measured on its own hardware.
How this was measured
- Against liblz4 1.10.0, on Intel (AVX2, 2026-06-08, build 5136196) and Apple silicon (NEON, 2026-06-09, build 58b2c35). The two machines are never divided into one ratio.
- 892 imagery tiles across 13 data types, at 256², 512², 1024², 2048², every setting from the fast modes to high-compression level 12. Each figure is the median of per-tile ratios. Licensed third-party samples are excluded.
- Every output round-trips byte-exact through the official C lz4; both machines produce the same file sizes.
Bring five of your datasets.
A pilot runs both libraries on your own data, on your own machine, at the settings you use. You keep the numbers.
TurboLZ4 is licensed through the Bitruvius Developer Hub and ships as compiled binaries.
LZ4 was created by Yann Collet; the liblz4 library is published under a BSD-2-Clause license, and lz4_flex is an open-source implementation. These names, and references to GDAL and numcodecs/Zarr, are used solely to identify the products, formats, and ecosystems being compared or interoperated with; no affiliation, sponsorship, or endorsement is implied. TurboLZ4 is an independent implementation of the openly published LZ4 block and frame formats; interoperability claims are verified by our test suites. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware. Full third-party notices: Attributions.