Three native profiles
Choose your search budget.
Fast bounds the work. Ratio compares fast with PPM. Full searches the active native encoder families and keeps the smallest eligible, verified candidate.
Product
One recovery contract.
Everything it delivers, on one page.
What Saar guarantees, what it costs in time and what it has measured. It also explains how to compare Saar fairly. The customer workspace runs jobs; this page is the full public picture.
Capability contract
What every workload gets.
One byte-preserving contract across text, structured records, media, telemetry, firmware and archives, with their actual limits.
Sparse-byte representation
A route for zero-heavy data.
The sparse mode is an eligible candidate in the native and TypeScript full tournaments. It is kept only when its complete verified frame is smaller than the alternatives.
SAAR v7 objects
A complete object, not a loose payload.
The container records the original length, metadata, payload and an SHA-256 envelope digest. When compression does not help, stored bytes remain a valid fallback.
SAST v3 streams
Bounded chunks. Parallel batches.
The native CLI processes chunks independently, verifies the ordered stream transcript, and can run chunk batches on multiple workers. This is an architecture capability. It is not a TB/s claim.
Exact recovery
Return the original bytes.
Lossless means byte-for-byte recovery. Saar checks decoded output before accepting encoded candidates; container and stream checks detect corruption, not sender identity.
Formats and limits
Bounded by design.
SAAR v7
Bounded objects of up to 16 MiB. Longer inputs are split into independent chunks, never silently truncated.
SAST v3
Chunks bounded at 16 MiB with up to 64 workers. SAST v2 remains readable for compatibility.
SHA-256 envelope and stream transcript checks
An envelope digest and an ordered stream transcript detect corruption. They are not encryption, authentication or sender identity.
Up to 5 TiB
Resumable, verified part streams with checkpoint continuation; the hosted workspace admits files up to this size. An implemented admission limit, not a throughput claim.
The original bytes
A successful decode reproduces the source exactly. When compression does not help, the stored frame is still a valid, fully recoverable object.
Throughput, scoped
Fast profile: 528 MB/s per core and 2982.8 MB/s at 10 threads on the local reference (17 October 2026). The full profile trades time for size. On compressible text, it measures tens of KB/s, so it is for archived data rather than interactive paths.
Throughput, with the machine stated
Fast tier: 2982.8 MB/s at 10 threads.
Recorded 17 October 2026 on Apple M4 Max, 36 GB (macOS arm64) · 249 MiB input, 4 MiB chunks unless stated. Single machine, single workload, development evidence. Not a cross-hardware, production or competitor-leadership claim. The only baseline that counts is your current codec on your machine.
528 MB/s
Scaling tops out near 5.6× on 10 threads despite 14 available: the main thread serialises stdin/stdout I/O. Opaque bytes encode at 2.3 GB/s per core. Matching, not entropy coding, is the per-core cost.
2982.8 MB/s at 10 threads
Thread scaling: 1t 528.5 MB/s · 2t 964.5 MB/s · 4t 1684.7 MB/s · 6t 2231.7 MB/s · 8t 2669.6 MB/s · 10t 2982.8 MB/s · 12t 2698.5 MB/s · 14t 2920.6 MB/s.
Choose speed or size per workload
At 14 threads, 2 MiB chunks peak at 2504.8 MB/s; 16 MiB chunks are 21% smaller but 22% slower. Chunk size is a speed-vs-size choice per workload.
Tens of KB/s
The full compression profile trades time for size. Context mixing measured 43–275 KB/s on compressible text in the 18 October records, while stored-fallback media runs faster. This profile suits archived, rarely-read data. The fast profile is the speed-first tier.
Test it here
The bounded live comparison.
Send at most 32 KiB of non-confidential bytes to the server. The server compares Saar with Brotli, gzip and DEFLATE, and requires exact recovery. Inputs and results are not persisted.
PORTAL EVALUATION LAB
Your bytes.
A measured comparison.
Run Saar v7 · TypeScript fast against Brotli · quality 5, Brotli · quality 11, gzip · level 9, DEFLATE/zlib · level 9 on the same input. Results are generated when you run the test; this is a bounded evaluation, not a stored-corpus benchmark report.
Maximum input 32,768 bytes · Not the native ratio/full profile; other codecs and larger workloads remain in recorded reports.2,100 input bytes
Recorded evidence
The results. The data. The method.
Browse recorded comparisons by study. Each report identifies its workload, revision, baseline settings and limitations. Different studies are not combined into one leaderboard.
Latest measured study15.65% smallerin aggregate vs the best competitor per file · 13 of 13 won · 15 October 2026
Domain workload audit: 13 workloads
Byte-exact round-trip verified in TypeScript for every file; the modes exercised are cross-decoded by the native C reader in the engine's interop tests.
The structured & scientific subset of 7 files runs 17.12% smaller.
Files, scope & limitations
model.stl · rdb.sqlite · gdsii.gds · graph.bin · cloud.pcd · las.bin · fits.bin · seismic.sgy · netcdf.nc · dicom.dcm · fastq.bin · hdf5.h5 · pcap.bin
Thirteen public and synthetic workload samples measured against the best recorded output of gzip -9, bzip2 -9, zstd -19 --ultra, brotli -q11 and xz -9 on one host. The complete Saar object is compared per file. Development evidence: not a fresh holdout, not an independent certification, and not a claim about files that were not measured. Comparative speed was not measured.
9 files in this set5.94 MiB selected input5 measured codecsOct 18, 2026
Current native revision re-measured on 18 October 2026 over the frozen round31 file set. Whole-command CLI method for every codec; output frame sizes are deterministic and match earlier revisions.
Nine previously acquired public binary/media/model files, each at most 16 MiB; not freshly curated and not an independent leaderboard. Process launch and pipe transfer are included and dominate small files, so aggregate speeds understate in-process codec throughput. The large-stream tier is published separately on /product. Peak memory was not measured. Results support this workload set only.
Saar CompetitorsRecorded results · All three metrics use the same selected files
Compression ratio
Original size ÷ encoded size
×Higher is better ↑
Encoding speed
Original bytes processed per second
MB/sHigher is better ↑
Decoding speed
Original bytes recovered per second
MB/sHigher is better ↑
Compression ratio = total original bytes ÷ total encoded bytes (1× means no size change). Aggregate speed = total original bytes ÷ sum of per-file times, in decimal MB/s. Peak RSS = maximum recorded per-file child decode RSS. Recorded comparisons are not a live feed or an independent ranking. Compare within each set; different revisions and datasets are kept separate.
| Codec / setting | Output bytes | Compression ratio | Output / source | Encode MB/s | Decode MB/s | Peak decode RSS | Exact recovery |
|---|---|---|---|---|---|---|---|
| Saar fast | 5,814,072 | 1.071× | 93.37% | 55.21 | 78.06 | Not measured | Verified |
| Brotli -q 5 | 4,410,518 | 1.412× | 70.83% | 52.07 | 81.91 | Not measured | Verified |
| Zstandard -1 | 4,502,426 | 1.383× | 72.31% | 93.82 | 108.22 | Not measured | Verified |
| Zstandard -3 | 4,435,315 | 1.404× | 71.23% | 89.65 | 109.93 | Not measured | Verified |
| LZ4 -1 | 5,838,144 | 1.067× | 93.76% | 103.38 | 108.54 | Not measured | Verified |
Test context & limitations
Hardware reference. All Saar timing is measured on a single local development reference machine (currently Apple M4 Max, 36 GB, macOS arm64). It is never a world baseline and is not a cross-hardware comparison; the only meaningful baseline is your own current codec on your own representative environment.
Environment. macOS-27.0.1-arm64-arm-64bit-Mach-O
Trials. One warmup, then seven rotated serial whole-command trials per codec and file. Charts sum the per-file medians.
Limitations. Nine previously acquired public binary/media/model files, each at most 16 MiB; not freshly curated and not an independent leaderboard. Process launch and pipe transfer are included and dominate small files, so aggregate speeds understate in-process codec throughput. The large-stream tier is published separately on /product. Peak memory was not measured. Results support this workload set only.
Report SHA-256. 9c78eaf9f8294049f2d0388b5d5120f012803e49d1cefbb709cd2de81f999308
- Brotli
- brotli 1.2.0
- Zstandard
- Zstandard CLI 1.5.7
- LZ4
- LZ4 CLI 1.10.0
These are HEOSSI’s internal measurements, not an independent certification, standards approval or industry ranking. Different suites use different encoder revisions and must not be merged into one leaderboard.
EXTERNAL BENCHMARK SOURCES
Independent context. At the source.
External results use different hardware, data and methods. They are not directly comparable with Saar’s internal runs. Saar has no independently verified ranking on these sources.
OpenBenchmarking.org ↗Public lzbench test profile and community results; opens the provider websitelzbench ↗In-memory multi-codec benchmark harnesslzbench result explorer ↗External charts; historical dataset, not a live Saar feedAIT Data Compression Challenge ↗Independent lossless compression leaderboard
On-demand GitHub repository metadata. This is not a live compression result or a Saar ranking.
RECORDED STREAM VERIFICATION
Beyond a single file.
Every byte recovered.
Recorded 11 October 2026 (SGT). Generated test input, recovered exactly in two interoperability checks.
4.29 GB4,294,967,419 original bytes → 4,294,967,419 recovered bytes
Historical stream verification, not a natural-data benchmark or a TB/PB capacity test. Encoded size was not recorded, so no compression ratio is claimed for this test.
Want to compress real files?
The workspace runs full jobs.
The live comparison is capped at 32 KiB. The customer workspace runs complete compression and restore jobs on your account, keeps results private and retains outputs for 7 days.
Comparison
Compare us the way an engineer would.
We publish results against Brotli, Zstandard, gzip, XZ and LZ4, including workloads where they win. Six rules make a comparison mean something.
One corpus, many codecs
Every codec compresses the identical bytes. No warmed cache for one and not another, no different file set.
Compare complete containers
Measure the full emitted frame, including headers, metadata and integrity envelope. Do not use payload-only figures.
Decode must return the source
A size win only counts if the decode reproduces the original bytes exactly. That is the contract, for every codec.
Speed is hardware-specific
Throughput means nothing without the machine, runtime and settings. The only baseline that counts is yours.
Name the profiles and levels
Brotli -q11, zstd -19, xz -9 and LZ4 -1 target very different trade-offs. Compare like with like, and say which.
The winning test is your corpus
Published results are direction, not destiny. The decisive comparison is your representative data against your current codec.
Where each one wins
The honest split.
A comparison that only shows our strong side is marketing. These are the categories where we are built to win, and the ones where a standard codec is the better tool.
Where Saar is built to win
- Structured and scientific records where savings compound and recovery must be exact.
- Telemetry, logs and event streams handled as bounded, ordered, checked chunks.
- Archives and cold storage where byte reduction offsets cost and reads are rare.
- Zero-heavy and sparse data, kept only when the sparse candidate verifies smaller.
Where the standard codec wins
- Already-compressed media may offer little additional saving. Measure the actual files; data at its entropy limit cannot be made smaller losslessly.
- Ultra-low-latency hot paths that need LZ4-class speed on near-incompressible data.
- Zero-dependency, ubiquitous tooling already in your stack, with no evaluation step.
- A universal win: no codec leads on every workload, including ours.
The only comparison that counts
Your codec, your data, your machine.
A baseline is the workload’s own current codec, measured on your representative environment. Not our development laptop, and not a published table.
Export a representative sample
Real files from the workload you are actually deciding on.
Run both, same machine
Your current codec and Saar, identical input, whole containers, exact recovery.
Decide on the numbers you produced
Keep the result either way. It is your data and your call.
Platform status
Current runtime evidence covers macOS and Linux. Windows has a serial code path but has not completed the runtime acceptance matrix. Signed public artifacts and independent security review are pending. Nothing here is presented as a shipped product.
Next step
Your data. Your criteria. Your call.
31 workload classes share this contract, and each one carries a dated measurement against the strongest available standard codec. Wins and losses are both published on the coverage table. Bring a representative workload and decide on evidence.