// infrastructure
M.I.K.E.
M.I.K.E.
Some data isn't compressed. It's a puzzle waiting to be solved.
MIKE pairs a new idea, the puzzle compressor (patent pending), with the best of classic compression, and autotunes the mix for every block it sees. On 60 real files it removes 64.8% of the bytes. The strongest rival we could find removes 36.6%. Every result restores byte for byte.
--powerbest rival (zpaq -m5): 36.6%
against seven rivals at max
--fast than 0.17.9,same output
cold storage · deep archive
Classic compressors pack the bytes. The puzzle compressor finds the rule that made them.
Every mainstream tool, from ZIP to zstd, does the same thing: find repeats, then entropy-code what is left. That approach has a hard floor. MIKE adds a second one. If the data came from a rule (a counter, a polynomial, a recurrence, a sampled signal, a table of numbers), the shortest way to store it is the rule itself. The puzzle compressor recognises the generator, stores the formula and the few values it cannot predict, and on restore runs the formula to get every byte back.
The best rival, zpaq at its strongest setting, saves 48.5% on the same files. xz saves less. That is the puzzle compressor alone: no other tool looks for the rule.
Office files, PDFs, PNGs and gzip archives are already compressed, so classic tools get almost nothing from them. MIKE unpacks them, codes the contents, and on restore rebuilds the original container byte for byte. The same goes for JPEG and MP3 internals, and for whole virtual disks (VMDK, OVA, qcow2, raw), which it reads file by file through ext4, XFS, NTFS and LVM2.
Puzzle or classic? MIKE tries both, block by block, and keeps the winner.
No single method wins on all data. So MIKE doesn't pick one. For each block it runs the candidates side by side: the puzzle compressor, the specialists that reopen known formats, and the classic coders (LZ matching, Huffman and arithmetic coding, context mixing). It keeps whichever result is smallest and decodes back exactly. The mode you choose sets how many candidates it is allowed to try. Because the plain classic coder is always among them, MIKE never does worse than storing the data plainly, plus a few bytes of header.
The puzzle compressor wins: formulas plus residuals.
Reopen the ZIP container, then classic coding on the XML inside. Best rival: 1.2%.
Context mixing wins: a text model predicting each bit from what came before.
// saved share at --power on the 60-file set below · the mix is chosen per block, so one file can use all three
MIKE is smallest on 58 of 60 files.
Documents, PDFs, photos, archives, text, code, tables and numeric series, 15.4 MB in all. Every rival ran at its strongest setting, one job at a time, on a low-spec VM (2 vCPU, 4 GB). Every MIKE result was decoded and compared byte for byte.
// share of the 15,378,200 bytes removed · longer bar = smaller output
| Tool | Saved | Smallest on |
|---|---|---|
| gzip -9 | 29.0% | – |
| bzip2 -9 | 29.0% | – |
| zstd --ultra -22 | 31.5% | – |
| Brotli q11 | 32.5% | – |
| 7-Zip -mx=9 | 33.1% | – |
| xz -9e | 33.2% | – |
| zpaq -m5 best rival | 36.6% | – |
| MIKE --fast | 44.9% | 5 / 60 |
| MIKE default | 61.1% | 50 / 60 |
| MIKE --power | 64.8% | 58 / 60 |
| MIKE --extreme | 64.8% | 59 / 60 |
| File type | Best rival | MIKE default | MIKE --power |
|---|---|---|---|
| Numeric series | zpaq 48.5% | 97.9% | 97.9% |
| Office (docx/xlsx/pptx/odt) | zstd 1.2% | 24.9% | 40.1% |
| zpaq 20.8% | 43.6% | 45.4% | |
| JPEG photos | zpaq 7.0% | 20.1% | 21.7% |
| CSV table | zpaq 87.6% | 90.0% | 90.5% |
| Prose & Markdown | zpaq 76.2% | 73.9% | 77.2% |
| HTML / XML / SVG / JSON | zpaq 89.1% | 89.0% | 90.6% |
| gzip archives | xz 2.7% | 88.5% | 88.8% |
| Source code | zpaq 86.4% | 85.5% | 87.8% |
| PNG | Brotli 56.9% | 82.8% | 91.0% |
| MP3 | Brotli 4.2% | 4.5% | 6.8% |
| H.264 clip | Brotli 44.2% | 43.6% | 43.5% |
// green = MIKE beats the best rival on that type · MIKE rows measured with the 0.17.11 engine on 2 Nov 2026; 0.17.12 codes these files the same or smaller · rival rows from the same VM and files
Machine and access logs: at --power, about half the size of xz -9e.
A real public web-server access log (the NASA HTTP trace, 32 MB) and a Linux system journal (3.6 MB), same VM. New in 0.17.12: big text is coded in chunks the text model can take, on every core, where before it fell back to the classic coder.
| Tool | Access log | System journal |
|---|---|---|
| xz -9e | 2,029,276 94.0% | 134,168 96.2% |
| zstd -19 --long | 2,149,774 93.6% | 159,433 95.5% |
| 7-Zip -mx=9 | 2,233,187 93.3% | 158,775 95.5% |
| zpaq -m5 best rival | 1,083,933 96.8% | 84,368 97.6% |
| MIKE --fast | 2,236,166 93.3% | 158,992 95.5% |
| MIKE default | 1,712,611 94.9% | 158,992 95.5% |
| MIKE --power | 1,101,575 96.7% | 60,354 98.3% |
// output size, share saved in brackets · all MIKE results restored byte-exact
VM disks and backups: smaller than xz -9 in every format.
MIKE opens the disk, reads the filesystem, and codes each file by kind. VMDK, OVA and qcow2 are
reopened to the same virtual disk, so the container format stops mattering. Disks stream through in
bounded parts, so memory is set by how many parts are in flight, not by the disk size: under 1 GB at default on every disk here, up to 734 MB, and 1.7 GB at --power.
| Disk | xz -9 | MIKE default | MIKE --power |
|---|---|---|---|
| ext4, raw 100 MB disk, 70 MB in use | 20.33 MB | 19.07 MB | – |
| same disk as OVA VMDK, stream-optimised | 29.29 MB | 19.09 MB | – |
| same disk as qcow2 compressed clusters | 30.85 MB | 19.08 MB | – |
| XFS 99 MB of files | 29.12 MB | 27.54 MB | 23.08 MB |
| NTFS 99 MB of files | 30.56 MB | 27.53 MB | 22.90 MB |
| LVM2 volume group | 39.83 MB | 33.79 MB | 28.23 MB |
// every result restored byte-exact · – = not measured on that disk yet
Smaller and faster at once.
Same 60 files, same 2-vCPU VM, each version as released. Usually a compressor trades speed for size. Across the 0.17 line, MIKE got smaller and faster.
15.7 s in 0.17.9, 4.1 s now, byte-identical output. Decompress 0.4 s.
0.17.2 took 78.8 s to save 57.6%. Now 38.4 s saves 61.1%.
57.7% in 0.17.2, 64.8% now: a new text and code model, layout rules, an x86-64 model.
| Version | Level | Saved | Compress | Decompress |
|---|---|---|---|---|
| 0.17.1 | default | 51.1% | 45.0 s | 1.6 s |
| 0.17.2 | default | 57.6% | 78.8 s | 7.6 s |
| 0.17.2 | --power | 57.7% | 103.4 s | 8.2 s |
| 0.17.9 | --fast | 44.9% | 15.7 s | 0.46 s |
| 0.17.9 | default | 60.3% | 52.1 s | 9.8 s |
| 0.17.12 | --fast | 44.9% | 4.1 s | 0.4 s |
| 0.17.12 | default | 61.1% | 38.4 s | 8.4 s |
| 0.17.12 | --power | 64.8% | 115.7 s | 29.2 s |
Big logs and text: coded in chunks on every core instead of falling back to the classic coder. The 32 MB access log above went from 2.24 MB to 1.71 MB at default.
VMDK, OVA and qcow2 stream in bounded memory like raw disks, and come out smaller than before (OVA 19.91 → 19.09 MB).
The app, viewer, service and NAS package now open streamed disk archives and chunked text.
Four levels from --fast to --extreme. A context-mixing text model with layout rules. An x86-64 instruction model for programs. Virtual disks read through ext4, XFS, NTFS and LVM2. Signed self-updates: every install moves to the new version by itself.
Streaming, storage, cold storage: each needs a different trade.
A byte costs different things in different places. In flight you pay in time, so the compressor has
to be quick on both ends. At rest you pay every month, so a few more seconds buys a smaller bill. In
cold storage you pay for years and rarely read, so every byte you can remove is worth it. One setting
can't be right for all three, so MIKE has four. They all write the same format: any .mike
opens with the same tool whatever level wrote it, and data can move to a deeper level as it cools.
- saved
- 44.9%
- in
- 3.7 MB/s
- out
- 38 MB/s
Pipes, transfers, ingest. mike stream runs in bounded memory on every core. On 2 cores it pays for itself on links below about 12 Mbit/s, and more cores raise that limit.
- saved
- 61.1%
- in
- 0.40 MB/s
- out
- 1.8 MB/s
Files people still open. Beats every rival's best on totals, with restores fast enough for everyday reads.
- saved
- 64.8%
- in
- 0.13 MB/s
- out
- 0.53 MB/s
Backups, snapshots, archives. Every specialist runs, plus the full text model. Smallest on 58 of 60 files.
- saved
- 64.8%
- in
- 0.11 MB/s
- out
- 0.49 MB/s
Written once, kept for years. Models whole files up to 64 MB and tries both containers per block.
// speeds = the 60-file set on a 2-vCPU VM, per job; disks, chunked text and streams use every core
SAP HANA backups: 7.6× smaller, where HANA's own compression gets 2.4×.
HANA's built-in backup compression is LZ4-class: fast, but light. Many backup agents add nothing on top. On TPC-H tables, the standard database benchmark data, MIKE cuts the backup to a third of what HANA's native compression leaves, and every byte comes back identical.
| Compressor | lineitem 10 MB | customer 24 MB |
|---|---|---|
| HANA native class zstd --fast (LZ4-class) | 41.2% | 48.3% |
| gzip -9 legacy backup | 28.6% | 37.3% |
| zstd -19 modern backup tools | 21.6% | 30.9% |
| xz -9e best rival | 20.9% | 29.2% |
| MIKE default | 14.6% | 24.5% |
| MIKE --power | 13.2% | 22.3% |
// size left, as a share of the original · TPC-H dbgen tables (lineitem: first 10 MB of scale factor 0.1; customer: scale factor 1) · MIKE 0.17.12 on the 2-vCPU VM, 2 Nov 2026, all byte-exact · at --power: 68% smaller than HANA-native-class on lineitem, 37% smaller than xz -9e
MIKE on HANA's backup path
SAP HANA hands every data, log and catalog backup to third-party tools through its Backint interface: a named pipe per backup object. The MIKE Backint agent sits on that pipe. It compresses on the way out and decompresses on restore, and HANA gets back exactly the image it wrote.
▸ Installs through the standard hdbbackint hook and global.ini, with no change to HANA or the applications.
▸ Every object is decoded again before it is reported saved. If it doesn't match, the backup fails rather than pretend.
▸ One setting per site picks the level: fast, balanced, power or extreme.
What does your estate cost at rest? Here's 15 exabytes.
Pre-filled with 5 EB of office documents, 5 EB of VM backups and snapshots, and 5 EB of machine and access logs. The reduction for each type is MIKE's measured result above, with the best rival beside it. Pick a mode, change any number, add your own data.
// saving = Σ stored × share saved × $/TB/yr · logs: average of the access log and the system journal above; rival = zpaq -m5 · VM backups: share of the data written to the disk (empty space costs nothing either way), measured on ext4, XFS and NTFS; rival = xz -9 · documents, PDF, photos, numeric, CSV: the 60-file set · your data will differ, so measure it: mike c --power reports the ratio for every file
One engine, in every shape it ships.
Every program below runs the same engine and the same format, and updates itself over a signed channel.
| Product | Runs on | Status | What it does |
|---|---|---|---|
| MIKE app mike-gui | Linux · Windows · Android | shipped | One button: drop a file to shrink it, drop a .mike to restore. Mode selector, AES-256 password lock, verify. |
| MIKE CLI mike | Linux x86-64 & ARM64 · Windows | shipped | mike c / mike d, four levels, --safe round-trip check, mike stream for pipes. |
| MIKE View mike-view · mike-open | Linux · Windows | shipped | Open a .mike without unpacking it. Temporary copy, wiped on close. |
| MIKE Vault mike-vault | Linux · Windows | enterprise | A folder that compresses itself. Files land, shrink, and open like nothing happened. |
| MIKE Folder mikefs | Linux x86-64 & ARM64 · QNAP NAS | preview | A share that is compressed on disk and served byte-exact over SMB, NFS or File Station. |
| MIKE Backup mike-backup | Linux · Windows | preview | Incremental VM and file backup with deduplication: QEMU/KVM and Proxmox disks, live file trees. |
| MIKE HSM mike-hsm · mike-hsmd | Linux | preview | Tiered storage: cold files are kept compressed and restored on first touch. |
| Backint for SAP HANA mike-backint | Linux | enterprise | MIKE on HANA's backup interface. |
| SAP & object storage contentserver · ilmstore · s3gw · segments · mike4sap-ds | Linux | enterprise | MIKE behind SAP Content Server, ILM store and Data Services, and an S3-compatible gateway. |
Licences, enterprise builds and support go through them. Write to mr.adamantware@gmail.com and we'll put you in touch.
No lossless compressor shrinks everything. Here is where we don't.
A noisy sensor series
One of the 60 files: zpaq is 7.6% smaller at --power. There is no exact rule for the puzzle compressor to find.
Modern video
H.264 (CABAC) and H.265 are already arithmetic-coded. On our small H.264 clip, Brotli is about 200 bytes smaller. MIKE falls back to storing it as is.
Logs at the default level
On logs, zpaq -m5 is smaller than MIKE default, and on the system journal so is xz -9e. At --power, MIKE is 28% under zpaq on the journal and 1.6% over it on the access log. For log archives, use --power.
Restore speed at the deep levels
Context mixing decodes as hard as it encodes. Classic tools restore in a fraction of a second where --power takes tens of seconds. Use --fast where restores must be instant.
Always lossless, never meaningfully bigger
Every result on this page was restored and compared byte for byte. Plain storage is always a candidate, so random data comes out at its own size plus a few bytes of header.