Imladri isolated DB branch latency on GCP Local SSD, then cut the 5B DDL tail.

Session pooling moved the tail down.

With the Node pg runner, prepared branch lease/create stayed below 200ms p95. Removing the write probe did not remove the first-query tail. But a second query on the same client dropped to 12.67ms p95, which isolates the remaining tail to first connection/query startup under burst, not the branch copy itself.

The next pass moved query execution into branchd-side resident sessions. In the clean read-only run, 100 concurrent branches completed in 216.44ms wall time with 82.3ms create p95 and 77.16ms first-query p95. A later sustained burst pass used a cheaper select 1 first-query probe, targeted the source-mutation check to the event table being written, and deferred Btrfs tombstone deletion out of the hot destroy path. That 5x100 run completed 500/500 branches with 95.41ms create p95, 33.36ms first-query p95, and 0 source mutations. Instrumenting the refill path then showed that Btrfs snapshots, Postgres starts, and session preconnects were competing inside the same warm loop. Phased warming fixed the contention and produced a new sustained run with 91.13ms create p95, 28.67ms first-query p95, 95.6ms write p95, and 3.93s refill p95.

The same host later ran the harder 5B DDL probe that had exposed the multi-second p95 tail. Normal event inserts stayed below 105ms p95, but branch-local DDL pushed write and cleanup into the one-to-two second range. The fix was not to hide the result. Imladri made per-branch Postgres memory/WAL/checkpoint settings configurable, restarted branchd with 64MB shared_buffers, and fixed the pool-refill timer so a restarted service always warms the prepared branch pool. The 5x100 repeat completed 500/500 DDL-heavy branches with 0 deadlocks, 0 source mutations, 361.87ms write p95, and 134.52ms destroy p95. A follow-up patch made pool accounting ignore stale entries from prior pool roots before refill. With refill/start/preconnect concurrency at 32, the write p95 moved again to 297.17ms, while the full 100-branch refill wait stayed around 8.3s.

This is better evidence, not the finish line.

The result is useful because it shows the refill bottleneck was a scheduling problem, not a hard storage ceiling. It does not claim that Imladri has matched full storage-branch vendors across every production shape. The honest next target is to repeat this phased refill policy on larger source fixtures and higher-core machines. The DDL-heavy path still exposes Btrfs snapshot creation as the next refill limiter.