Skip to content

PATTERN Cited by 1 source

A/B variant prototyping at database level

Pattern

When two competing schema designs are in contention, build both on parallel database branches forked from the same parent, run the application's critical read/write paths against each, measure what matters, and keep the better solution. Discard the losing branch. Document the decision and reasoning in the PR description as a permanent design record.

Mechanics

  1. Create two branches off the same parent (staging or production).
  2. Apply Design A's migration to branch A, Design B's migration to branch B.
  3. Run the application against each. Measure:
  4. Query latency on the common read path.
  5. Migration execution time at production data volume.
  6. Index footprint and storage overhead.
  7. Lock contention under simulated load.
  8. Pick the winner. Discard the loser. Document why in the PR.

Why it works now

Per-branch cost is near zero on copy-on-write substrates like Lakebase or Neon. Exploring two designs no longer requires picking one in advance, and no longer requires a provisioning process most teams won't undertake for an exploratory question. Both branches share all unmodified pages with the parent — storage cost is only the delta of each design's writes.

Canonical example

Jen considered two designs for the location/batch/serial feature: three new columns on the existing inventory table, or a separate inventory_attributes lookup table keyed by inventory_id. She built both on parallel branches off staging, measured query performance on the common read path against production-shaped data, and saw the lookup-table version performed worse because every inventory display required a join. She shipped the columns version, discarded the lookup-table branch, and left a note: "Considered lookup-table version; rejected because the common read path becomes a join. Revisit if more than five attributes accumulate."

(Source: sources/2026-06-05-databricks-enabling-evolutionary-database-development-database-branchin)

Anti-patterns

  • Prototyping without documenting the decision. The branches are gone in a second; the design decision should be permanent. Without the PR note, the next developer who extends the schema doesn't know what was considered.
  • Running A/B experiments against synthetic toy data. The value of this pattern is measuring against production-shaped data. If both designs look equivalent on 100 rows, the comparison provides no signal.
Last updated · 542 distilled / 1,571 read