Imladri moved governed Postgres FK branches onto a prepared COW pool.

The 100-way FK create p95 moved to 53.34ms.

The same ten-table FK fixture was tested across three implementation shapes. Eager materialization was correct but expensive. Targeted lazy materialization avoided unnecessary table work. The prepared pool moved most remaining clone work before the request. The final row is the latest clean run: refill disabled for benchmark hygiene, schema fingerprints cached, zero deadlocks, and zero source mutations.

The speedup did not remove the FK guardrails.

The prepared branch still enforced the same branch-local FK behavior as the correctness article. The benchmark completed 100 simultaneous FK branches, allowed valid branch writes, rejected orphan writes, applied update/delete cascades, and left the source unchanged. Cascade p95 moved from 3235.59ms to 493.36ms, and cleanup p95 moved from 3052.3ms to 249.34ms.

Fast branching and heavy branch writes are different claims.

The sub-100ms branch numbers in this article are about governed branch creation over approved tables. The 12.88s and 138.4s numbers are heavy branch-local writes after the branch exists. They do not disprove fast clone work, but they also do not make Imladri an Ardent- or Neon-class full-database clone engine by themselves. The new backend seam for that next layer is external_snapshot_command: Glasshouse can now delegate branch create/destroy to a storage provider while keeping Imladri policy, transaction, cleanup, and proof around the branch lifecycle. A follow-up self-hosted Btrfs droplet 100-sample repeat reached 1106.76ms p50 / 1666.56ms p95 branch create on the existing shared runtime droplet. Moving the same 10M-row loopback proof to a dedicated 4 vCPU / 8GB droplet improved that to 699.54ms p50 / 1150.54ms p95, with 0 source mutations.

The provider coordination bug is fixed; prepared physical branches cut the tail.

The first 25-way physical branch run exposed a real provider race: concurrent creates could reserve the same state window, fail, and leave branch subvolumes behind. The provider now reserves ports and state under an atomic lock, writes state atomically, and destroys by deterministic branch path if state is missing. After that patch, both the shared runtime droplet and the dedicated DB-sandbox droplet completed 25/25 concurrent branches with 0 deadlocks and 0 source mutations. The dedicated host reduced the 25-way create p95 from 60488.22ms to 10748.29ms. It is still loopback Btrfs, not a final attached-volume benchmark, but it proves the high tail was mostly host/contention pressure rather than a mutation safety failure.

The next pass warmed physical branches before the request path and leased them under the same create/destroy contract. That removes checkpoint, snapshot, and Postgres start from the hot path. On the dedicated loopback host, 20 concurrent warmed physical branches stayed under six seconds p95 while keeping 0 deadlocks and 0 source mutations. At 25-way, the host still crossed six seconds p95, so 25-way is a correctness result rather than the speed envelope.

The attached-volume run then moved the same provider from a loopback Btrfs file to a real DigitalOcean block volume. That pass caught two host-realism bugs before publication: long benchmark branch names exceeded PostgreSQL's Unix socket path limit, and /tmp socket directories needed to be owned by the branch Postgres user. After both fixes, the attached volume completed 100 serial branches and 20/25 concurrent warmed branches with 0 source mutations. On this 4 vCPU / 8GB droplet, 20-way is the honest sub-six-second envelope; 25-way is a correctness result that needs a larger storage host or smarter request scheduling.

The honest next target is partner-workload write throughput.