Let AI Work on Your Database: Safe AI-Driven Development with Database Branches

Summary

This video demonstrates how Lakebase's branching capabilities enable AI coding agents to work on isolated database environments, eliminating the risk of destructive actions on production data.
Lakebase branches act as fast, low-cost pointers to production data, allowing AI agents and developers to experiment and build in parallel without duplicating data or compromising production stability.
Practical patterns covered include parent branch isolation, a merge model for validated changes, and a Lakebase skill that guides AI agents toward safe database development practices automatically.

Let AI Work on Your Database: Safe AI-Driven Development with Database Branches

AI coding agents have drastically improved the way we work in so many areas of software development, but because LLMs are inherently non-deterministic, many developers are still hesitant to let AI agents touch their databases because of the risk of destructive actions. In this talk, we’ll show how to safely leverage AI in real workflows using Lakebase’s branching capabilities. With the tools and strategies we’ll discuss, you will be able to create isolated code and data environments that enable AI coding agents to build in parallel, experiment safely, and iterate faster, without risking production data. By the end of this talk, attendees will walk away with practical patterns to integrate AI into their development workflows with confidence.
Talk By: Anthony Giuliano, Developer Advocate, Databricks ;

Chapters

FAQs

Why are AI coding agents particularly risky when they interact with databases?

Unlike UI changes such as adjusting a border radius, database operations are often irreversible—deleting or corrupting data can cause immediate production outages. Headlines about AI agents deleting entire company databases in seconds illustrate that the risk is concentrated at the data layer, not at the application layer.

How does Lakebase branching solve the speed-versus-safety dilemma for AI development?

Lakebase branches create isolated environments that are fast, low-cost pointers to production data rather than full data copies, so AI agents can build and experiment freely without touching the production database. Changes are only promoted back to the parent branch after they have been validated, preserving both development speed and production safety.

What is the merge model for Lakebase database branches?

When a developer or AI agent finishes work on a Lakebase branch, changes can be reviewed and merged back into the parent branch through a controlled process similar to a code pull request. The parent branch remains isolated from branch activity until a merge is explicitly approved, ensuring that only validated changes reach production data.

What is the Lakebase skill mentioned in this video and how does it guide AI agents?

The Lakebase skill is a set of instructions that can be provided to an AI coding agent to automatically steer it toward safe database development practices using Lakebase branching. Rather than relying on the agent to independently choose safe patterns, the skill encodes the branching workflow so agents follow it by default during database-related development tasks.

Full transcript

