0.85ms writes: I re-ran Firenook's 40x claim on a 4-core VM

Firenook claims its Rust Firebase emulators write 40x faster than Google's official ones: 5.1 ms median against 208.2 ms. I installed it, ran 300 writes, 100 reads, and 20 queries against it on a 4-vCPU VM — and then audited their benchmark data, because a 40x claim deserves a second look. My median write was 0.85 ms. The claim holds up, but not for the reason the headline suggests.

What I ran

Firenook 0.2.1, installed with npm install firenook (73 MB of node_modules, a 75 MB single Rust binary inside). Node 24.22.1, a 4-vCPU VM with 8 GB of RAM. A minimal project: firebase.json with Firestore, Auth, and Storage emulators, rules wide open. No functions, no listeners, no SDK — plain Firestore REST calls over loopback, sequential, one at a time. That is a lighter workload than theirs, and the difference matters: their numbers come from two hours of a real app's traffic with listeners and a Firestore-triggered function attached to every write.

single-doc writes: n=300 median=0.85ms p95=1.39ms p99=1.77ms max=4.90ms single-doc reads: n=100 median=0.34ms p95=0.71ms p99=4.36ms max=4.36ms orderBy n DESC limit 20: n=20 median=0.77ms p95=1.18ms max=1.18ms 

Every write was a fresh document with three fields, acknowledged by the server before I timed the next one. The read-back check passed on all 300 documents, and every orderBy query returned exactly 20 documents in the right order. The write path is sub-millisecond at this scale — faster than Firenook's own published 5.1 ms, which makes sense: their 5.1 ms includes a triggered function and listener delivery on every write; mine includes neither.

The restart number matched theirs exactly

The claim I could check most precisely was the restart. Their docs say restarting with data kept takes 0.59–0.60 s, against 30.8 s for the official emulator. I loaded 2,000 documents (2.11 s, 947 docs/s), stopped the suite, and restarted with --keep-data:

cold start (empty store): ready in 0.85s, tree RSS 99.8 MiB loaded 2000 docs in 2.11s (947 docs/s); RSS after load 114.7 MiB .firenook on disk: 2,169 KiB stop: 0.16s, exit code 0 CLEAN restart with 2000 docs kept: ready in 0.59s bulk docs after clean restart: 2000 (expected 2000) 

0.59 s, all 2,000 documents present with correct values, clean stop. One wrinkle worth reporting: --keep-data refuses to run with --only firestore — it needs the firestore, auth, and storage services together, because the state receipt covers all three. I hit that error, added the other two emulators to firebase.json, and it worked. Also worth noting: my first "restart" measurement was bogus — the old process was still holding port 8080 and answered in 0.03 s. I killed it, re-ran clean, and got the 0.59 s above. If a benchmark number looks too good, check whether the thing you think you restarted actually restarted.

I audited their benchmark file, not just their blog post

Firenook publishes its benchmark methodology and the raw frozen data in the repo (docs/benchmarks.md, benchmarks/020-paired-acceptance.json). I checked the doc's headline numbers against the JSON:

write commit, median/p99: official 208.2 / 279.8 ms, firenook 5.1 / 50.6 ms, n=5280 listener delivery: official 209 / 258 ms, firenook 11 / 60 ms, n=60000 memory peak (PSS): official 22.57 GiB, firenook 2.11 GiB resumed start, 3 runs: firenook 0.59 / 0.59 / 0.59 s; official 30.8 / 31.7 / 30.67 s stop with data saved: firenook 0.05–0.26 s; official 54–58 s (export) 

Every figure in the doc matches the frozen JSON. The methodology is also unusually candid for a vendor benchmark: it names the host (Ryzen 5 3600, 64 GiB, NVMe), the workload (211,205 documents, 33,352 storage objects, 6.7 GB), the sample counts, and — the part I liked — where Firenook loses. Storage downloads were slower on Firenook (2.30 ms vs 2.12 ms median), and the doc says so. A benchmark page that prints its own loss is more credible than one that doesn't.

What I could not check

I did not run the official emulator side by side. This VM has no Java, 8 GB of RAM, and the official stack peaked at 22.57 GiB of emulator memory alone on their 64 GiB host — it would not have fit here. So the 208.2 ms official-emulator number is theirs, not mine. What I verified is the Firenook side of the comparison at my scale, plus the internal consistency of their published data. That is a weaker claim than a full A/B, and it is the honest one.

The other thing to keep in perspective: 40x is a ratio, and ratios flatter the faster side when the baseline is slow. The official emulator's 208 ms median write is the real story — it is a Java process that keeps everything in heap and only persists on export. Firenook being a native binary with data on disk explains most of the gap; the interesting number is not 40x but the absolute one: sub-millisecond writes and a 0.59-second restart with your data intact. On my VM, both of those reproduced.

Sources: firenook.dev; firenook-dev/firenook on GitHub (Apache-2.0, 64 stars, created 2026-09-09); docs/benchmarks.md and benchmarks/020-paired-acceptance.json in that repo. All latency, memory, and restart numbers above are from my own runs on 2026-11-06, firenook 0.2.1; the official-emulator figures are Firenook's published numbers, verified against their frozen benchmark JSON, not measured by me.