Glaspoort Branches Databases Like Code

Glaspoort, a fiber infrastructure provider, has revolutionized its data operations by treating its Databricks Lakebase database changes with the same rigor as application code deployments. This approach, detailed in a recent Databricks blog post, centers on a CI/CD pattern where every environment branches directly from production.

The core challenge was to enable granular testing of database changes without the common pitfalls of environment drift and complex refresh procedures. Glaspoort’s solution involves creating ephemeral, per-pull request database branches that are instantly forked from production. This strategy effectively eliminates the "reset-from-parent trap" where refreshing a stale environment necessitates rebuilding dependent branches.

The Problem: Stale Environments and Cascading Resets

Traditionally, database environments are stacked hierarchically: dev branches off production, acceptance off dev, and feature branches off dev. This structure leads to divergence as production receives live data, while long-lived development branches lag behind.

Refreshing these stacked environments from production requires deleting all child branches, including acceptance and feature branches, before resetting the parent. This cascade of deletion and re-creation is time-consuming and discourages the necessary hygiene, resulting in testing against outdated data.

The Glaspoort Solution: Branching from Production

Glaspoort's design flips this model. Both development and acceptance environments are direct children of production, existing side-by-side rather than stacked. This topology means refreshing one environment does not impact the other.

This simple change makes refreshing cheap and routine. When an environment drifts, it can be reset from production with a simple operation, ensuring that development and acceptance environments remain honest reflections of production. This is a key aspect of their Databricks Lakebase branching strategy.

The Per-PR Lifecycle: Ephemeral Branches and Migration Replay

The day-to-day workflow for developers leverages this stable topology with ephemeral branches. When a developer opens a pull request (PR), a fresh, short-lived Lakebase branch is created directly from production. This PR branch has a limited lifespan, typically an hour.

Continuous integration (CI) then replays all database migrations against this new branch. A git diff check determines if a migration rehearsal is even necessary, skipping the step for PRs that don't alter migrations.

Crucially, the testing goes beyond isolated migration validation. CI deploys the new application image to a staging slot, points it at the freshly migrated branch, and runs the full application test suite. This ensures that every PR validates both the migration and the new application image together before any changes reach a production-like environment.

This process mirrors how one might approach OLTP database CI/CD.

Migrations as the Source of Truth

The linchpin of this system is the principle that database migrations, not the databases themselves, are the source of truth. Changes are promoted not by copying data between branches, but by re-running the ordered set of migrations against the target branch.

Branches are intentionally disposable. If a refreshed branch is missing a change, the subsequent migration replay will apply it. This focus on migration replay ensures consistency and reliability, even with frequent environment resets.

This approach to branching databases like code is a significant departure from traditional methods.

Promotion and Tradeoffs

After a PR is merged, CI re-runs migrations and tests against the target branch, typically development. Promotion to acceptance and then production environments involves manually approved gates. Each gate triggers CI to replay migrations against the next environment in the promotion pipeline.

Glaspoort acknowledges a tradeoff between merging as soon as CI passes versus waiting for full promotion through acceptance. They opted for a velocity-first approach, bolstered by safeguards like stack revalidation and a crisis pipeline for critical situations. This decision reflects a commitment to rapid iteration while maintaining production stability, a core tenet of Databricks Lakebase branching.

The company also highlighted how Databricks Lakebase branching supports agentic AI development, a testament to its flexibility.

This is how Glaspoort ships database changes with the same rigor as application code.