§2.5 · Research thread · active · open source

HanuDB

Madhu

Kansas City · Independent · since 13 September 2026 · updated 24 September 2026

Abstract

A document store whose durable home is object storage: the machine that serves it holds no truth. The machine that serves the database holds no truth. Every acknowledged write is in a cloud bucket, hash-chained, in two regions. Delete the machine and a new one rebuilds from the bucket alone. Every change was measured against a fixed benchmark with hard gates for recovery, memory and cost, and kept only when the mean of two runs improved by more than three per cent. Several findings reversed what was expected: a second thread on a shared core is a net loss, and resident set size is the wrong quantity for an out-of-memory guard. The engine is HanuDB (formerly TwinDB), public on GitHub with clients, an installer and guides. This site and bigImmigrationHub run on it.

1 · Article 2 · Experiments 3 · Paper The code

Keywords: databases, rust, object storage.

1Measurements

**Table 1.** Every headline number this thread claims, with the conditions it was measured under and the file it is read from.
measure	value	conditions	source
Benchmark score	9 047 → 40 116	geometric mean of writes/s and reads/s on a 1-core, 768 MB harness	`results.tsv`
Writes / reads per second	34 821 / 46 218	—	`run.log of experiment 0091`
Experiments	108	74 changes kept, 27 discarded	`results.tsv`
Soak	14 M documents	ten minutes, zero errors	`soak-server.log`
Rebuild from the bucket	40 s	4.5 GB snapshot plus tail	`README.md, Scale`
Cost to run	≈ $0.01 / day	measured on a real free-tier machine	`README.md, Real e2-micro`

2The paper

The full account is written up as a preprint: HanuDB: A Bucket-Resident Document Database for a Free-Tier Virtual Machine, and the 108 Experiments That Shaped It (37 pages at a paper's density; pdf).

3The database, in plain words

HanuDB is a small database for people who build a lot of apps.

Every app needs somewhere to keep its data, a way to fetch it by id, a way to list it with filters and sorting, and sooner or later a search box. The usual answer is a managed MongoDB or Postgres plus a managed Elasticsearch, and the bill for those grows with every new app and with every gigabyte each app collects. HanuDB is the answer we built instead: one small binary that does documents, filters, sorting and full-text search, runs on the smallest VM Google gives away for free, and keeps the truth in a Google Cloud Storage bucket so the VM can be lost at any time without losing a write.

It costs about a cent a month in bucket operations, and it answers in well under a millisecond. It is public, with releases, a one-line installer, clients for TypeScript, Python and Swift, and nine guides; the preprint reports the 108 experiments that shaped it.

The engine on GitHub · nine guides, from nothing to operations · db.carebun.com · read the guides with a quiz and recall in the Reading Room.

§Where the work lives

~/apps/hanudb — the engine and its results.
~/apps/hanudb/paper — the preprint.
~/apps/hanudb/docs — the nine guides, and the description quoted on this page (README.md).
~/apps/hanudb/results.tsv — one line per experiment.
Source: github.com/madhudream/hanudb

§Related writing and lessons

OptionMantra: VIX Data Pipeline - A Practical, Everyday Build (writing)
How does a semantic cache work? (writing)

Ask this thread

← §2.4 BigKids