Introducing Consort: Test-driven development on a branching database

Databricks Field Engineering has released Consort, an open-source agentic framework for test-driven development on a branching database, built on Lakebase Postgres. The framework enables developers to branch databases like code, run tests against real data in the inner loop, and catch production issues before deployment. Consort uses Lakebase branching to support integration testing, schema migrations, and a multi-agent workflow.

An open-source agentic framework, built by Databricks Field Engineering, for test-driven development on a real branching database. For 25 years I built software on the practices I grew up with: Kent Beck’s TDD, Martin Fowler’s Refactoring, Uncle Bob’s Clean Code, Jez Humble and Dave Farley’s Continuous Delivery, Pramod Sadalage and Scott Ambler’s Evolutionary Database Design. With modern software development practices, code can be branched, environments are containerized and infrastructure becomes code. But one part of the stack never played along: the database. It sat there as a rigid monolith, and we accepted many workarounds because of it such as mocks instead of the real thing, a shared staging box and schema changes running as a careful ceremony. I’ve been speaking with software dev teams about Lakebase Postgres https://www.databricks.com/product/lakebase for a while now, and how it changes what we used to do. You might have heard me say: Branch your database like you branch your code. But what does that mean in practice, and how do I apply it? Integration testing comes home to the inner loop Testing against a real database used to be an outer-loop concern. Standing up a database, seeding it with schema and data, versioning the schema, and doing it per unit test was too expensive, so I didn’t. Nobody did. We wrote unit tests against mock objects instead, not because mocks were good, but because a real database in the inner loop was out of reach. And we know that mocks drift over time; they fall out of step with how the database actually behaves and the more you maintain them, the less real behavior they verify. Copy-on-write branching removes the reason for mocks to exist. You create an isolated branch of the real database in roughly constant time, regardless of data size. The first test I write, TDD-style, runs against a live branch of real data, not a fake. I can run destructive tests, blow up everything, hose up my schema, and never touch what the rest of the team is on. It’s my branch. When I’m done, I throw it away. Code and schema ship as one Because the schema now travels as versioned migrations Alembic, Flyway, or Knex, by stack , a schema change and the code it depends on, moves together as a single unit. You merge the schema not the data , and the code lines up with it. Two engineers I showed this to, on different teams, landed on the same phrase for it: Data CD. The 2 a.m. production break gets caught before it happens When something breaks in production, it’s usually at 2 a.m., and you’re reverse-engineering what changed. Branching flips the timing. On every pull request, and again on merge, you create a fresh database branch from the target environment, run the migrations and the full test suite against it and find the regression or the collision before it gets deployed. The schema change is in the pull request as a migration, so your DBA reviews it there as a code owner, not a ticket in a downstream queue. Promoting a schema change used to be a high-risk ceremony. Now you branch prod, apply the change, test it in isolation and promote. Doing the same on a vanilla cloud Postgres setup takes a pile of fragile DevOps scripting and wastes precious human time. None of this is a database feature you switch on. It’s a shift in when the hard testing happens, all the way left, in the loop where you’re actually writing the code. Now that the infrastructure for branching is here, what’s been missing from the conversation is something that puts it to work in a real development loop. That’s why I built Consort https://github.com/databricks-solutions/consort . Consort is an open-source agentic development framework that uses Lakebase branching as the foundation of its test-driven build. If you know Scrum, the idea is in the name. Each role on the team product owner, spec author, architect reviewer, DBA, test strategist, and a navigator/driver pair becomes an agent. They perform together, led by a conductor, and ultimately perform as a consort. Work runs in two lanes: a spec-first design lane where intent is agreed and frozen, and a build lane that runs the full red/green/refactor cycle against a live branch of the real database. A few components make it hold together when an agent is the one writing the code. As an optimization strategy so your agents don’t spend the beginning of each turn re-scanning everything , Consort feeds each agent a scoped context package, the exact tests to pass, the design requirements and where those tests live, instead of turning it loose on the whole codebase. Unscoped access is how agents drift, and how they spend eons thrashing over the code trying to figure out what to do and where it goes until they forget what DRY means. The architect reviews the spec before any code is written and layers in the design you care about including the cross functional requirements, the layering, patterns like DRY, SRP and SOLID. That upfront design is why you don’t end up with everything in one file. And when you want to explore, Consort runs parallel experiments for a story, each on its own database branch and worktree, fully isolated, so you can try more than one approach and keep the better experiment. When I’ve shown this to other engineers, they tend to recognize it immediately as the thing they’d been trying to build themselves. You can watch all of it, and steer the direction. A VS Code plugin shows your paired Git and Lakebase branches across tiers, with code and schema changes in a single diff view. An observability dashboard shows each turn live: every role, its prompt, and the artifacts it produces for the next role to consume. And at each gate you inspect the working software yourself, running against its own branch, before you approve it forward. Consort is open source and community-supported. It’s a project you can adopt, run and recommend, with its own lifecycle. It’s not a bundled platform feature with an SLA. You don’t have to rewire your stack to use it. Lakebase is Postgres, so your finished app runs on it with no branching workflow required; the paired Git and Lakebase branching is something you do during development. For 25 years the database was the one part of our stack that couldn’t branch. Now it can. That’s what changes, and it’s why I built Consort. You only need Lakebase. Get it on Free Edition https://login.databricks.com/signup . The rest of the stack is open – Java, Python, or Node – and it runs on Claude and has a VS Code plugin companion. When you’re ready, it’s three commands: /consort:start walks you into a project. Start with the StockFlow example. It seeds with three files, and you can watch it grow into a full codebase from there. If this work inspires you and you want to make it better, I’m looking for more contributors and codeowners. If you’d like to join in, or just to see how the internals work, visit the repo: https://github.com/databricks-solutions/consort https://github.com/databricks-solutions/consort Subscribe to our blog and get the latest posts delivered to your inbox.