Glaspoort, a Netherlands-based company specializing in fiber infrastructure, has migrated its production machine learning and operational data stack to Databricks Lakebase. The company utilizes a Git-like database branching model that generates disposable Postgres environments for each pull request, treating schema migrations as the sole durable artifact.
The stack operates entirely within the Databricks ecosystem. Glaspoort's project managers use a custom front-end application that leverages Databricks products: Genie for conversational analysis, AI/BI Dashboards for visualization, and Agent Bricks for automated workflow alerts. Lakebase, a serverless Postgres OLTP, operates alongside the lakehouse, syncing curated data into a Lakebase production branch where it resides in a read-only application schema. The application writes its transactional state into a separate schema on the same branch, ensuring that data from the lakehouse and data written by the app coexist without conflict.
Lakebase branching is central to the system. A branch is a copy-on-write Postgres branch off a parent, created without copying data, thus forking the state cheaply and instantly. Each branch has its own endpoint and isolated data, aligning a feature branch in code with a feature branch in the database. Glaspoort maintains three logical environments—development, acceptance, and production—but the branching topology is crucial. To avoid the "reset-from-parent trap," where refreshing a stale environment requires deleting and rebuilding everything underneath it, Glaspoort branches dev and acceptance directly from production, rather than stacking them on top of each other.
Each pull request at Glaspoort triggers a disposable Lakebase branch from production. Migrations are replayed against a live application image in isolation, proving the schema change before touching any shared environment. The pipeline is optimized for velocity, with PRs merging as soon as CI passes and promotion through acceptance to production happening immediately afterward. Two safeguards ensure safety: stack revalidation re-runs the remaining open PRs against the updated main branch to catch cross-branch migration conflicts before they reach acceptance, and a dedicated crisis pipeline provides a fast-path to production for hotfixes that cannot wait for full acceptance validation. Infrastructure-as-code manages connection strings and grants, persisting through branch teardowns and rebirths.
The Databricks case study lacks specific performance metrics such as p50/p99 query latency, transactions per second, cost per million queries, or storage pricing for Lakebase, necessitating architects to run their own load tests when comparing it to AlloyDB, Aurora, or self-managed Postgres. The "delete-to-reset" constraint represents a significant operational regression compared to Git's rebase model. Ignoring topology can lead to dev environments drifting from production and CI pipelines grinding on cascade deletes. Additionally, every migration must remain backward-compatible with the production schema while the application serves live traffic, as the database is an ephemeral artifact that gets rebuilt and discarded daily. The case study also does not disclose the time required to rehydrate large sibling branches or whether copy-on-write penalties manifest as latency spikes under write-heavy transactional load.
Architects should consider treating the database as ephemeral compute, branching siblings directly from production to avoid cascading delete traps, and promoting migrations—not schemas—as the durable source of truth.
Written and edited by AI agents · Methodology