Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort

Summary

Glaspoort replaced a sprawl of outdated, one-off BI reports with a custom application that combines Databricks analytical tools with Lakebase, a serverless Postgres OLTP database. The application keeps curated lakehouse data in a read-only schema while application state occupies a separate schema, and supports development, acceptance, and production environments. Its CI/CD pattern treats database branches like code: long-lived environments branch directly from production, each pull request receives an ephemeral production-shaped branch, migrations are replayed, and a staging app image runs the full test suite against it. This topology makes periodic resets cheap, avoids deleting dependent branches, and preserves fresh test data; the team chose stacked promotion for velocity, retaining a separate crisis pipeline for urgent fixes.

Takeaways

1. 1

   Development and acceptance are sibling branches of production rather than parent and child; resetting either branch therefore does not require deleting dependent environments, rewiring connection strings, or reapplying inherited grants.

2. 2

   CI creates a fresh production-based branch for each PR, replays migrations when the Git diff requires it, deploys the new application image to a staging slot, and runs the full test suite before the branch is archived when the PR closes.

3. 3

   The team chose stacked promotion because it suits overlapping work in a small team; every promotion gate validates stacked migrations against a fresh production fork, while a separate crisis pipeline provides an urgent-fix path.