When AI Agents Write Your Code, Who Protects Your Database? - Amir More

Hey everyone. Uh thanks for coming to my webinar. Um I'm going to tell you a little bit about myself and then we'll jump into uh the presentation. Oh, let's uh click. So, before [clears throat] we start just a little bit about where BaseHit comes came from and a little bit about my background. Uh my background is as a DBA. I started off as an Oracle DBA around 25 years ago. In the last 10-15 years, I was more into the open source database arena. So, a bit of MySQL, a bit of but mostly Postgres. Uh during these years, I uh had the responsibility of uh being a a DBA of an operational database or actually multiple databases and uh I've come to learn what it means to be uh responsible for a database um and talking with my colleagues and people in the market, I realized that this is a a shared feeling. Uh when you're responsible for a database uh it it comes with some anxiety, right? Uh you you'd like to uh know that the database is running smoothly and that uh there's no sudden uh downtime, but on the other hand, developers are constantly writing code, constantly pushing new code to production and you know that some of that code is going to create problems. Uh there's going to be bad migrations, queries are going to change, uh not use indexes, there's going to be unexpected locking and a whole bunch of um weird issues that just come up in production. And so, having gone through issues like that and having gone through uh downtime uh and and lost nights and weekends, there is a certain anxiety that sets in where you realize that this is going to keep happening. Uh but at least we want to try and fix it. Right? So, our go-to move is usually to start with giving developers some sense of what will happen when they roll out to production. And now, in 2026, everyone, of course, is writing code with AI. So, whatever anxiety we felt for years when developers wrote code by themselves is now uh vastly um made worse by the rate of code being written uh through just prompting. Right? So, generally, let's get into this a bit. We try to solve this problem by giving developers some sort of copy of production. Uh sometimes there's some kind of staging, some sort of shared environment. Uh there's some mechanism where the developers can get a sense of how their change will affect production or how production will affect their changes. So, sometimes we have, uh as I said, a shared environment. Uh we take some nightly dump from production and we restore it in some R&D environment or we have some mock data or seed data. But, even before AI, um we've seen that this has uh not been up to speed. Uh we've already had problems, right? Uh when you have a shared environment, there's there's conflicts um at a certain at a certain scale, someone's always screaming, "Hey, who broke Who broke staging? Uh can we refresh staging?" Um nightly dumps uh are are only a little bit better, so they're they're kind of stale by the next day. Uh there's schema drift even if it's a nightly repair. Uh if you're using seed data, it's always missing some edge case or something's wrong with the distribution, right? So, the index works on the seed data, but it doesn't work in production. So, whatever we've been doing until now, it has only slightly helped, but not not made a measurable dent. And And the thing is, now that we're bringing in AI, this problem is exacerbated, right? If we needed for a handful of developers, we only needed a handful of environments, maybe we can get by with one. Now, with agentic coding, this this becomes a much bigger problem. We're just running more coding efforts at the same time, right? Developers are opening multiple tabs, they're they're using Cloud Code, Codex, whatever other system they're using for for launching prompts, and so these agents these agentic coding efforts are running in parallel, and they can clash, and therefore we want to give these agents their own sandboxes. So, whatever infrastructure we had, we probably need to extend it. It needs to grow by an order of magnitude in the number of environments it can sustain. Now, usually when I'm in person, I'll ask people to raise their hand, but uh if you have developers on your team writing code, then surely you know that they're not reading all that code. There might be some, you know, code rabbit or or similar products reviewing code in in a merge request or a pull request, but uh the code's being written, and it's not necessarily being vetted, and that's pretty bad. Uh and it's bad because uh the database is starting to become a kind of a bottleneck, right? Uh the agents and sometimes make weird mistakes. Uh these mistakes will cause them to just go off the reservation and drop tables, delete files, do all sorts of wonky stuff. And we need as the humans in the loop, we need to keep up with this, right? We need to repair the database. We have to create a database, which is a bit of a problem. With with agents, it's worse than that because if you're not reading the code, it isn't clear what are the agents doing to the database? Are they creating tables? Are they modifying tables? Are they modifying ever so slightly some queries such that they don't use indexes? Are they are they creating queries that happen to lock other queries in production? For for a human looking at code, typically they'll have the world view to try and at least predict or or raise a flag if there's some risk. The AI will just barrel ahead and and that really is scary. Finally, typically when you write code with AI, it doesn't necessarily know what's going on in production. Typically if if you're on Bob's team and you're writing a query and you know that Bob wrote a query that happens to interact with the same table, you have the decency to tell Bob, "Hey, I'm about to change your query." I'm about to affect your query or lock your query. The AI has has no such world view or won't necessarily let you know that something's about to change. It might not even know that something is going to affect something else in production. The AI doesn't necessarily have that world view and context of all the queries running in production. AI begins to be a bit of a problem when you want to write code in in serious systems that have you know uh old system of record behind it, many users and many downstream systems connecting to it. It's just hard to to make sure the AI has a full world view. So, we believe uh that part of the foundation of agentic development infrastructure is the database infrastructure, the database environment, or as we call them the database sandboxes. Uh you have First of all, you probably want to get some fresh data from production, obviously sanitized, anonymized, subsetted, what have you. Um you're going to need a lot of environments at scale, so you probably want to have anywhere between two and 10 times the number of environments as developers. And you're going to want them to be provisionable very fast, probably within seconds. And uh this is because uh when you're running agents and you're run running agentic coding prompts, uh you want it them to run as fast as possible. You don't want to wait, say, 10, 15 minutes, 20 minutes uh for for AWS RDS to spin up a clone, right? Or or similar, or GCP or or Azure. Uh you want you want speed. You want uh instances to start up, to shut down, to reset as fast as possible. So, let's talk a bit about how uh how we get uh copies from production. Uh if you've ever had this problem, if you've ever been uh the person that needs to create uh environments or sandboxes or preview environments, they go by name by many names, uh then you know that it's never just a copy. It doesn't end with, "Oh, let me just click a button in in the cloud and and set up a clone, or let me just dump and restore." There's a number of problems. Uh first, there's the issue of scale. It might be the case that one database is easy to start, but what happens when you have dozens or hundreds or even thousands of developers? Um managing hundreds of systems at the same time is a bit of a headache. Uh you have to run after developers, get them to shut them down. Uh you have to of course protect these environments. There's a security issue. Uh so at scale this begins to be an issue. One other problem here is also cost. Uh for example, let's say you have a production database in one of the managed cloud environments and that managed database costs you $100,000 a year. Say 8 9,000 dollars a month. For a a medium-size business, this is quite common. Um but now let's say you have a 100 developers and each developer has their own copy or or wants to have their own copy. If each development uh database copy is 100th the cost of production, so $1,000 per developer, and you have 100 developers, you're going to have to pay double production. So you're going to have to pay 100k for production and then another 100k for your developers' environment. And that can be prohibitive. Typically, companies just won't shoulder that bill and say, "Nope, we're not doing it. You'll have one or two stagings. Good luck with that." So scale is a problem. The second problem uh that I'd like to talk about is compliance. So you can't typically just give people copies of production if only because there's sensitive data and you have to sanitize it or subset it or both. Um this is just an issue of regulations. Uh for many B2B companies, it's also a problem of uh contractual obligation where you you have to um make sure that uh your your customers' customers' data never reaches R&D. Uh so there is an issue here of um modifying the data before it gets to a a developer's eyes or or agents' access uh after it leaves production. Uh next there's the issue of distribution. And I think this is somewhere uh that the operators uh the devops uh are are very familiar with this painful issue, but most uh database companies and and cloud providers, they're they're not at all attuned to this problem. Uh in in the real world, typically, uh you don't want people connecting to your production environment. Uh there's a an operational account or region, uh and you want to protect it. And so part of that protection is definitely not creating databases that are can be written to and modified and shared in that environment. Um what we also see is we see companies say, "Look, uh we don't want to mix and match R&D workload and production workload. There's operations and there's R&D, and we want to be able to set up a P&L separately." So for a variety of reasons, companies don't really want to connect R&D and developers to production. As a result, you have to take data from production and copy it out. And so now you find yourself having to distribute copies from one region to another, from one account to another, uh and this can be quite quite a hassle. Uh some companies even prefer to create a small version of production, wrap it up as a docker image, let you download it locally, depending on on their data and their and their compliance requirements. So everyone's trying to solve the distribution problem. And finally, there's the issue of speed. Even if you solve one or more of these issues, they always somehow run into a wall when the database starts growing. So imagine you have, you know, a one or two terabyte database, um creating a copy of such a database and then anonymizing it is a major headache. Uh you have to start updating large tables, uh then you have to get the indexes to update. That can be quite a problem. Um and therefore, when you start combining all of these problems, the headache becomes almost exponential because you have to solve multiple constraints at the same time. So, for this reason, uh we created Base Shift. So, Base Shift is an end-to-end, all batteries included solution to this problem. Base Shift will connect to production, uh either the master or your or your replica. Uh we will take a look at the schema, uh map out the PII by column name, by by content, uh suggest an anonymization policy, we will facilitate the copy of the data itself, uh we will anonymize data as it is copied or subset it or both. Uh we then create snapshots, which I'll talk about in a moment, and we facilitate the entire process of distributing and making available these snapshots to everyone in the business, including uh distribution to uh new geographic regions, uh monitoring uh and maintaining these copies, and auditing them. Uh and finally, we also provide uh added value services on uh the operations uh done on these copies. And we'll get into that in a moment. The point is it is a one-stop shop. We do all of it. Let's take uh a look at how all this works. Base Shift provides two components uh that you install in your cloud. Your Your data is your data. It doesn't sit in our in our cloud. Uh the two components are a server and a proxy. So, uh the server is uh is starts out as a pretty much empty container, and it detects what database you're running, so usually Postgres in our case. Uh we will take a look at um what version you're running, and we will spin up an instance of the database. So, if you're running Postgres, say 19.4, we will start up Postgres 17.4. Mind you, this is This is a regular Postgres, so it's a literal APT install Postgres. Uh this is a standard binary. It can also be MySQL and but uh the the focus is is Postgres. So, we start up a standard Postgres instance, and we connect through our proxy to the uh source database. Now, here's where we're very different from most products in this area. Typically, you'll make a copy of a database and then start anonymizing. Uh but we do it the other way around. So, we take data as it flies out of the source database, we pass it through our proxy, and that proxy will open up packets, literally disassemble the packets in real time, and replace any sensitive data uh with a anonymized uh masked um hashed version, and then and then put that put the packet back together and let it go. So, what you basically have is something like a restored dump, uh but it's already anonymized. The nice thing about this is once you've made that first copy, you can then use replication to transmit the deltas, right? A logical replication, if you will. Since we're passing all these packets through our proxy, we can then anonymize the changes themselves. So, what you've got is something like a read replica, because it's not wall-based, it's it's uh TDC-based, but it's already anonymized as it gets as it gets replicated. Now, here's the point where we uh start diverging from most other products in this area. Uh we create snapshots from this replica, but we use our own unique technology. We're not EBS uh or or equivalent in uh in Google and Azure. We're not uh some NFS or EFS. Uh, we don't use RDS. In fact, our snapshots are just files. Literally a directory with a whole bunch of files. Um, we can take these files and make them available to you in a variety of ways. The most common way uh that we uh that we make these um snapshots available is as a Docker image. So, we can take the files, we can uh gather them up, we can put them together with a database binary and extensions. Uh, it's all wrapped up into one Docker image. We can push it into uh some Docker registry like ECR or Artifactory. And uh and away you go. So, you can just do a Docker pull, Docker run, and and I'll be demoing this in a minute, uh where you can just connect it to your uh to your Kubernetes or download it locally, whichever you prefer. The other option is to directly start up a writable clone on this server. And you can start up multiple clones the same time. The idea is very similar to other uh copy-on-write uh systems. You have a snapshot, and that snapshot data is shared between clones. So, let's take a look at how this works. So, say you have a 1 TB database. Uh, just for for the sake of discussion, let's say it's an AWS RDS. And uh and you decide to make a snapshot of the whole thing. So, we'll make a copy. And um when we make that copy, we compress it like many storage systems. So, uh we'll see a ratio of about 1:3. So, that 1 TB will become 300 GB, uh but it will be already anonymized. Because as I said, when the data passes from the RDS to our instance, it goes to a proxy which modifies the data. Now, if you've done this process once, no matter how fast this process is for you, copy 1 TB is is no small feat. It takes quite a long time and it creates quite a lot of um of um of added IO on the source. So, you wouldn't want to do this daily. Nevertheless, after a day, you want to fresh copy of production. So, like I said, we do replication um and after a day, we can detect what has changed from one day to the next day 1% of the database and snapshot that again as a delta and compose the files. As a result, you'll have a snapshot directory. It could also be a a Docker registry and repository with two snapshots, the base and the delta. And just like it, you can spin up a writable copy starting from either or. Um in fact, you can spin up multiple copies. Uh you might be familiar with this concept uh from file systems like ZFS uh or or um branchable databases, same idea. So, you can launch multiple instances of Postgres, uh each writable, all of them sharing the snapshot uh the same snapshot, but they don't see each other. Uh they only take up space proportional to the amount of data you write to them. One important point here is this doesn't just happen on a server. You can create a Docker image and download that Docker image to some other server and get the same behavior. Uh when there's a new delta snapshot, you do a Docker pull, you'll just get the delta as a a new Docker layer, and then you can do another Docker on and away you go. So, that's kind of uh an example of what you can do with this technology. So, um I'm about to get to a demo, but before I do, uh what are some of the key benefits of of how Base Shift works? First of all, we have a pretty streamlined process. Uh so, I'll show you in a minute. We have a wizard that sets you all up. Uh it will install our our Docker containers in your uh environment. It could be Amazon, it could be uh a GCP, Azure, or it could be just some on-prem Kubernetes setup. It doesn't matter to us. Um as I said, uh we are security first. So, we believe your data shouldn't leave your network. Our on-prem install keeps everything on your side. Uh you even have your own encryption passwords and keys. Uh we don't we don't see them. We don't know them. We we typically see a large reduction in costs. They're something between 70 and sometimes 95% uh because you can provision clones pretty much without limit. Um and and you can do so in one or two or both modes. So, either you have a server launching clones uh similar to to other known systems. Or you can do everything in Docker. And so, it encapsulates everything for you. And finally, uh much as we love Postgres, uh Postgres isn't the only database out there. Uh we frequently see people using combinations. So, you'll see Postgres and Postgres and ClickHouse. Postgres and MySQL. There's There's all all sorts of stuff out there uh where the production environment is uh a composition of databases. Sometimes even multiple Postgreses, right? Uh you'll have uh basically a number of connection strings that together comprise what you might call the data environment. Um if you have such a data environment, it becomes quite cumbersome to build and maintain a solution that can snapshot and and and anonymize multiple such big databases simultaneously. And so, we understand this concept first class and we're able to snapshot an entire data environment and provide that data environment as a unified set of of Docker images or or server-based snapshots. So, um let's look at let's take a look at what this looks like with AI. So, um in a moment you'll see a demo where we start off with a prompt. Uh the prompt launches a coding agent uh with with regular LLM and that LLM will decide it needs a sandbox in order to run some database-oriented code. Uh in this case, it would be a simple migration. So, what you would typically have to do without Bay Shift is you'd have to you know, log into your your cloud environment, you'd have to set up a clone, you might have to run a script, or you might have to contact DevOps to do this for you, uh which is quite a headache. Um what the agent will do is it'll use MCP to directly spin up its own sandbox connected to it. Uh that sandbox is already up to date, it's it's isolated, no one else is seeing it, and it can't impact anyone else. And of course, that data is uh pre-sanitized. Uh the agent will attempt a migration. Um it'll probably fail because it's it's been set up to fail. And then it'll realize that the prompt uh didn't give it enough information to understand what it really needs to do in order to get the migration done. So, it will self-reset its environment and then try again. Now, at the other side of things, um as the developers, we're going to want to know what did this agent do to the database? At the very least at the very least, we need some factual explanation, right? We want to know um did it create a table? Did it modify data? Did it write some data migration? What are the what's called What is the shadow of the operation from the database's point of view? And so, we'll show you how BaseShift captures this information and presents it to you, or it could present it and reflect it back to the AI. Now, finally, I will give you a glimpse of where we're going. It's not enough to just see the factual um audit of what happened. Like, yes, it's good to know the database created a table and modified some queries, but what you really want to know is is there any inherent risk in this change, right? Are we are we somehow endangering production by writing a query or modifying a query, and we'll show you how BaseShift purports to to give you that information, provide a risk analysis, and and put up a flag in your PR and say, "Wait a minute, this is dangerous." So, without further ado, let's do a demo. Right, so, let's take a look at [clears throat] BaseShift. So, this is what we call our dashboard. What you can see here is what we call dubs. Dubs are a an instance of a source database, a masking policy and subsetting policy, and some uh snapshotting schedule. And you can have multiple such dubs uh supporting you at the same time. In this case, we took the well-known Acme HR demo database and created a dub out of it. You can see that this is a full copy dub, meaning it creates a whole snapshot nightly. It has some masking policy and you can see that despite the database being about 1.2 gigs, it compresses down to 370 megs. Now that we have one set up and I skipped the setup process intentionally, I'll show you what you can do with it. First, you can just get it as a docker. So you you have a a set of commands, you have off, you have a docker pull, docker run and just connect with PSQL and away you go. Of course, same instructions, you can set up your Kubernetes, have it download a docker image and you're good to go. At the same time, the server can launch a writable clone. So I click the button and in real time it has created a clone. I can launch another one. So I can click this again. phone And now there's two clones up. When I click that button in real time, an instance of Postgres has started on a server which would be in your environment. So the server is is connected to us via control plane and we give it the command and the the server spins up an instance of Postgres. We can typically spin up dozens, sometimes around 100 such instances on one server and the more RAM you give it, of course, the the more instances you can have. But one interesting property is because our snapshots are just files, like I said earlier, we can put those files in some shared storage like EFS or S3 or anywhere that you can share files and you can then just spin up more compute resources as you go. You don't have to scale up that instance. Everything you see here, you can also do through rest or CLI or MCP. So we'll we'll get to that in a moment. Now, let's take a look at how we do some some masking. So, we can take a look at a policy. We can see here our schema. You've probably seen similar tools before. Um you can choose a table and uh select some uh masking function on on certain Uh at the same time, while you're setting up this uh this tub, you can have us run an automated PII scan and we'll take a look at columns uh and their contents and suggest how you might want to mask them. Of course, once you're done, as you've seen before, you can override any results and set up your own uh masking policy. Now, one important point is if you've ever uh had to maintain these types of systems, uh you'll know that schemas tend to change and that can be a bit of a headache, right? You you have to constantly keep tabs with who's adding what column and what are they doing with it. So, to support day two, we have something called an automated automated masking policy. Uh we let you define categories of of columns and then decide uh even before uh you you have a chance to modify these configuration yourself, uh how the system should automatically anonymize that data. Right? So, there's a whole bunch of categories. You can add more. Uh we we allow you to modify these. Now, next, uh beyond just masking, you can also do subsetting. So, what you'll do is you log into here. Uh you'll tell us, "Okay, here's a bunch of tables I don't want you to copy or I do want you to copy um or you can tell us you know, I have multi-tenancy and my multi-tenancy is is column-based. So, I only want ten tenants one, two, and three. Uh or I want you to look into a JSON and and get data based on some JSON key. Uh similar similar to masking, you can just look at the policy and go into a specific table and just set your own subset policy and even set your own do our query set set the predicate tell us what to copy. Now again, everything you've seen here is also available in API. So, you don't have to do everything through the screen, you can just configure us uh remotely. So, now that we've seen the system, I want to show you how this works as a developer uh using agents um in in a real-world kind of setting. Let's start with the basics. As I've said, everything you've seen in the UI is available as a rest, as a CLI, and an MCP. So, I've gone ahead and I've authenticated and set up our our CLI. And so, if I want to clone, all I have to do is type base shift clone start. And what's happening is the same thing that happened before when I clicked the button. It's just sending a remote command telling the server to start up the clone and in a second, we have a clone. Now I can just copy the command line and connect. Now in some cases, uh you probably don't want to set up all the networking which which can be a bit of a headache. Um if you have you know, a server in a in a private VPC, uh you have to set up VPN, it could be a bit of a headache. Uh so, we provide a number of ways to connect. Uh we one of them is you can uh set up Tailscale and provide us with a key, and we'll use that key to set up two endpoints in your Tailscale network and provide the connection directly from the CLI through your to your server. Uh we can also run a similar thing in our cloud uh and and using other providers. Uh but the idea is we are all batteries included. So, all you have to do is our CLI and the CLI will work with whichever networking technology you prefer uh to provide a a local connection a local port that forwards all the way into the server. Now, just as I started a a clone, I can stop it. And the same operation can be done uh through an MCP. So, uh to show you what this looks like, I've created a project uh in Devin. Um and I've set up the MCP. And let's set that up real quick. You can take a look. So, what we have here is a a demo uh sample Django app. Uh we took the uh Acme HR database and um we set up a scenario where we want to run a a migration. Uh we have a prompt here, and we have our our Base Shift MCP set up. Uh this MCP is exactly the same CLI that you saw earlier. Uh it will set up it will run the same clone, and it'll provide the same connectivity. Uh it's just accessed by MCP. So, I'm going to start off this live uh prompt, and while it runs, I'll I'll visualize for you what the task is and what you're going to be seeing because this can take a couple of minutes. Right. So, while that runs and we'll skip right back to it, what's actually going on here? If you're familiar with the classic Acme HR schema, there's a handful of tables and one of them is the titles table. This is This is very common. You'll have a table with a a string or a varchar and at some point someone on the team will say, "Well, look, we can't have people just entering titles freehand. They have to be normalized." So, the task that we gave the AI is take that column and create a table out of it so it's normalized. But, while it runs this normalization, it's going to run into an error. And the idea is to show what kind of problem could be introduced when you run a migration on a production database um and you'd see an error in production but you wouldn't see it otherwise because the data in production acts a bit differently or has some edge case you wouldn't expect. In this case, there's a unique key or primary key on three columns, emp_no, title, and from_date. We intentionally added another column where it seems to be there was a typo or a change. Someone took the senior engineer title and first entered it abbreviated and then on that same day decided to add another row where it's fully spelled out. What's going to happen here is the AI is going to naively assume, well, I can take the title. I can just create a table of titles um and then when I canonize the the values, um it'll all be fine. But, what will happen is uh there will be a a key violation uh which would fail in production if it's not caught during development or or during testing. So, let's take a look at at how this happens. I think the AI should be just about done by now. Keep in mind, this is a live demo and it's still in the middle. It'll It'll take another minute or two. Well, I'll explain what what has happened so far. Uh but, using the MCP, the AI has decided uh to start up a clone. Uh and the clone, as you can see here, has started. You return a JSON. It's basically the same output we got earlier uh but in MCP uh form. And now the uh the agent can query the table, get some get some info, analyze the info, and it'll start uh modifying the model, creating a migration. And uh in a few seconds, what you'll see is that it tries to run the migration, and that migration's going to fail because it was a bit naive when it started. And now, to be clear, hold on just a sec. All right, yeah. It'll figure this out. Uh to be clear, this is a contrived example. Uh if you've ever worked with real databases, it you've you've seen this happen, right? You you write a migration, uh you think everything is fine, it passes your tests, you roll out to production, and then all hell breaks loose. Um It's happening. Oh, it'll it'll get there. Um the the idea of providing an up-to-date production uh almost equivalent a data set to the AI at will uh is uh it is is quite an unlock uh for for those working with complex data. Uh because if you want confidence in how the migration will work in the real world, you need to know that it has been attempted against uh a real-world copy. Uh you can see here indeed they're finally getting it to run. There was a there was a key violation. Right? And you can see the case. But now it will understand what happened, and it will it will go through the motion, uh it'll it'll stop the clone, it'll create a new clone, it'll it'll fix its migration, it'll run it again, and at some point it'll be done. Now, as I've said earlier in the in the webinar, um having it run on a copy of production is uh is necessary, but it is not sufficient to to unlock and to relieve that anxiety. Cuz as I've said before, it's easy uh to to just run a migration, but how do you get the confidence that something in production has not been affected? You want more, right? You want to know what did the AI do, and you want to know how will this impact production? So, when the clone uh is is done with, which it should be any moment now, uh what we'll see is that Base Shift has recorded all of the operations uh the the code has done against such a such a clone. And that allows us to get some understanding of what it's doing. Let's take a look at that. All right. So, as I said, uh we launched some clones, right? Uh you saw me manually launch a couple of clones. They're still up. I can shut those down. Uh but what we really care about is the clones that were launched uh just a few seconds ago. Uh and what you can see is we record everything that the the code does or the AI does against these clones, and you can observe uh the the migration directly. Right? So, we can see here's the migration, or at least here's the schema modification. We can see the data migration. Right? Here, it's it's updating uh uh the the the titles database. And so, we we can at least observe at will what's going on. But of course, we can't be expected to do this, right? We're not going to actually manually look for for the SQL. Uh what you want is uh to have some understanding on the merge request or pull request of what has happened uh in this modification. And so, here's kind of a a a mocked-up example of what this would look like uh in in a pull request. Uh this will be available uh within the next the next uh quarter. So, uh we first see that we can uh we can reference the clone or the instance of Postgres that was launched by the by the last run. We can also see the factual analysis of what has been done. So, a new table has been created and another existing table has been modified. What we really care about though is what does this mean for us and what does this mean for production? What we can see is in this case there was a new query which we'll call the application query which was modified and unfortunately it will no longer be using an index and it will fall back to a full scan which is quite square scary in a production environment. But far more far more scary is the migration query and this is something that's often overlooked. I've seen large companies have production outages because of this issue. The migration query just so happens to take a lock on that table. It just so happens that there's two very important queries running in production that create transactions on that table that would be locked out while that query runs. So, having something reflect back to us an analysis and tell us this is what might happen if you roll this out to production at least gives us the fighting chance. It It It gives us the opportunity to maybe plan around this migration, maybe modify the migration, but at least it lets us know what's about to happen in production before we roll out the AI's code. And so that that is the purpose and the the mean the meaning of of BayShift. Um We are currently in in a closed beta. You're you're welcome to sign up for the waitlist. We'll be opening up BayShift in the coming weeks. Um We are we are happy to demo and engage with you and with that I'll take a look at some of the questions Uh in the in the chat. Look. So, I'll start with Miss Anba. Um can we get some insights on how the snapshot was created and starting to the clones? Is it going to test the load on the source DB? Okay, so I'll start with the with the latter. Um it depends. Uh the answer is you can configure us to do a variety of things, and we can also uh grab the data from more than one source. So, if the data is if data is truly big like you know a few terabytes, typically our customers will point us at a read replica, and we'll get the data from there. Um also typically you won't want the entire database. You'll want just a fraction. So, obviously if we're doing copies, this will create more load. The question is how much? So, we're we we mitigate this in a number of ways. One of the ways we do this is we allow you to throttle how much we copy at a time and at what rate. So, you can control that process a pretty well. So, that I hope that answers that question. Um how the snapshot is created. So, the the snapshot is is an instance of a database like PostgreSQL and what we're doing behind the scenes is we're capturing files that the database has created. These are These are native database files, and we're just turning them into a folder and and squashing that into a Docker image. So, the clone is just kind of kind of like Git. It's like a fork of those files, and you can do a whole bunch of them. Um and I and I hope that that answers that question. So, D is nothing consistent. Yeah, um masking is consistent. Um, it it depends of course on which masking you do, but generally yes, it is it is um, we we do uh, use the uh, the data masked as a input for a random seed generator. So, uh, the same quote unquote random uh, generated output um, will you'll have a consistent output from that generator depending on the input. So, the same email will come out as as the same uh, fake email or or name will become, you know, uh, anonymized name. But, it's more sanitization or pseudonymization. It's not necessarily pure anonymization. Um, and so Marie you said that AI will suggest anonymization policies, this AI already did. Uh, we are not using AI to uh, suggest the anonymization policy right now. It's right now it's just regex. So, the way it works is uh, we have our what we we used to call agent, but that's got a new name now. So, it's just a proxy. Uh, the proxy which sits close to the production database uh, has a component which will sample uh, production. It'll take a look at the schema, the columns, and a sample of data to uh, to kind of guess uh, what what you want to do. Um, it hasn't been trained on any kind of data. It's uh, it's not LLM prompted at all. It's it's just logic. Not it's not very advanced. The problem there is because of uh, of the sensitivity of the data, uh, you have to be careful. So, we we definitely can't send it out. Maybe one day we'll have our own tiny model uh, any classifier internally and we have to make sure the data doesn't ever leave that that little container that runs a proxy. So, I hope that answer that answers Amri's question. And so, with with another few seconds, I'd like to give you a glimpse of how D-Shift works and what's what's our special sauce. What's different about D-Shift? So, for just half a second, I'm going to do a short technical deep dive and and give you a view of what we're doing. So, jumping back into the slides for a second, I'm I'm going to tell you what we do, but before I do, I'm just going to say what do we typically see people doing? So, typically in the market, one of two things will happen. Either you take a database and you create a special version of it cuz it's your database if you're, you know, a special custom database and add branching to it. Right? So, you might take Postgres and create a fork of Postgres and your fork of Postgres Postgres has a number of functionalities you've added. And one of them is that you can do branching or or what's known as copy on right. So, that's option number one. Option number two is you'll use the thumb file system or some driver or some underlying storage system to take a snapshot of a volume or of a of a folder and then behind the scenes kind of play some I call kind of tricks and and generate a new volume or new or new folder that behind the scenes is some sort of shadow copy or copy on right or branch of the storage. And so, we don't do either. So, we're kind of both and yet none at the same time. And so, to understand what we do, I'm going to to to call back to um, if of you have have learned compilation and writing code in C to how binaries work. So, Postgres, like many binaries, um, typically does not directly call the operating system. So, when the database says, "Give me a file. I want to I want to read some data." Um, it won't directly call Linux or Mac or Windows and say, "Here's my file. Get me the data." Instead, it loads a library provided by the operating system, which will translate that command into an actual operating system command, um, usually called a syscall. And so, that library is most typically called libC. So, uh, how does this work? Um, when you download Postgres or or MySQL or any other database or almost every program, um, it it has a a stub uh, that's waiting for uh, the OS to fill it in. When you start up the binary, it will run something called the dynamic loader, which will go and find uh, this this library, hook it up, and then and then the the operating system can serve this the requests of the binary. Uh, what we do is we interfere in this process, and we install our own form of libC, uh, which does something else. Uh, what we do is um, we install our own libC, uh, which allows us to do something like branching or something like mounting. Um, towards the binary, it appears as if you're doing uh, uh, regular IO. The OS has no idea this is happening. Um, from its point of view, this is pure user space, uh, but uh, we translate uh, the reads and writes into a format that does have copy-on-write. And we can do this for many database types and on multiple operating systems. So, uh, let's take a look at how this works. So, uh, starting up Postgres is pretty simple. You just do this uh configuration called LD_PRELOAD and Postgres will start up just like just like normal. Uh behind the scenes, what we're doing is we are capturing a command. Um we are uh figuring out where that IO request goes in the in the data structures and files on disk and we will reroute uh reads and writes um at a at a block level uh granularity um to to to produce the IO required. And by doing this, we can take a folder of of a snapshot data and create many folders creating what we call clone data and route reads and writes accordingly so that you can start up many Postgres binary instances sorry, Postgres um cluster instances from the same read-only snapshot, but each one has its own writable folder. So, that's that's how Base Shift works. Because we do this in in user space, we can do this in Docker images, we can we can have this running in standard, you know, container environments like ECS and EKS and their equivalents in in Google and in Azure. Uh so, that's a bit about how uh Base Shift works. Um if there's any questions about that, uh you're welcome to reach out. Um thank you so much for attending our webinar. Uh you are more than welcome to reach out to us on the on the wait list. You can also email me directly uh amir@baseshift.com and I'm happy to get back to you. So, with that, I think we'll end our webinar.