Join waitlistJoin
How it worksResearchDocsAdoptersPricingContactJoin waitlist
Back to sandboxing
Database sandbox / May 15, 2026

Imladri re-ran governed Postgres branches at 100M, 1B, and 5B rows.

The repeat matrix kept the core safety claim intact: complete numeric coverage, twenty storage-COW branch samples per scale, zero source mutations, and passing proof checks. It also explains the honest limit: the 5B p95 widened because the current proof path records large source metadata before the branch packet is complete.

Database sandbox research sequence

Seven chapters. One continuous data-boundary story.

The path moves from billion-row governed branching, to 5B scale and the FK gap, then the FK fix, repeat matrix, prepared-pool optimization, GCP Local SSD latency isolation, and cold reserve pools.

011B branch proof source untouchedA verified billion-row source was branched, written to, cleaned up, and proven with 0 source mutations.May 9025B scale and gap limitation foundThe COW path held at 5B rows and 100 branches, then exposed the branch-local FK gap honestly.May 1303FK action patch gap closedOrphan rejection, restrict, cascade, set-null/default, deferred checks, and multi-branch isolation passed.May 1304100M / 1B / 5B matrix tail explainedThe repeat matrix passed coverage and source-isolation checks, then traced the 5B tail to proof metadata.May 1505Prepared branch pool hot path reducedPrepared COW schemas moved simple branch p95 to 14.67ms, FK branch p95 to 53.34ms, and 1M/10M branch writes onto a set-based bulk path.May 1606GCP Local SSD branchd tail isolatedA GCP Local SSD run separated branch creation from first-query startup, warm-query latency, psql overhead, and cleanup/refill behavior.May 1907Cold branch pool host ceiling exposedCold reserve snapshots preserved 5B proof checks, then showed the next bottleneck is 8-vCPU branch-process contention.May 21
Result

The matrix repeated the same governed storage-COW branch benchmark over three verified Postgres sources: 100 million, 1 billion, and 5 billion rows. Each run verified numeric ID coverage first, then created twenty branches, wrote inside the branch, cleaned it up, and checked that the source table remained unchanged.

The important result is not that every number stayed flat. It did not. The important result is that correctness held at every scale, and the latency change was traceable to metadata and proof capture instead of hidden row copying.

Scale matrix

All three scales passed coverage, isolation, cleanup, and proof.

The p50 branch-create number widened with source size:19.4ms at 100M, 30.53ms at 1B, and 65.17ms at 5B. Branch writes and cleanup stayed small, and source mutations stayed at zero.

ScaleSource sizeCoverageCreate p50 / p95Create maxTx p50Cleanup p50MutationsProof
100M13.24 GiB2/219.4ms / 32.43ms490.89ms11.19ms9.22ms06/6
1B136.67 GiB20/2030.53ms / 56.09ms3334.52ms12.47ms9.03ms06/6
5B794.94 GiB100/10065.17ms / 231.67ms16217.07ms9.52ms8.34ms06/6
Tail latency

The 5B p95 widened, and that is the finding.

The cold first branch-create sample was high at every scale. More importantly, the 5B warm distribution widened: most samples sat around 62-67ms, but the second-highest create sample hit 231.67ms. That is why the 5B p95 should be reported, not hidden.

ScaleCold first createWarm minp50p95
100M490.89ms17.92ms19.4ms32.43ms
1B3334.52ms27.22ms30.53ms56.09ms
5B16217.07ms62.23ms65.17ms231.67ms
Investigation

Metadata probing reproduced the same size-shaped curve.

The branch create path records a source fingerprint and relation-size metadata. That includes calls such as pg_total_relation_size and pg_indexes_size. Those calls do not copy source rows into the branch, but at 5B they are visibly larger and more variable because the table and index set are much larger.

ScaleProbe sizeMetadata p50Metadata p95Metadata max
100M15.33 GiB6.01ms8.42ms4897.01ms
1B157.59 GiB15.59ms25.01ms4489.33ms
5B794.94 GiB63.7ms184.97ms14317.76ms
Fix validation

Moving exact size accounting out of the hot path cut the 5B p95.

A follow-up run used the same verified 5B source and the same twenty storage-COW branch samples, but switched the source fingerprint to catalog-estimated size metadata. The branch still recorded the schema hash, estimated rows, source relation, isolated write, cleanup, zero source mutations, and proof checks. The hot create path dropped to 15.96ms p50 and 20.61ms p95.

ModeProof metadataCreate p50 / p95Create maxMutationsProof
BeforeExact relation-size proof metadata65.17ms / 231.67ms16217.07ms06/6
AfterCatalog-estimated source-size metadata15.96ms / 20.61ms225.94ms06/6

The phase split shows the remaining steady-state work is mostly branch DDL, not source-size probing.

Phasep50 / p95Max
Schema setup0.23ms / 0.5ms1.29ms
Source metadata3.86ms / 6.56ms34.03ms
Branch DDL10.28ms / 14.2ms22.42ms
Storage branch total15.78ms / 19.7ms222.79ms
Conclusion

The safe claim is narrower and stronger.

What stayed strongEvery scale had complete numeric coverage, twenty storage-COW branch samples, 0 source mutations, and 6/6 proof checks.
What changed at 5BThe 5B create p50 and p95 widened. The branch still did not copy source rows, but source metadata and fingerprint capture became visibly larger.
Why the tail widenedRead-only metadata probes reproduced the same curve. The current create path records relation size and index-size metadata before the branch proof packet is complete.
Next optimizationThe first fix is now validated: keep exact metadata available for audit runs, but use catalog-estimated source-size metadata for the hot branch path.
Evidence

The combined artifact is public.

The JSON artifact links the three scale runs and includes the metadata-probe investigation used to explain the 5B tail.

Open scale matrix JSONOpen optimized 5B JSONRead 5B limitation note