[00:09] All right, folks. So, I don't know if any of you have been on the internet lately, but if you have been, you may have come across some headlines that look something like this. Claude AI agent deletes company's entire
[00:21] database. And it only took 9 seconds. Now, this, of course, is a developer's worst nightmare. And the unfortunate reality of this situation is that this is not a one-off
[00:34] instance where some particularly unlucky company just happened to be the victim of an AI agent gone rogue. We are seeing headlines like this in our industry all the time now. And in my opinion, these kinds of
[00:46] stories are popping up left and right because of a central dilemma that a lot of us are facing right now in our industry as we're all trying to incorporate AI into our software development workflows.
[00:58] And that dilemma can be summed up as speed versus safety. It feels like these days with AI, this is the central trade-off, right? AI has made it easier than ever before
[01:10] for us to move quickly. We know that. We're seeing that with the pace of the industry. But now, we're also starting to see stories like this that are indicating that sometimes, if you move too quickly and you don't have the proper guardrails
[01:22] in place, you could find yourself in this position. Now, in Claude's defense, it did move quickly here. Only 9 seconds to do the job, just maybe in the wrong direction.
[01:34] I'm seeing some folks with some headphone issues. Is everyone okay? All set? You guys okay over there? Perfect. Okay.
[01:47] So, obviously, going too fast and sacrificing safety can present some dangers. We've seen this. But the inverse is also true. Because of course, it's important to emphasize safety, but if you emphasize it so much
[01:59] that you restrict your agents and you slow them down, they run the risk of not being able to build quickly. And if not able to build quickly, then your competitors may have an advantage over you. And that presents a danger just in
[02:13] a different kind of maybe less obvious way. So, this starts to feel like a bit of a catch-22. Now, what I find most interesting about stories like this is that they are always about the database. You're never
[02:27] going to see a story like this, a headline that says, "Claude, AI agent changes the border radius from 12 pixels to 24 pixels." It's not going to happen. Agents may do that, they may affect affect your app in different ways, but these aren't
[02:40] severe circumstances. It's only when we're interacting with the database. And I think this is because of two main reasons. The first is that data for most applications is critical. Again, you can
[02:52] have an agent that maybe introduces a bug in your UI or in your front end, but you can survive that. When it comes to your data, if an agent deletes a production table, the consequences are much more severe.
[03:06] The second reason I think we're seeing this around the database is because in this new age of AI, much of the development stack has adapted and flexed to conform to our new practices that
[03:18] we're creating. So, if we take a look at the stack, we can see where AI has made its way into all different phases of development. Agents are very good at code generation, we know this. And so, as a result, there
[03:32] are all of these new workflows that are starting to emerge. When it comes to writing code, we're not just working one-on-one with an agent anymore. Now, we're using tools like Git work trees or agent orchestration tools like Omnigen
[03:45] to allow our agents to develop in parallel. But agents, of course, aren't just good at writing code, they're also good at testing code. And so now they're writing entire test suites for the code that they're generating. There are even tools
[03:58] now where agents can view their changes in a browser to verify the results of the changes they've made. But, it doesn't stop there because now when you go and create a PR for your change, your agents are automatically
[04:10] reviewing your PR and suggesting changes or even making those changes directly. And eventually when you deploy that change, there are agents running in the CI/CD pipeline to diagnose issues and proactively fix any of your failed
[04:23] builds. And these are just a few examples. Agents are everywhere and probably in your own workspaces uh in the work that you're doing today. But, when it comes to databases,
[04:35] not much has changed. Things kind of still look the same. And that's because when you think about it, databases were never that well integrated into the system to begin with. For a lot of folks, this is what the
[04:47] system of databases looks like today. Of course, you've got your production database, but then you've also got your database for staging, a testing database, a dev database that maybe a development team is sharing or more
[04:59] likely fighting over. There are all of these uh disparate databases that you have to manage. All of these have to be actively managed. Each database also presents an opportunity to drift from production and
[05:11] then thereby present issues. And each of these databases costs money. And we've all just kind of come to accept that this is the way of the world when it comes to databases, that we all just operate in this messy conglomerate
[05:24] of tooling. But, in the age of AI now, all of the problems associated with this are now being exacerbated by the pace and the structure that we're working with with all of our AI tools.
[05:37] And as a result, databases have become the bottleneck for a lot of teams. All these other areas of the stack have adapted and adjusted, but databases seem to be lagging. So, we need a way to remove this
[05:49] bottleneck. And this is where Lakebase comes in. Now, just as a reminder, Lakebase is a fully managed serverless Postgres database. And it it interacts directly with the lakehouse, so that way you can
[06:02] move your data seamlessly between systems. And most importantly, Lakebase separates storage and compute. And by virtue of doing that, what this architecture enables is a way for our database to adapt to agentic
[06:16] development. And specifically, this enables database branching. Database branching is the missing piece uh in order when it in come when it comes to uh getting both the speed and
[06:28] safety of the trade-off that we're working with. So, how does it all work? Well, database branching is exactly what it sounds like. It's the idea of branching your database the same way
[06:40] that you branch your code. So, in this instance here, we have a production database that's serving your app. And then from there, we can create a branch for a specific feature that we want to work on. And what this branch does is it
[06:52] essentially creates a copy of your database. And that copy will include both the schema and the data of your production database, so you're getting a production-like environment. Now, I say essentially a copy because
[07:05] it's not actually a copy in the way that you may be thinking where you fully deep copy all of your data. Instead, what we do is we do what we call copy on write. And the idea with copy on write is that
[07:17] when you create a new branch from your production branch, your data isn't actually copied over. Instead, your branch starts empty. And it just has a pointer that points back to the data in production. So, when you
[07:30] perform any reads on your feature branch, that data is actually going to be just pointed back to the data you have in production. And we call it copy on write because it's only when you actually write to the database that those changes start to get
[07:43] uh incorporated into the branch. So, if you insert a new row, if you modify the schema, if you delete your data, hint hint wink wink, uh these kinds of modifications are going
[07:55] to be captured in the branch, but all of your unmodified data is still going to reference the production branch. And this is cool. I think the tech is really interesting, but why does this even matter in the first place?
[08:08] It matters because this structure now makes your branches both fast and cost-efficient. Because you're not actually copying over your data anymore, you're just creating a pointer. It also means that the time to create a
[08:21] branch is independent of the size of your database. So, if you have 1 GB of data in your database, or if you have 1 TB of data in your database, it's going to take the same amount of time to create a branch. Because again, you're
[08:33] just creating a pointer. So, now that we have these really fast, cost-efficient, lightweight branches, you can treat them as temporary environments. Because there's no longer this huge
[08:45] upstart cost of copying over all of your data, something that takes time. You don't have to worry about your data going stale, because everything uh just kind of comes together with this copy-on-write architecture.
[08:57] And so, we're not facing any of those traditional problems that we get with the previous kind of database setup. So, now you can spin up a branch, you can use it for whatever you want to do, you can migrate changes over to
[09:09] production if you like them, or if not, you can just throw it all away. Everything is ephemeral now. And these kinds of temporary environments are perfect for your agents. Each agent is now able to spin up a
[09:22] branch, make changes as it sees fit, and all of those changes are isolated from production. Which means now when you give an agent a branch, nothing in production is affected, and your agent is able to work as quickly as it wants, is able to test
[09:35] and do any destructive actions that it wants all in the branch and keep everything isolated. So, now we understand the theory of it all, but I want to show you guys a more practical workflow, how you can actually use branches.
[09:47] So, we'll jump on over here. So, if you haven't seen it yet, this is what the Lake Base console looks like. And so, this is a very simple little to-do list app that I've created kind of just to walk you through some of the
[10:00] capabilities here. So, you'll see right now we're using our production branch. And if we come on down to the table section here, you'll see I've got this little to-dos table with a few to-dos in here.
[10:13] In order to create a new branch off of here, I'm going to come over to branches and click new branch. I'll get a few options here, the first of which is the name for the branch. So, I'm going to
[10:25] call this my dev branch, for example. We'll also get this drop-down to select the auto-delete timeline. This is essentially a TTL. Um I like the default of 1 day, especially for agentic development, but you can configure it however you'd like.
[10:38] And then, in addition, we have the parent branch. The parent branch is where we are essentially cloning or copying from. Um so, nine times out of 10, you're going to want to use the production branch here, but if you have other staging environments, testing
[10:50] environments, you can pull from those as well. And then finally, we select if we want to use the branch the data and schema from right now, or if we want a previous point in time. I'll keep this all as the
[11:02] default and I'll click create. When we do that, Lake Base is going to provide us with all of the environment variables, the credentials that we're going to use to connect to this branch. I won't use them right now. I'll just
[11:14] close this out. And now, if we jump over to uh the side over here, you'll see that we have our dev branch that we're looking at. So, if I come back down to tables,
[11:27] we've now got a copy of all of the table the to-dos that we were working with. The nice thing about this branch though now is I can click over here and I can delete all of this data. Maybe this is something that your agent is doing, and just getting rid of all the data in your
[11:39] database. And now if I come back to my production branch, all of the data is still here. So, this is just a way to to show that you can do whatever you want in these
[11:51] isolated dev environments, and all of your production data stays completely unaffected. The other thing that you can do is if you come back over to your branches, and I click over on my dev branch, I can come back and say reset
[12:03] from parent. And so, if any destructive actions do happen in your, uh, branches that you don't want, you can essentially revert back to your parent. So, one last time, if I come over to the tables,
[12:15] you can see all the data is back in here in my dev branch. Oh, sorry, this is in, uh, production still. Let's go over to dev. Let's see. All of the data is still there.
[12:28] This is more a way to visualize, uh, things. And the console is helpful in terms of spot checking things. But, more likely you're going to be operating in your IDE or in the terminal. And so, we have a CLI attached to Lake Base that
[12:40] you can also use under the Data Bricks Postgres name here. And so, this is just one example. You can create a branch, specify the project, the name of the branch, and again, things like the the source branch, that's the parent branch,
[12:52] and the time to live in seconds. But, it is of course 2026, so anywhere there's a CLI, there is an agent following not too far behind. So, I want to show you what I do in terms of my
[13:05] actual setup whenever I'm building apps on Lake Base. Here in my agents.md file, I've created this what I call mandatory feature workflow. And the idea here is that every time I build out a new feature, my agent is
[13:18] going to follow these five steps in order to create an isolated environment. So, the first step, of course, is creating a Git branch. Pretty standard. The second step though is on top of that Git branch, we're going to create a
[13:31] database branch, a Lake base branch. And make sure that we specify which project we're working in because odds are you may have more than one project in your workspace. So between those two branches, Git for code and the Lake base branch for your data, we now have a fully isolated
[13:45] environment that we can work in. Again, I'll set the TTL. I like to set the default for, you know, 1 to 7 days. You can also override this if you need to. But once we have that environment, all we need to do is point our application to it. So we're going to say that we
[13:58] want to take the local database environment variables and point them to that new Lake base branch. Once we do that, your agent is free to make any changes it wants. It can go in and build out the feature, test a bug,
[14:10] whatever the case may be. Um and if it makes any schema changes and decides to affect the schema in any way, we're going to make sure that we tell it to only make schema changes to the feature branch and never the production branch. We'll handle all of the production
[14:22] migrations in our CI/CD pipeline. So this is what it looks like in terms of building out your agentic workflows with Lake base. So if I jump back over here,
[14:34] this is all really cool, of course, but I want to be clear that branches are just one piece of the puzzle. They enable your agents to move quickly in an isolated environment, but they are not a replacement for standard security
[14:46] practices. You still want to make sure that you're taking all of the proper precautions when it comes to using any kind of database for that matter. So things like when you're running your agents, running them in an isolated sandbox. Also giving your agents tightly
[15:00] scoped permissions to make sure that they only have access to the things you want them to. Marking your production branch as protected. This is something that you can do in Lake base and essentially it's a added layer of security that makes
[15:12] sure that no matter what, your production branch cannot be accidentally deleted. And then finally, if you need to, leaning into Lake base's a recovery methods if you ever need to roll something back, should something go
[15:24] awry. But, with this system in place, hopefully we never reach that point. Now, I show all of this because what I'm showing here today is really just the beginning of what you can do with branches. There are a whole lot more
[15:36] ways that you can configure branches in your development workflows. Uh so, one example that I really like is if you're using any kind of orchestration tools, Omnigen, uh what you can do is you can attach a database branch, a Lake Base
[15:49] branch, to each of your Git work trees. So, that way if you have multiple agents running in parallel, they're not going to step on each other's toes when it comes to changing anything in the database. Uh the other thing that you can do is integrate branches into your CI/CD
[16:02] pipeline. So, if you have preview environments set up, for example, you can use a Git hook to hook a new Lake Base branch into every PR that you create. So, that way anytime someone comes along to review your PR, should
[16:14] that be a human or an agent, uh they can interact with that environment, again, not affecting production or even your own development environment. Given that, there is a lot that you can do with Lake Base branches. So, in the
[16:26] spirit of agentic development, we've created a skill for you to use with Lake Base. And you can install it with Databricks AI Tools install. The idea here is that we want to give your agent some guidance uh in terms of
[16:39] working with branches and other features of Lake Base, for that matter, um in a way that fits your specific use case. Because we want you to be able to start moving quickly, but again, we want to do things properly and safely, as well. And
[16:53] the agent is going to help, or the skill is going to help guide your agent in that way. Surely, it goes without saying that this skill, albeit helpful, uh does not absolve you of any responsibility that you have as a developer, as someone uh
[17:05] owning your database. Um this skill is more meant to guide, but it's also important that as you adopt these new tools, you're learning alongside that skill uh to see and understand how how agent is affecting your security posture.
[17:18] I know I covered a lot, but all of this is to show that in this new agentic world that we have, our systems are changing. Development workflows are changing. And these changes are exciting. They're going to introduce new ways for us to
[17:31] build and new things that we can build with these new uh processes. But we need to take our database with us. And now with branches, we can. Thank you all so much.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.