--- title: Branching databases like code: a CI/CD pattern for... description: Glaspoort, a Dutch fiber infrastructure company, describes how they implemented a CI/CD workflow for their Databricks Lakebase (serverless Postgres OLTP)... canonical: https://daily.dev/posts/branching-databases-like-code-a-ci-cd-pattern-for-lakebase-in-production-at-glaspoort-shn6oybua twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort | daily.dev og:description: Glaspoort, a Dutch fiber infrastructure company, describes how they implemented a CI/CD workflow for their Databricks Lakebase (serverless Postgres OLTP)... og:url: https://daily.dev/posts/branching-databases-like-code-a-ci-cd-pattern-for-lakebase-in-production-at-glaspoort-shn6oybua og:image: https://api.daily.dev/og/posts/ShN6oYbUa.png og:image:alt: Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort **[databricks](https://daily.dev/sources/databricks)** · 11 min read · 39 upvotes · 3 comments ## Summary Glaspoort, a Dutch fiber infrastructure company, describes how they implemented a CI/CD workflow for their Databricks Lakebase (serverless Postgres OLTP) database. The core pattern: all long-lived environments (dev, acceptance) branch directly from production rather than from each other, eliminating the costly cascade of deleting child branches when refreshing. Each PR gets its own ephemeral database branch forked from production, and migrations serve as the single source of truth — changes are promoted by replaying migrations against target branches, never by merging data. The post also covers a tradeoff between two merge strategies (merge after CI vs. merge after full CD promotion), token-based auth with short-lived credentials, and grant inheritance via branch forking. The result: no more shared environment coordination, no drift, and safe hotfix paths. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why should dev and acceptance database branches be children of production instead of being nested under each other? Nesting causes a costly cascade: resetting a parent branch requires first deleting all its child branches, so refreshing dev from production would force deleting acceptance and every feature branch hanging off it, plus re-wiring connection strings and re-applying grants. Making dev and acceptance siblings that both branch directly from production means refreshing one never affects the other, so resets stay cheap and teams actually do them. _Anyone designing database branching strategies can compare real production topologies like this one on daily.dev._ ### How does Glaspoort handle database credentials for its Lakebase-backed application without storing a long-lived secret? A static password stored in Azure Key Vault is used to mint a short-lived database credential with a 60-minute TTL via the databricks postgres generate-database-credential command. Because the token expires hourly, the client refreshes it proactively using an async password function on the connection pool that caches the credential and rotates it before it lapses. _Developers wiring token-based database auth can find implementation patterns like this through daily.dev._ ### What is the trade-off between merging a PR after CI passes versus after it's promoted through dev and acceptance environments? Merging after CI passes lets teammates build on each other's changes immediately but risks multiple merged PRs stacking together when promoted, with hotfixes needing a parallel pipeline to bypass the queue. Merging only after promotion through dev and acceptance gives each PR independence and a clean hotfix path, but teammates must wait for acceptance to go green before building on a change. A small team working on overlapping changes benefits more from the first approach. _Teams deciding on a merge-and-promotion strategy can weigh trade-offs like these on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@trevorsuna** · 0 upvotes > Forking each PR from production while promoting only migrations is the key bit here. It gives developers realistic data shape without turning database branches into another source of drift. **@quest4jolt** · 0 upvotes > A solid CI/CD pattern, but migrations still seem to be the source of truth. but doesn’t treating migrations as the source of truth leave a gap where database state lacks native commit history and merge semantics etc? ## Similar posts on daily.dev - [Database Branching in Postgres: Git-Style Workflows with Databricks Lakebase](https://daily.dev/posts/database-branching-in-postgres-git-style-workflows-with-databricks-lakebase-hdnh9bdho) · databricks · 23 upvotes · 0 comments - [Enabling Evolutionary Database Development: database branching with Lakebase](https://daily.dev/posts/enabling-evolutionary-database-development-database-branching-with-lakebase-o3cvra6aw) · databricks · 0 upvotes · 0 comments - [Practical Guide to Database Branching](https://daily.dev/posts/practical-guide-to-database-branching-hgm43imgd) · Neon · 1 upvotes · 0 comments - [Anthropic recommends a git worktree per agent. Your runtime infra makes that a problem.](https://daily.dev/posts/anthropic-recommends-a-git-worktree-per-agent-your-runtime-infra-makes-that-a-problem--wxsvazqwq) · The New Stack · 3 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#cicd](https://daily.dev/tags/cicd), [#databricks](https://daily.dev/tags/databricks) [View this post on daily.dev](https://daily.dev/posts/branching-databases-like-code-a-ci-cd-pattern-for-lakebase-in-production-at-glaspoort-shn6oybua) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort","url":"https://daily.dev/posts/branching-databases-like-code-a-ci-cd-pattern-for-lakebase-in-production-at-glaspoort-shn6oybua","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/branching-databases-like-code-a-ci-cd-pattern-for-lakebase-in-production-at-glaspoort-shn6oybua"},"datePublished":"2026-07-20T20:33:57.774Z","dateModified":"2026-10-15T02:22:23.548Z","description":"Glaspoort, a Dutch fiber infrastructure company, describes how they implemented a CI/CD workflow for their Databricks Lakebase (serverless Postgres OLTP)...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3dad675d05c8d65e5cdc90400bc1107d?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3dad675d05c8d65e5cdc90400bc1107d?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"databricks","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"databricks","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/fa7aa720f2db4d1eba826814730482c8","url":"https://daily.dev/sources/databricks"},"commentCount":3,"discussionUrl":"https://daily.dev/posts/branching-databases-like-code-a-ci-cd-pattern-for-lakebase-in-production-at-glaspoort-shn6oybua","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":39},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":3}],"keywords":"database,cicd,databricks","timeRequired":"PT11M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"databricks","item":"https://daily.dev/sources/databricks"},{"@type":"ListItem","position":3,"name":"Branching databases like code: a CI/CD pattern for Lakebase, in production at Glaspoort"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/branching-databases-like-code-a-ci-cd-pattern-for-lakebase-in-production-at-glaspoort-shn6oybua","comment":[{"@type":"Comment","text":"Forking each PR from production while promoting only migrations is the key bit here. It gives developers realistic data shape without turning database branches into another source of drift.","datePublished":"2026-07-21T02:20:52.963Z","url":"https://daily.dev/posts/ShN6oYbUa#c-CHBACpwOB","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"}},{"@type":"Comment","text":"A solid CI/CD pattern, but migrations still seem to be the source of truth. but doesn’t treating migrations as the source of truth leave a gap where database state lacks native commit history and merge semantics etc?","datePublished":"2026-09-14T18:59:48.333Z","url":"https://daily.dev/posts/ShN6oYbUa#c-0DCLkWrAo","author":{"@type":"Person","name":"J-dawg","url":"https://daily.dev/quest4jolt","image":"https://lh3.googleusercontent.com/a/ACg8ocKhFgP1EkhUsabwdXHwFacFAAPl0xYwcWaTMOAcLVryCsQKQ30=s96-c"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/branching-databases-like-code-a-ci-cd-pattern-for-lakebase-in-production-at-glaspoort-shn6oybua#faq","mainEntity":[{"@type":"Question","name":"Why should dev and acceptance database branches be children of production instead of being nested under each other?","acceptedAnswer":{"@type":"Answer","text":"Nesting causes a costly cascade: resetting a parent branch requires first deleting all its child branches, so refreshing dev from production would force deleting acceptance and every feature branch hanging off it, plus re-wiring connection strings and re-applying grants. Making dev and acceptance siblings that both branch directly from production means refreshing one never affects the other, so resets stay cheap and teams actually do them. Anyone designing database branching strategies can compare real production topologies like this one on daily.dev."}},{"@type":"Question","name":"How does Glaspoort handle database credentials for its Lakebase-backed application without storing a long-lived secret?","acceptedAnswer":{"@type":"Answer","text":"A static password stored in Azure Key Vault is used to mint a short-lived database credential with a 60-minute TTL via the databricks postgres generate-database-credential command. Because the token expires hourly, the client refreshes it proactively using an async password function on the connection pool that caches the credential and rotates it before it lapses. Developers wiring token-based database auth can find implementation patterns like this through daily.dev."}},{"@type":"Question","name":"What is the trade-off between merging a PR after CI passes versus after it's promoted through dev and acceptance environments?","acceptedAnswer":{"@type":"Answer","text":"Merging after CI passes lets teammates build on each other's changes immediately but risks multiple merged PRs stacking together when promoted, with hotfixes needing a parallel pipeline to bypass the queue. Merging only after promotion through dev and acceptance gives each PR independence and a clean hotfix path, but teammates must wait for acceptance to go green before building on a change. A small team working on overlapping changes benefits more from the first approach. Teams deciding on a merge-and-promotion strategy can weigh trade-offs like these on daily.dev."}}]} ```