TOP OF FORMFICHE ARCHIVE COPY 0x57 0x57 HANDSHAKE OK PAGE 001 · SYSTEM LOG
WormDB is a distributed key-value store in a single 45 KB Zig binary. Seal a key forever with one flag, prove it with Merkle audit trails, run your business logic inside the database, and replicate everything over encrypted tunnels — no coordinator, no sidecars.
SET audit:2026-07-04:001 "deploy v2.3.1 approved" WORM
OK · wal seq=48213 · crc32 9F2E11D4
GET audit:2026-07-04:001
"deploy v2.3.1 approved"
SET audit:2026-07-04:001 "rewrite history"
ERR WormViolation: key is write-once
DEL audit:2026-07-04:001
ERR WormViolation: WORM keys cannot be deleted
-- 4 statements · 0 rewrites --
PAGE 002JOB CONTROL — EXECCONT'D FROM 001
Stored procedures in WormDB are native Zig functions compiled into the server
binary. One EXEC frame runs a multi-key operation atomically under
automatic shard locking and returns in a single round trip — no application-side
transactions, no read-modify-write races, no ORM in the middle.
52 procedures ship in the binary today, and adding your own is three files and a recompile. Your entire backend logic rides inside a 45 KB static executable — deploy it like the mainframes deployed jobs: one artifact, no drift.
When "trust me" isn't enough, the append_log family notarizes your history:
Merkle Mountain Range proofs, signed checkpoints, and third-party witnesses make any
tampering mathematically evident — not just against policy.
EXEC transfer acct:alice acct:bob 250 lock shards 0x2F, 0xA1 · ordered, deadlock-free OK alice=1750 · bob=2250 · 1 round trip EXEC append_log_mmr_proof audit 48213 merkle mountain range proof, verifiable offline OK 17 hashes · root 4C6F…E2A1
PAGE 003CAPABILITY REPORT[1B OPCODE][4B LENGTH][PAYLOAD]
Every capability is a first-class frame on the WormWire protocol — one opcode byte, a big-endian length, a payload, 16 MiB cap. Here's what the bytes buy you.
Set a key with the WORM bit and the engine refuses every later overwrite and delete — enforced under the shard lock, replicated to every peer, surfaced as a protocol error. Audit trails without a compliance vendor.
Every session opens with two magic bytes — WW. There is zero grammar to fuzz and zero escaping to get wrong. Raw telnet is rejected at byte one.
Subscribe to vec: and receive every vector insert on the server as unsolicited EVENT frames on the connection you already have. No polling loop, no sidecar broker.
Embedded meshguard runs SWIM gossip for discovery and failure detection; replication travels ChaCha20-Poly1305-encrypted over WireGuard tunnels. Joining peers converge by anti-entropy. There is no etcd.
Embeddings write through the same durable, replicated path as any key, then serve from a per-namespace HNSW graph with a 1-bit quantized prefilter (32× smaller) and AVX2/NEON distance kernels.
Native Zig functions run atomic multi-key operations under automatic shard locking, in one round trip. Counters, transfers, agent memory, Merkle proofs — or handlers you write yourself.
PAGE 004BENCHMARK SUMMARYMEASURED, NOT MARKETED
$ zig run src/vector/bench.zig -O ReleaseFast -lc · AVX2 · SINGLE THREAD · 50K VECTORS · K=10
Most stacks bolt a vector database next to the real one, then spend their uptime keeping
the two in agreement. WormDB stores embeddings as ordinary keys —
vec:<ns>:<id> — durable in the WAL, replicated with everything
else, WORM-sealed by default. Queries take the fastest path the
namespace supports:
mode=exact.
Cluster-wide: EXEC vsearch_cluster scatters the query to
every peer over the already-encrypted replication links and merges top-K. For agent
memory, optional temporal decay lets fresh context outrank stale embeddings.
VSEARCH THROUGHPUT
cosine · 50,000 vectors · K=10 · one thread · queries/sec
bars share one linear scale · reproduce with src/vector/bench.zig
PAGE 005REPLICATION TOPOLOGY0x05 · CLUSTER STATUS
A WormDB cluster is just WormDB. Peer discovery, failure detection, identity, and encrypted transport ship inside the same 45 KB binary, via the embedded meshguard mesh layer.
# first node seeds the mesh wormdb --port 6389 --data ./n1 \ --cluster prod --gossip-port 51821 # everyone else just names a seed wormdb --port 6390 --data ./n2 \ --cluster prod --seed 10.0.0.1:51821 # watch it converge wormdb> CLUSTER PEERS n1 10.0.0.1 alive seed n2 10.0.0.2 alive synced 48,214 keys
PAGE 006INSTALLATIONZIG 0.16+ · LIBSODIUM
One static binary out, nothing to install on the target box.
git clone --recursive \
https://github.com/igorls/wormdb
cd wormdb && zig build -Doptimize=ReleaseSmall
./zig-out/bin/wormdb --port 6389 --data ./data
Linux: full feature set — clustering, io_uring, epoll. Windows: single-node, threadpool backend.
docker build -t wormdb:latest .
docker compose up -d # 2-node encrypted cluster
The repo's docker-compose.yml brings up a gossiping two-node cluster; the bench compose file adds a load generator.