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.
Platform
One recovery contract.
Every workload.
Saar combines content-aware compression, explicit formats, verification and bounded resource limits into one platform. This is where the engine sits, how it behaves and what it has measured.
SAAR v7 objectsSAST v3 streamsExact recoveryBounded limitsEvidence published
Recorded 13-workload audit21 October 2026
87.13%smaller than original bytes
27.48% vs bestExact recoveryComplete outputEvidence linked
Architecture
Where Saar sits in the stack.
Saar is a byte-preserving layer between your data sources and the systems that retain or move them. It does not replace storage, networking or security controls.
Input
Applications
Archives
Streams
Edge and devices
Saar platformRecovery contract
RoutingSelect a strategy for the input class.
SearchCompare eligible candidates under a chosen budget.
VerifyDecode back to the source before acceptance.
PackageEmit a versioned object or ordered stream.
Integrity is checked, not implied
Output
SAAR v7 object
SAST v3 stream
Exact recovery
Measured evidence
Capability contract
What every workload gets.
The same recovery rule applies to text, structured records, media, telemetry, firmware and archives. Only the eligible strategies and the measured outcome change.
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.
The formats carry explicit versions, lengths and integrity checks. Limits are part of the contract rather than undefined behaviour you discover in production.
SAAR v7
Bounded objects up to 16 MiB. Longer inputs are split into independent chunks, never silently truncated.
Object formatSAST v3
Chunks up to 16 MiB with up to 64 workers. SAST v2 remains readable for compatibility.
Stream formatIntegrity checks
SHA-256 envelope and stream transcript checks. These detect corruption; they are not encryption or sender identity.
VerifiedLarge delivery
Resumable, verified part streams with checkpoint continuation; the hosted workspace admits files up to this size. An implemented admission limit, not a throughput claim.
Admission limitObject & stream envelopes
One object-format family supports v7 for compact binary and v6 for stored and general chunks. Streams use SAST v3 with defined headers, footers and ordering.
Exact-recovery rule
A candidate is accepted only after it reconstructs the original bytes; stored bytes bound expansion.
Resource limits
Bounded object sizes, chunk sizes and, where requested, codec heap budgets.
Integrity checks
Envelope and stream digests detect corruption. They are checks, not encryption or sender identity.
Workload coverage
Documented across your kinds of data.
Coverage and measured outcomes are separate facts. Every class enters the same recovery contract; the result depends on the sample and the baseline.
| Workload | Representative inputs | Mode | Measured sample |
|---|---|---|---|
| Text & documents | Documents, RFCs, exports, chat archives | 33 PDF · 36 text | Won · round22-two-cities.txt |
| Source code | Repositories, patches, build scripts | Universal | Won · round22-cpython-typeobject.c |
| Logs & observability | Application logs, traces, audit records | Universal | Won · fixture-app.log |
| Structured data | JSON, CSV, ledgers, tabular exports | 36 structured text | Won · round22-gdp.csv |
| Images | Photographs, scans, diagram files | 27 PNG · 32 raster | Won · earth.jpg |
| Voice & audio | Speech, music, call recordings | 30 WAV | Won · hello.ogg |
| Video | Clips, delivery libraries, captures | Universal | Won · sintel-trailer.mp4 |
| AI models & embeddings | Checkpoints, weights, vector sets | Universal | Won · mobilenet-quant.tflite |
| Game & app assets | Builds, patch payloads, content packs | Universal | Won · Duck.glb |
| Backups & archives | Snapshots, cold storage, exports | 29 ZIP | Won · nibabel-example4d.nii.gz |
Evidence
The results. The data. The method.
Studies identify their workload, revision, baseline settings and limitations. Different studies are kept separate rather than combined into a leaderboard.
Latest measured study87.13% smaller than original27.48% smaller than the best competitor per file · 13 of 13 won · 21 October 2026. Scope and limitations included.
Domain workload audit: 13 workloads
Byte-exact round-trip verified for every file. The complete Saar object is compared per file.
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 87.13% figure is the reduction from original bytes to Saar bytes; the 27.48% figure is the margin over the best competitor 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 for this study.
Files and 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
Size-only study · 13 workloads
Every workload in the domain audit.
These rows are the 13 files behind the 87.13% reduction from original bytes (7.77× compression) and the 27.48% margin over the best competitor per file. Comparative speed was not measured for this study. The speed suites below are a separate dataset.
| Workload file | Input bytes | Saar bytes | Best other | Best codec | Result |
|---|---|---|---|---|---|
| cloud.pcd | 35,650 | 6,856 | 8,244 | brotli -q11 | Won · 16.8% vs best |
| dicom.dcm | 1,890 | 336 | 409 | brotli -q11 | Won · 17.8% vs best |
| fastq.bin | 3,041 | 280 | 333 | brotli -q11 | Won · 15.9% vs best |
| fits.bin | 57,600 | 6,083 | 6,506 | brotli -q11 | Won · 6.5% vs best |
| gdsii.gds | 92,278 | 35,235 | 38,272 | xz -9 | Won · 7.9% vs best |
| graph.bin | 109,261 | 99,495 | 107,692 | brotli -q11 | Won · 7.6% vs best |
| hdf5.h5 | 2,216 | 286 | 291 | brotli -q11 | Won · 1.7% vs best |
| las.bin | 36,437 | 19,096 | 21,740 | xz -9 | Won · 12.2% vs best |
| model.stl | 186,049 | 14,236 | 18,528 | brotli -q11 | Won · 23.2% vs best |
| netcdf.nc | 7,646 | 612 | 645 | brotli -q11 | Won · 5.1% vs best |
| pcap.bin | 1,400 | 264 | 265 | zstd -19 | Won · 0.4% vs best |
| rdb.sqlite | 2,899,968 | 260,216 | 407,540 | xz -9 | Won · 36.1% vs best |
| seismic.sgy | 14,600 | 746 | 1,460 | xz -9 | Won · 48.9% vs best |
| 13 files | 3,448,036 | 443,741 | 611,925 | Best per file | 87.13% smaller than original · 27.48% vs best · 13 won |
Development evidence: not a fresh holdout, not an independent certification and not a claim about files that were not measured. Full method and limitations are in the audit record.
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.
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 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.
Fast profile on the local reference: 2674.7 MB/s at 8 threads (21 October 2026, one machine). Scoped numbers and limits →
Throughput, scoped
More threads. One stated machine.
This is a local-reference measurement, not a cross-hardware benchmark. Compare it with your own environment and acceptance criteria.
Three independent runs, three repeats per thread count. The current median peaks at 8 threads, about 5.5× the single-thread result; 10–14 threads did not improve the median because the main thread serialises stdin/stdout I/O. Matching, not entropy coding, is the per-core cost. The only meaningful baseline is your own environment.
Deployment and access
Start where the work is.
Access is scoped by surface and evaluation. The public site does not imply a private, sovereign or regulated deployment that has not been agreed in writing.
Hosted workspace
Run jobs, manage retention and restore outputs from the portal. Access is account-scoped and subject to the published evaluation terms.
Native CLI and C API
Embed the checked C11 library or use the native command line for bounded objects and streamed workloads.
TypeScript API
Use the compressor and stream helpers in Node.js. Public package distribution is not currently enabled.
Enterprise and government
Licensing, deployment and procurement are scoped in writing. No private or sovereign deployment is implied by a plan name.
Integration surfaces
Meet Saar where you already work.
The recovery guarantee is identical across surfaces. Only the calling convention and distribution status change.
Native C API
Embed the checked C11 library or use its native command-line interface. Object calls are bounded; use the stream CLI for larger inputs.
TypeScript API
Use the TypeScript compressor and stream helpers directly in Node.js applications. Published package distribution is not currently enabled.
Native CLI
Pipe objects and SAST streams through the checked native executable, with exact output verification and explicit resource limits.
Bring your workload. Keep the result.
A baseline is your current codec on your representative environment. Start with a short evaluation brief or review the enterprise and trust material first.