Back to sandboxing
Database sandbox / May 13, 2026

Imladri branched a verified 5B-row Postgres source, then found the next database-agent gap.

The governed copy-on-write path held under five billion rows, one hundred simultaneous branches, and ten million branch-local writes. The same run found a branch-local foreign-key limitation; an orphan child write was accepted inside the branch even though the source database stayed untouched.

Result

The benchmark verified a synthetic Postgres source with exactly 5,000,000,000generated rows. This 5B-row numeric coverage proof ran before branch timing, then created twenty governed storage-COW branches through Imladri's storage_branch API. Every branch completed with 0 source mutations and 6/6 proof checks.

This is the shape database agents need: a fast branch for risky work, isolated writes, cleanup, and an evidence packet proving the production source was not mutated.

5B proof

The scale claim is based on numeric coverage, not estimates.

The original lexicographic verifier caught mixed-width legacy IDs in the first 1B fixture. We fixed the verifier to use a unique numeric expression index and one hundred bounded chunks over 1..5,000,000,000.

Rows verified5,000,000,000
Source size690.34 GiB
Coverage modenumeric expression index
Coverage fingerprint063c20e5dd1e88e59793971300217f1f0105bcecfadb26b59323aa036fa5daf4
Create p50 / p9556.84ms / 68.95ms
Transaction p50 / p959.32ms / 12.29ms
Cleanup p50 / p957.49ms / 9.09ms
Proof checks6/6
Boundary follow-up

Concurrency and heavy writes held. Foreign keys exposed the limit.

After the 5B result passed, we ran the next production-realism checks: one hundred simultaneous branches, one million branch writes, ten million branch writes, and a five-table relational fixture. The first FK run exposed a branch-local orphan-write gap: the branch protected the source, but the branch view did not yet reject an orphan child write.

CheckResultStatusTimingSource state
Concurrent branches100 / 100 succeeded0 deadlocks1037.55ms p50 / 2036.41ms p95 create0 source mutations
1M branch writes1,000,000 overlay rows38,661 rows/sec31.30ms cleanup0 source mutations
10M branch writes10,000,000 overlay rows37,237 rows/sec258.18ms cleanup0 source mutations
Multi-table FK check5 related tablesvalid write passed; orphan child acceptedlimitation found0 source mutations
Limitation

The FK limitation is the point of this article.

This matters more than hiding the weakness. The benchmark first showed that the COW branch protected the source but did not reject an orphan child write. This article preserves that failure as the audit trail. The fix and rerun live in the next article so the progression is clear.

What failed firstThe initial copy-on-write branch view accepted an orphan child insert in the five-table foreign-key fixture.
What changedThe 5B scale path held, but the first five-table FK fixture exposed that COW branch views needed explicit branch-local constraint checks.
Validated behavior before the patchConcurrent branching and heavy writes stayed isolated with 0 source mutations, but an orphan child write was accepted inside the branch.
Next patchAdd explicit branch-local FK triggers so orphan writes and parent-side actions behave like Postgres tables, not plain views.
Evidence

Artifacts are public.

The first artifact proves the 5B source coverage and twenty storage-COW branch samples. The second artifact records the concurrent branching, heavy-write, and FK limitation follow-up.