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.
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 verified | 5,000,000,000 |
|---|---|
| Source size | 690.34 GiB |
| Coverage mode | numeric expression index |
| Coverage fingerprint | 063c20e5dd1e88e59793971300217f1f0105bcecfadb26b59323aa036fa5daf4 |
| Create p50 / p95 | 56.84ms / 68.95ms |
| Transaction p50 / p95 | 9.32ms / 12.29ms |
| Cleanup p50 / p95 | 7.49ms / 9.09ms |
| Proof checks | 6/6 |
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.
| Check | Result | Status | Timing | Source state |
|---|---|---|---|---|
| Concurrent branches | 100 / 100 succeeded | 0 deadlocks | 1037.55ms p50 / 2036.41ms p95 create | 0 source mutations |
| 1M branch writes | 1,000,000 overlay rows | 38,661 rows/sec | 31.30ms cleanup | 0 source mutations |
| 10M branch writes | 10,000,000 overlay rows | 37,237 rows/sec | 258.18ms cleanup | 0 source mutations |
| Multi-table FK check | 5 related tables | valid write passed; orphan child accepted | limitation found | 0 source mutations |
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 first | The initial copy-on-write branch view accepted an orphan child insert in the five-table foreign-key fixture. |
|---|---|
| What changed | The 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 patch | Concurrent branching and heavy writes stayed isolated with 0 source mutations, but an orphan child write was accepted inside the branch. |
| Next patch | Add explicit branch-local FK triggers so orphan writes and parent-side actions behave like Postgres tables, not plain views. |
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.
