We created a synthetic Postgres source table with exactly one billion generated rows and rebuilt its primary key after proving the generator at 1M, 10M, and 100M rows. The benchmark then created a governed copy-on-write branch through Imladri's storage_branch API, executed an approved write transaction inside the branch, confirmed the source table did not change, destroyed the branch, and exported the proof artifact.
The result is the useful shape for database agents: not a giant full copy, but a governed branch that can be created, written to, proven, and cleaned up while preserving the production source boundary.
We stepped through 1M, 10M, 100M, then 1B rows.
The billion-row result was not a single blind jump. We used smaller runs to catch fixture and proof issues first, then promoted the same benchmark path to the D: volume for the final 1B-row run.
| Run | Rows | Source size | COW create | Tx | Cleanup | Source mutations | Proof |
|---|---|---|---|---|---|---|---|
| 1M | 1,000,000 | 0.13 GiB | 17.15ms | 8.78ms | 5.81ms | 0 | 6/6 |
| 10M | 10,000,000 | 1.31 GiB | 17.97ms | 14.68ms | 7.55ms | 0 | 6/6 |
| 100M | 100,000,000 | 14.86 GiB | 26.42ms | 12.48ms | 56.38ms | 0 | 6/6 |
| 1B | 1,000,000,000 | 136.77 GiB | 22.96ms | 12.67ms | 7.10ms | 0 | 6/6 |
The scale ladder found a real fixture bug before the 1B run.
The 10M-row step exposed an ID collision at the first nine-digit boundary. That was exactly why the benchmark needed row coverage proof before publishing timing numbers.
| Caught | The first high-scale fixture rebuild failed when the synthetic ID generator created a duplicate key at B10000000. |
|---|---|
| Fixed | IDs now preserve every digit past the eight-digit padding boundary, so 10M, 100M, and 1B rows keep a unique contiguous ID range. |
| Guarded | The benchmark now refuses to report timing until exact row count, valid ID count, invalid ID count, min/max ID range, and source fingerprint checks pass. |
Build a real billion-row source
The benchmark loaded public.imladri_bench_customers into a separate local Postgres 17 cluster on the D: volume, then rebuilt the primary key over all generated IDs.
Prove coverage before timing
The run performed exact count and ID-range coverage checks: one billion exact rows, one billion valid generated IDs, zero invalid IDs, and min/max IDs matching 1 through 1,000,000,000.
Create the governed branch
The storage_cow backend created a copy-on-write Postgres branch through the same Imladri storage_branch API used by the product sandbox flow.
Write without touching source
The branch transaction inserted and updated inside the sandbox, returned proof metadata, then verified source mutations stayed at zero.
Clean up and export evidence
The branch was destroyed, cleanup proof completed, and the JSON artifact was published for inspection.
How we know rows were not skipped.
The benchmark does not rely on Postgres estimates. Before reporting the branch timings, it performs exact coverage checks over the generated ID space. Because the rebuilt primary key enforces uniqueness, the combination of exact count, valid generated ID count, invalid ID count, and min/max range proves the fixture covers every generated ID from 1 through 1,000,000,000.
| Exact rows | 1,000,000,000 |
|---|---|
| Valid generated IDs | 1,000,000,000 |
| Invalid IDs | 0 |
| Min / max ID | 1 / 1,000,000,000 |
| Coverage fingerprint | 3644389ad3cdf775508ce91123480b29eaa490221dbdfb49eddbbf2d6f867bbe |
Copy-on-write is the scale path.
The first billion-row artifact used one iteration, so its min, p50, p95, and max fields are identical by definition: one sample has only one value. We kept that full comparison artifact, then ran a focused twenty-sample repeat check on storage_cow only.
The full template database branch timed out, which is the expected failure mode for a full-copy approach. The copy-on-write storage branch stayed size-independent at the branch creation boundary.
| Case | Backend | Create | Tx | Cleanup | Source mutations | Proof |
|---|---|---|---|---|---|---|
| storage_cow | postgres_copy_on_write_schema | 22.96ms | 12.67ms | 7.10ms | 0 | 6/6 |
| copy_on_write | overlay schema | 657.21ms | 18.96ms | 7.36ms | 0 | 6/6 |
| materialized | bounded 5k-row copy | 2998.13ms | 67.42ms | 48.16ms | 0 | 6/6 |
| storage_template | full template database | timed out | n/a | n/a | n/a | n/a |
Twenty storage-COW samples over the verified 1B source.
The repeat run reused the verified coverage artifact instead of rescanning the 136.77 GiB source table, then executed twenty governed storage-COW branches against the same source.
The first sample was the cold max. After that warmup, create times stayed between 22.66ms and29.56ms. Every sample preserved the source with0 mutations and kept the proof score at6/6.
| Samples | 20 |
|---|---|
| Create min / p50 / p95 / max | 22.66ms / 24.07ms / 29.56ms / 210.63ms |
| Tx min / p50 / p95 / max | 9.42ms / 11.19ms / 16.82ms / 36.54ms |
| Cleanup min / p50 / p95 / max | 7.44ms / 9.22ms / 17.90ms / 21.02ms |
| Cold first-run max | 210.63ms create / 36.54ms tx / 17.90ms cleanup |
| Subsequent create range | 22.66ms to 29.56ms |
| Source mutations | 0 |
| Proof checks | 6/6 |
| Run | Create | Tx | Cleanup | Source mutations | Proof |
|---|---|---|---|---|---|
| 1 | 210.63ms | 36.54ms | 17.90ms | 0 | 6/6 |
| 2 | 22.74ms | 16.82ms | 8.23ms | 0 | 6/6 |
| 3 | 25.66ms | 11.86ms | 9.42ms | 0 | 6/6 |
| 4 | 22.66ms | 13.03ms | 7.70ms | 0 | 6/6 |
| 5 | 25.43ms | 13.05ms | 8.50ms | 0 | 6/6 |
| 6 | 23.68ms | 10.59ms | 9.05ms | 0 | 6/6 |
| 7 | 23.51ms | 12.13ms | 21.02ms | 0 | 6/6 |
| 8 | 24.07ms | 10.68ms | 12.45ms | 0 | 6/6 |
| 9 | 23.53ms | 11.19ms | 11.33ms | 0 | 6/6 |
| 10 | 24.63ms | 9.68ms | 10.69ms | 0 | 6/6 |
| 11 | 26.75ms | 11.59ms | 10.64ms | 0 | 6/6 |
| 12 | 26.88ms | 9.61ms | 7.44ms | 0 | 6/6 |
| 13 | 29.56ms | 14.78ms | 9.59ms | 0 | 6/6 |
| 14 | 24.28ms | 12.90ms | 9.22ms | 0 | 6/6 |
| 15 | 22.93ms | 9.68ms | 9.16ms | 0 | 6/6 |
| 16 | 23.57ms | 10.00ms | 9.94ms | 0 | 6/6 |
| 17 | 23.89ms | 11.94ms | 8.20ms | 0 | 6/6 |
| 18 | 27.05ms | 10.01ms | 8.57ms | 0 | 6/6 |
| 19 | 26.10ms | 9.42ms | 9.29ms | 0 | 6/6 |
| 20 | 22.68ms | 10.09ms | 7.92ms | 0 | 6/6 |
Database agents need governed branches, not shared production writes.
Coding and data agents increasingly need to test migrations, generated SQL, cleanup jobs, and application code against realistic data. The dangerous pattern is letting an agent touch production state directly. Imladri's database sandbox gives the agent a branch, routes writes through the policy boundary, records what happened, and destroys the workspace after the run.
This does not replace purpose-built storage engines or snapshot systems. It gives Imladri a governed API layer that can sit above those engines: create branch, permit or deny actions, record proof, clean up, and show what changed.
Download the artifact.
The public JSON contains the generated timestamp, fixture size, row coverage, benchmark samples, backend failure, and proof scores from the run.
Open JSON evidenceWhat this does and does not prove.
- This is a local Postgres copy-on-write benchmark, not a managed distributed database benchmark.
- The source table was synthetic and about 136.77 GiB, not a multi-terabyte customer production database.
- Full template database branching timed out, which is expected. The result supports the COW/storage-branch direction, not full-copy cloning.
- The long part was building and verifying the billion-row fixture. The measured branch creation happened after that verification completed.