Closing the Loop: Modular, Testable Postgres for AI Agents - Dan Lynch

Thank you for uh letting me share uh what we're building at Constructive. Uh I'm Dan Lynch, founder of Constructive. I've been working oh the first time I touched Postgress was probably like 2005. Um started building tooling for Postgress in two well 2016 actually was when I really got into it. So um just to give everyone like a sense I focus a lot on tooling around the language itself um testing um and packaging um a lot in the TypeScript and JavaScript ecosystem. Um in my opinion I think that uh you know JavaScript became the lingua frana of the web and Postgress is the lingua frana of databases. So it's a great combination. Um and particularly when it comes to testing, I always felt that when I wanted to write a test. Um it made so much more sense, at least for me as an application developer, to be building the tests in the language of my application. Um and then to keep uh the the database kind of um something that I could spin up inside of a JavaScript environment very quickly um in an ephemeral way. Um and then each test case will actually spin up all the seed migrations or schema changes. Um and then roll them back each test case, right? So I can thrash the database. I can add users. I can do all sorts of stuff. I can even test role level security. Um so today my goal is to show you guys how to how to set this kind of stuff up. Um it relies on PGPM which is a Postgress package manager. Um and effectively what PGPM does is it's a schema change uh migration framework but it comes with also workspaces which give you modules. Um if you've ever coded in uh let's say yarn or learn or pnpm workspaces um you should be very familiar. If not I'll I'll show you what those are. Um, but yeah, the first thing the first thing I would do is I guess I'll show you two things just in case you want to track all this stuff later. Um, on constructive.io, we do have a learn page. Um, and if you just go to this, um, quick start and we have prerequisites. I'll just kind of discuss this really briefly. Um, but it requires node. Um, it says node 20, but I would recommend 22 or 24. Um we do use PNPM which is one of the best um package manager tools on top of npm and you know every person does this differently especially in the Postgress world. Um we are going to use Docker to run Postgress. If you already have Postgress that is fine you don't need to do anything. Um this is just like a nice kind of replicable way for people to install Docker. Um and we have uh just the Postgress client tools we need to install. So if if you already have all this stuff, great. If not, uh the first thing you want to do is just install PNPM using like an npm install- G, which will globally install it. For most JavaScript devs, you're very familiar with this type of a command. Um so yeah, so you'll actually install PNPM first. That's right. Sorry. Um I I recommend using Docker for desktop Docker desktop just to kind of uh do things quickly. Um and then installing PGPM itself and you can verify that. So um let me just maybe install one of the latest versions here too. So I will move my terminal up here. So, I'll just install the latest freshest version of PGPM. And then while we're waiting for that, I do want to talk about one thing. If you do the Docker install, um I tend to use psql without postgress being installed because I don't like homebrew and everyone installing all these different services on my computer. Um I just want the client tools, right? Because I just want Docker to open up a port. So I I tend to I tend to do um this installation where it just installs the libraries. It does not install all of Postgress and then I can delegate the Postgress installation to docker and and uh there there's a good reason for that. Um, cool. And so, you know, maybe I'm rushing through this, but I am assuming you guys probably do have node and postgress, but if not, again, just go to the learning portal in constructive.io. You'll see the prerequisites. And also, we do have this learn tab on pgpm.io, which just links directly to our learning page here. What we're going to do is we're going to spin up one of these modular workspaces. Um, and I'm going to actually just walk through everything uh with you guys. So, the PGPM in it workspace and I'm going to go it's going to give it a name here and then it'll ask you for your name and your email and it'll it'll find stuff if you have like a nice uh git config there. [snorts] Um, my username for GitHub and I'll choose a license. And so what it's doing is now it's cloned the repo. It's made a a kind of boilerplate a starter kit. And now I'm going to CD into my workspace. I will just do PNPMI. While that's running, I'm going to open up the codebase so we can just analyze it together. So out of the box when we do PGPM in it workspace, we get all these uh PNPM workspace files. a PGPM JSON um an agents with a pre-installed skill for using PGPM which is really great and it just kind of sets you up with everything you need. Um and so since we are in an agentic world um I I'm tempted to start using the agent right away. Uh but first let me just show you guys how to make a module from scratch. Then what we'll do is we'll have the agent maybe modify the module and make a new a new package. Uh modules and packages I kind of use interchangeably. Um so let's go ahead and do that. So we'll do pgpm and it I won't put anything on the end of that one. So this is a module name and let's say I'll call it pets for example. So it's going to be public um which means I could publish it. That's more of an npm thing. Uh, okay, cool. So now I have this new packages pets folder. Uh, let me go back here to the code. And now you'll see we have packages pets. We have deploy, revert, and verify. If you're familiar with sketch, which was written by David Wheeler, um, a lot of the file format has been uh, pretty much inspired completely by Sketch. um is did the only difference is it's TypeScript uh instead of Pearl. Um but then we got our test folder here. And so let's see. I'm going to come back to our prerequisites and just make sure we're we've gone through everything here so I don't lose anybody if people are following along. So we've installed Docker, we've installed PGPM, we actually initialized even our own uh workspace. I just want to make sure you guys if you're if you are using PGPM and you do not have a Postgress up and running yet, let's just go through that real quick. So I'm going to do PGPM docker start. So that's essentially starting a Postgress in Docker. Yours will take longer than mine if you've not run that before. So, I'll kind of wait a moment. I'll explain a couple things. Um, if you use our Docker image, PGPMM will spit out a default export environment to have all that set up. I usually just run this email. And so now I should be able to like, you know, run psql and I'm inside of a Postgress 18 instance on my computer. Um, everything I build I try to make it so it's runnable locally. uh effectively. So let me just exit out of this. Um so if once you've got that going, you should have your environment u and again if you do have your own Postgress set up just set up your environment variables to point to your Postgress. So if it's a different port or host, username, password, whatever, just you know export those variables and everything should be good to go. Um, and uh, for running the tests, there's a one-time command you'll want to do. Um, we do, for this demo, I'll be using anonymous, authenticated, and administrator roles. And this will bootstrap those roles here. And we can get into like other Postgress frameworks and their users and how to manage that later because we do have a way to do Subase Insight um all the different uh Postgress uh ecosystems. Um okay cool. So let's go back to our code here. So basically we've got now this package. Um I'm going to add a change. So, I'm going to CD into the package pets and I'm going to do PGPM add and I'll call it let's say um schema, right? And and then I'll call it um you know pets public, let's call it. And so what that's going to do is it's going to create a deploy revert and verify. So, if I open this up now, I can start making my table here. Um, here's where it might be nice to have an agent pop in. So, I will just say I trust this folder. Hey, can you update the pets public schema? Uh, deploy, revert, and verify and just add a schema for the pets. um table and let's also add some owners if you can, but the owner should probably be in another change. Um check out the skill just so you know how to use PGPM. I probably didn't have to say that with the PGPM, but because the skill is in the codebase, so what's happening now is um I mean I guess I could have written the schema myself. I probably should, but it's good to have the agents coding while I can talk a little bit about what's happening. So, we generated these uh deploy, verify, and revert. And then what happens is there's this pgpm.plan file which actually has a reference to this uh schema and pets public. And what happens is if you have a ton of schema changes over time, you will end up with a linear list here. However, what's really nice is inside of your deploy folder, you have a very human readable content addressable kind of human sensible way of organizing your code even though when the system migrates it in an item potent way um in order. So, I always find that to be really nice. And as you can see, the agent now already picked up how to uh use the system and has now added a owner's table and a pets table. And as you can tell here, there's also these um dependencies. So this owner's table is depending on the pets table and uh the the pets is depending on the owner's table and also the um pets public schema which also probably means that we can take a look at these. So we've got um interesting I think the agent forgot to write the schema. That's interesting. That's funny. Uh maybe he's writing it now, but let's see. So he's got our table and some comments on the columns. We've got our owners, and I believe you can see this requires owners here. So this is one of my favorite features, which is that you have these sort of require statements at the top of the file. It kind of reminds me of like when I'm using Python or JavaScript and I'm importing a module or a file um into another file. Um this is actually super useful because usually SQL is just like a bunch of linear migration files and I always found it so nice and neat to be able to now organize SQL in a very structured way. Um so let me let me just do one thing here. Um, let him know. Hey, the schema did not seem to be created. Can you make sure that schema is there? Um, the pet schema. That's funny. That is an agent problem. That was not a me problem. I'll tell you that. That was pretty silly. Um, I guess it happens to everybody every once in a while with agents. All right. All right. So, my next phase here is then to we're going to set up a test and we will um I will show you guys why this is really awesome because what's going to happen is we are going to be able to quickly start testing this schema. And so, let me analyze just a little bit about this PGSQL test which is our testing framework that comes baked into all the workspaces. So, you'll see this. Let me just zoom in here for you guys. And pardon these um squiggies. I wish I could just get rid of that for right now. But anyhow, um PGDB and tearown come from this git connections. And uh what that is is PG is a super user connection to your Postgress database. You'll be able to do anything you want with that. Then there's the DB connection which will add here to the role level security. So, this one uh is what you'll probably want to use almost every single time if you find yourself using PG. Just be careful because you might be taking some shortcuts. Um so, generally you want to use DB. And so, what happens here is that before every single test, what's happening is it is creating a new database. This database happens to be the result of running all of the deploy migrations across your entire package. And before each it will then set up the transactions and commit calls and begin calls so that before and after each test case which is here for example it will roll your database back to your seed state. So that's honestly I think what one of the key topics is for today which is like if you want to write very fast tests that agents understand uh quickly um it's really about testing. It's about strong signals for agents so agents can know what they did right and know what they did wrong. Um and oh maybe I just didn't maybe because I had opened that before. Oh, there we go. We have the schema. Perfect. Okay, great. Um, so now what I'm going to do is I'm going to try and just run this test myself. I don't want to get the agent involved right now because I want to show you guys um how to run it yourselves. So, let's just see if we run a P. Okay, look at that. It passed. I'm going to put the PNP PM. So, so just to if you're following along, what you're going to want to do is you're going to want to CD into the packages pets and you just want to run PNVM test. Now, what that's doing is you can even see here in the logs, it's, you know, doing the migration, uh, deploying everything and, uh, it's then running some, uh, connections and everything. What I like to do is if I'm really doing a lot of innovation, I'll do test watch and and I think you'll see here why the testing is really important. So, what I'm going to do is I'm going to go and sorry, I'm going to just shrink this a bit so it's easier to see. So, let's say I go into I don't know um and I rename this thing and I hit save. Look how fast I get the feedback that like this failed, right? Um, that's pretty quick, right? So, let me let me undo that. Um, and now I save it. So, we're talking milliseconds. This is Okay, so this is 542 milliseconds here. Um, I just want to pause on this because I think like that's really the innovation which is that like I'm editing a piece of code and I know now within half a second if my code change was successful or not. If you imagine I mean what I used to do I don't know what you guys are do but I used to take this kind of code I would run it in psql I would run it in a guey I would then have to have a UI or something I would try to like either do queries or I would you know click on some buttons and before you know it I'm spending I don't know 20 seconds testing my code and so instead of spending 20 seconds testing my code. All of a sudden, now I'm spending half a second. And so ultimately, I'm I'm I'm now uh more of an engineer than before. Before I was kind of focused on QA because I would be editing code for 2 seconds, testing it for 20 seconds, and and so I think this is actually kind of great. So, all right. So, so this is working. Um, let me make sure that everyone knows how to get set up with the GitHub workflow. So, it comes with a workflow. So, now we want the tests to run in GitHub actions. And you'll see there's this module here, your module one. We will put um I think we just called it pets, but let's just double check. So if we close all of these and we just click on the pets control file. In fact the name is pets because whatever the name is control happens to be the name of the module. Just so everyone knows these are both an npm package and a postgress extension. Um and it's also modular which I will showcase soon meaning that you can actually have multiple packages. they can depend on each other. You can publish them to npm. Um, I think that's a bit superfluous right now. We should focus more right now, I think, on getting the test to run on GitHub. So, we generate the workflow file for you. Check out this matrix. Make sure the package has the package that you've created. And then what I'm going to do actually I believe I have uh here I'm going to create a new repository. One moment. All right. In fact I'll put this in constructive. All right. Cool. So I made a new GitHub repo agents demo testing here. And I'm going to just uh set this origin. So um getting it dot and then I'm going to just add everything. And this will be the first commit. And what's great about the PGPM workspaces is, you know, for the most part, I mean, we might run into a little bit of a snag here and we'll figure it out. That's why I'm really glad we're all working together. But um I should have pushed that up. Oh, I don't know why it was private. Let me uh let me make sure that's public actually. Sorry. I'll fix that right now. Uh that part's fun. Give me a moment. It's always fun doing your password on a webinar, right? All right, here we go. Let me just uh I just want it to be public so you guys can see everything. Okay, cool. So, that's public. We can refresh this public repo. Um it just gives you a basic kind of quick start how to get your repo set up, how to test everything. You can even run audits. Uh, the more important thing is, oh, look, our test broke, which which is honestly fine. Um, because what I'm going to do now is figure out what's going on here. Let's see. Pull. Oh, Mo. Oh, no. This is This is Mo. This is why this is why you don't change your um th this is unexpected because Mo just removed their uh Docker images the other day. This is not related to us. This is a little bit upsetting, but I will have this fixed immediately. So, here's what I'm going to do. Um, change Mino to Rust FS. Sorry, guys. Um, what's happening is the service container is not working. Okay, cool. Well, anyway, let's take a look at another action that ran while the agent is is fixing that. Uh, because I think there was more than one test, right? There was uh let's see here it was um oh well I just run the socket security one. Okay, we'll we'll hold off on this. So once so so once we get that so maybe we can start working on some more stuff. So he's he's working to remove video. I will actually fix that from the uh boiler plate and I apologize that um that's even affecting us right now. And uh we'll we'll get this pushed up very quickly. The demo gods always like to have fun with me, I'll tell you. Um so hopefully we can get that pushed up quickly. Um cool. So one other thing it might be worth mentioning is uh if you want to just kind of check out where these things live, you can find pgsql test here. Um if you guys are writing a lot of subabase, we have a subabase test here. Let me just close this little thing here. Um, and so Superbase test for example is built on top of PGSQL test. However, it has all the Superbase specifics baked into it and you get the exact same syntax here. So in your before all um you'll you'll get your DB and your tear down um and everything is perfectly ready for uh Subbase. Um, what's really cool about this stuff is there's a lot of cool things you can do for seeding. So, you can just use the DB itself and literally seed stuff that way. Uh, you can seed things using the PGPM deploy verify reefer files like I was sharing earlier. One of the top other cool features is you can actually um simulate role level security which is useful for constructive subay ins I mean all of them PG light um so you can set your role and then any of your claims like a user ID or or depending on your your application what you've got there um and this way you can actually test out the security of your application Right. So, for if we're kind of zooming out a bit now and we're thinking about like the aentic loop or even the development loop, like honestly, in my opinion, a lot of this stuff was uh I wonder if I have some if I have a nice graphic for this I can share with you guys because um I think it might be nice to see. Let me Sorry, give me one moment here. I'm going to try and pull up a graphic. Uh, [groaning] I have this this might be for a different Okay. Oh, no. Is it okay? Pardon the um, [gasps] pardon the name. We I I had used I had another name for a product long time ago. It was called Starship, but it's the same exact thing. So essentially you write code, hit save, you go to the browser, you refresh, you're clicking and interacting on stuff, right? And then you finally see the result. Once you see the result, you can make an analysis and you can then like go write code again. The truth is that navigating to a browser, refreshing and clicking around things and interacting is just so bad for your hands, for your time, uh time to market. you can get like literally like carpal tunnel. Um, and even with agents, I mean, I guess the new problem would be just like what are you gonna do? Burn tokens on like your agent using a browser or doing things that like kind of manually writing testing by I don't know like you know writing queries against SQL in a very nondeterministic way. Um, anyway, so we aim to get rid of these three yellow boxes. So all you really should do is write code, hit save, and you see the result, right? Just like we saw previously here and here when you know we we leave the test on a um on a watcher, right? And then if we if we hit save when we're like editing the code for example, you know, it's running right away. Okay, so we're getting that instantaneous feedback. That is effectively what this feedback loop is. And this is like productivity and happiness. This is like the dopamine loop. And the argument here is which is funny because I I've made this slide years ago for a different platform, but I've really incorporated this into everything I build, which is why it's still relevant. And the truth is your agents are also going to be just as productive and happy as you would be if you were writing the code yourself. So this is still applicable whether you are human or an agent. Um and this dopamine loop really is what brings back the joy of programming. So um let's let's let's get to it now. Let's just see if he fixed this thing. And I really hope that he did. So we're using Rust FS instead of Mo. And I will have to make a note to up upstream that because that is something I don't want anyone else to have to deal with unfortunately. Uh so kind of rolling with the punches here. So let's see what happens. So now when I push code he's already running the test which is great. So while he's doing that I'll also showcase a couple other ones. So on npm we should also have PG light test. So PG Lite is uh now a part of data bricks um and neon uh but it used it was originated from the electric SQL team. So here's another one that we have. And again, you know, the beauty of all of our frameworks is we just aim to make everything identical in terms of simplicity and uh give you the ability to do these rollbacks and write all of your um tests. And so there's a little bit more configuration options here um for for PGE, but uh for the most part, it's actually all pretty much uh simple. And let's see um there are other testing frameworks too. There's our there's our seating framework which is pretty useful and you can use it in the tests. Um and it comes baked in so you can load CSVs, JSON. Um you can just do pure SQL files. Um and again you know the PGPM which is like obviously you know kind of baked in. Um, and I think a good example is say you want to check out Superbase for example. Um, you can go and check out like a hello world. We've got a deploy here with an RLS demo. And we've got some tests here. Here's a hello world test. We've got users. We've got all the, you know, basic setup which is in every other PGSQL test. And here's what it looks like when you set up your um JWT claim. So here we're simulating that we're logged in as user one. And now we can test out basic CRUD operations on these pets, right? So and we can we can actually simulate some of the stuff ourselves if if our if our timing is okay. But just wanted to make sure you guys knew where you could find examples. Um, so we got the Subbase test suite. We should also have a PG light test suite, believe. Yep, this is a full PG light setup. And again, all these ones should be passing, meaning that they're running all of the tests. Same with the Superbase one. So this is literally spinning up a Subabase database inside of GitHub actions and running it. And this is spinning up a PGE database there. And then the one we're working on now is just a regular Postgress uh database powered by Docker. Um and that failed. So that's always fun. But again, um now it's now it's some kind of lock file thing. And yes, I am just going to paste that to my agent because I'm being funny. Um, so once we have that lock file set up, it's probably hopefully going to run. Um, but yeah, so I mean on a high level, the flow really is about just getting your code running in your GitHub actions. And uh that way when you're writing code, you'll know like, hey, did you break something like this? Um, and actually the way you should set it up is that your main brand should never ever have a red X. You should always do feature branches and you're collaborating with your team members. You're collaborating with your agents and uh you're only merging in the poll requests if they are green and passing. So, you know, just back to that agent loop, it's really about can you write modular code? Can you test that code? Are you getting the results of those tests quickly when you're running your code locally? Can your agent run that stuff locally? And then when they push the code to your GitHub, is everybody then that's connected to that repo also getting the strong signal whether or not your code is passing or failing? And then if it's passing, then you can merge it in. So yeah, to kind of uh bring things home, there would be one how I'm sorry, do much time we have. Do we have like time for one more piece or are we getting to a point now where I should start to wrap it up? I Okay, cool. I will do one more thing because I think it's worth I think it's worth testing and I do apologize for the quirk. You know, just so everyone knows, Mino apparently like stopped open sourcing everything and so they removed their Docker. So that was just very not nice. Thank you Mino for being not open source friendly um during my demo. Um because normally everything is passing just fine. Uh but so so that's what happened there. Um, and hopefully I can get this now pushed up. Um, and then what I'm going to do, whether or not we can get this test to pass. Um, and I will get it passing and I will also update the boiler plates so that way you're not stuck in the situation here. But I want to do a a second module. So here's what I'm going to do. Um, can you please make a new package, a new PNP, Oops, sorry, not PNDM. I even get confused. PGPM package. Um, be creative, but it should be a new package that depends on the pets package because I want to demonstrate the modularity and one package depending on another package. And please write a test for it and so we can run the test in that new package. All right, cool. So, what I'm doing now is the agent is going to write a new PGPM package. So, at some point, we should see that he's going to be creating a new package here. So far, we only have pets. I actually don't even know what he's going to create. I'm kind of a excited to see. Um, it's like the randomness combined with determinism. You know, the determinism comes from the framework and the systems and the guide railro the guardrails we're putting in this sort of harness. Then the randomness is in the agent. Okay, he made a vet. Look at that. All right, great. So, we got a vet package and the vet package uh has this, you know, basic test put in there. Okay. Well, he's already got a vet public schema he's building. He's got some functions for booking appointments uh and tables. Okay. Wow, that's a lot of stuff. But the the point here is actually that like this vet package is going to depend on the pets package. And honestly, like I don't know how you guys are organizing your SQL files, but like for me, this was a lifesaver. I mean, literally being able to have modularity like I would expect in, you know, TypeScript or Python, but now have it inside of my Postgress was like was a game changer. Um, so it looks like he's still kind of uh putting stuff together here. I'm just going to um mention one thing. One thing I noticed that the agent's not doing and I hope he does it by the end of it. And if not, I will have to figure Oh no, he is requiring. Okay, look at this. He's requiring pets. Okay, by the way, this syntax is not invented by us. This is a PostgrSQL extension syntax. So what's happening is this control file called vet is stating that the vet extension depends on the pets extension. Now since these are actually deployed as like modules I tend to actually call them modules. Um they can be converted and packaged up as Postgress extensions as well. So they are dual modules as well as extensions. The difference is modules typically require some sort of a super user privileges like some kind of like highle DevOps you know permission or AWS RDS probably would not let you do that right so uh that's why these modules can be deployed without them actually being installed as extensions however for just like setting up the workspaces and being in line with not inventing new DSLs and piggybacking off of the syntax that Postgress provided for a module saying which thing it depends on. I'm just using the control files. So, uh, the control file is always a place you can kind of figure out like where things are. And each of these packages technically are in fact, um, a a package. And and and I guess one I I could quickly just do a real fast demo of that. Um, let me just I think you do pgpm package. So if you write the command pgpm package inside of a package, it will write the SQL folder which this is the extend. This is what's needed for it to become an extension. What it does is I if you guys are familiar with my parser library, um I parse all the SQL inside of all of these based off of the order that they're supposed to deploy. And then we generate a nicely packaged uh extension of your entire code, right? And what's cool about that is if you're using, you know, if this were to be an extension as well, because it depends on pets, it knows to install the pets extension. Um, but also, let me just go into the vet package real quick and do a uh PMBBM test. And what's cool is like you'll notice like look at that. Um this is interesting because what it did was it actually migrated the pets package. Look at this. It deployed the local module pets before it deployed the local module vet. But what's kind of cool is like my vet package is pretty clean because my vet package really is only concerned about the veteran or the veterary clinic and the functions for the veterary clinic. All the code for pets can live in the pets folder. But it is nicely neatly packaged not only in a Postgress native way with the control files and uh being able to build things and test them but also you can publish these to npm and then if they if you want to have some open source Postgress utilities that you use quite a bit um you just do a PNPM learn publish um which which we we could you know maybe get into another in another webinar. Um, so what I'll do real quick is I will just uh add all this. Let's see. Let me add bets and I will push this. Um, and hopefully let's see. So in the last we do have some and now now if you notice look there's a vets test and also a pets test. So we have two and that way for each mo each time you add a module you're going to have a test for each module. So effectively over time you'll have many different modules um you'll have many different tests. Um they should they should all be running um and you know without without surprises like I had today. They usually will they usually should just pass. Let me just kind of check if there was something I can fix really quickly here. So, I would love to leave you guys with a um with a passing with a passing setup. But yeah, um maybe might be a good time for some questions. Um you know, just to summarize, we've got the work the workspaces. Um, and you can learn about those in PGPM. And these are basically for creating those. It's actually a learner PNPM workspace which is from the Node.js community, but then I've kind of layered native Postgress extensions on top of it to create Postgress modules. Uh, and then uh to set all this up, we have our learning portal here. Uh, constructive.io/arn io/learn prerequisites would be a good place to to get set up. Um and then honestly my favorite which is the testing framework which is PGSQL test um that is natively baked into all the workspaces and what it does if to to sum it up is just it will take your migrations and your seed and then all your test was automatically have all that seated SQL so you can just start writing your tests um and then we've we support PG light as well as a few others and if [clears throat] you have new you need, let me know. We're happy to build it. Um, and you know, typically what'll happen is you'll have a series of tests and they will all run. Uh, and what's great about this is now you're creating that strong signal, that strong feedback loop, so you and your agents know when your code works, when it's breaking, um, and you're constantly testing it, and you're spending more of your time writing code, uh, than doing QA and testing. So um I guess I'll open it up for some questions at a high level. What are we solving here? Currently a lot of existing u migration studios. Why should we change? Um look like I I haven't seen um anything that is a nom uh Postgress migration framework. uh a lot of the migration frameworks out there that are specifically in JavaScript or Python, they like wrap your uh they they wrap code and they they um effectively become your your SQL. So you're not really writing SQL. Um and so for example, if you're using like Drizzle or uh some of these other ones, um it kind of gets crusty in my opinion because then you're learning two things. uh you're learning the OM and then you're learning the underlying language which in this case happens to be Postgress. Um what's cool about PGPM which we borrowed from sketch which was David Wheeler's uh original work in Pearl. Um is that we we do not use an OM right? Uh so the the great thing about this this solution is that as you could tell every file was just a native SQL file and in my opinion that's actually really important because I prefer not to make abstractions. I love to take like what are the most popular open source things and if they're good I want to build on top of them. I want to generate those you know like generate TypeScript or generate Postgress. Um, but I don't want to force people into a new DSL or a new abstraction. So I think when you're talking about a lot of existing migration solutions, I would say probably the majority of them I would throw out right away because they are wrappers. You have to upgrade with them and then if you need to migrate your code, you're like editing like JavaScript code. And um, I think to edit your actual schema, you should be editing SQL to test it and use it. It's fine if you want to use uh JavaScript and we do have transpilers and code generation tools that will read your Postgress and generate APIs and also generate React hooks and generate SDKs and generate all your types. Um but those are derived from the source of origin being your SQL code. Um so that's a philosophical thing. If that doesn't resonate u I'd say you know stick to whatever uh tools you're using. Um but you know in general like you know we wrote the drizzle OM test framework they didn't have one right so I don't know how people are even you know one of the most popular OMS in the world drizzle um people are still not writing tests so you know what I would say is we are the only one that to my knowledge that takes into account the developer experience um the nativeness of Postgress itself with the usability and front-end developer for empathy of of um JavaScript and having modularity um with the full cycle and thinking about GitHub actions and and CI/CD I think u we're trying to create like standards you know so so that way it's like hey if you want to build a Postgress project like use this um you'll get tons of stuff out of the box and we're going to keep innovating on that um I I think like the ecosystem is so kind of sparse and also sporadic that like there really is no tried and true way to build a Postgress app. Um I think that's actually one one of the problems with our space. I think that Postgress was you know the ecosystem is primarily built around database administration but it's not built around database applications and we're trying to change that. So um we've got a lot more stuff than this too. So we're we're actually going to be releasing a lot of cool new stuff in the next couple weeks. Um but I hope I hope that um answers the answers your question. that you know there is also the publishing to npm and re and be being able to consume packages through npm uh which is a nice feature um maybe I should just do a real mini super fast demo there but um because it sounds like you didn't see that and I feel like I would be leaving you guys selling you guys short. Um, but let's say we do a uh let me just kill this here. Oh, shoot. Okay. No, I killed the wrong terminal. Um, so let's say I'm inside of one of my packages here. Uh, and I can just do pgpm install and I can do pgpm. We have a thing called we have a faker library for example. And so there we go. Um and and then so if I want to deploy um let me do PGPM um to get this. I'm just going to set up my envir. Whoops. All right. And so I'll do uh you know create DB my DB. Probably should have done this too. Um deploy. And I will do D- database my DB. And I'm going to proceed. Yes. And now look at this. All these modules is asking me which one do you want to deploy? Do I want to deploy my pets? Do I deploy this Faker library? What are these doing here? Oh, these are here because Faker depended on this types one and I think they both depended on verify. So that's like npm, right? Like that's not something that you just typically get out of the box with any of these migration frameworks, right? This is only because PGPM offers that package manager with modularity. And again, similar to the philosophy that I talked about earlier where like I don't Whoops. I don't want to invent anything new. I want to piggyback off of existing popular technology. This just uses npm, right? So I don't have to invent anything new. Now, if I were to run, you know, pets, it's going to deploy, as you can tell, separated by blue, then we have green. Um, this is the verify package. This is the types package. Here's the faker package. Here's the pet package. Right now, let's say I run this again and I run the vet. Notice it skips all these ones because it knows it already installed it. And um now it's deployed this one, right? And so like if I were to do, you know, psql my db and I can do select, you know, I think it's like faker. this or something like this just got installed from that PGPM install command which actually came from npm. So like if you go to npm there should be a pgpm faker library right. So this literally which is consumable from a PGPM install gives you all these like cool ways of faking data and the code itself actually has this deploy revert verify with actual um SQL in it. So um the modularity in my mind comes from being able to publish modules, separate them, have them be tested in an isolated way um and then all the tests run you know here in this case we have I mean how many different test there's probably like 30 different tests across 30 different modules. Um, so hopefully that made the demo a little bit more clear about modules. Um, and and really what that is is that like you've got these packages. Each of these folders happens to be a module. These can all be publishable to npm npm. They also can be installed as a Postgress extension because they have these control files. And so the modularity is just that they're they're separated. They're isolated, but they're interdependent in the sense that they can depend on each other. So, cool. Um, but that was a great question. [clears throat] Uh, Llank Leblanc Leblanc. Uh, and I feel like I've I might have seen you on Twitter before or your name is just familiar. Um, cool. If there's any other questions, happy to go over them. Otherwise, um yeah, I hope you guys can use this and [clears throat] great. Um well, you know, that was really fun. I'll tell you, I um I I I feel like if you guys have any ideas, please send them my way on Twitter. Uh my my Twitter account is just my name. It's just Dan Lynch. Um love feedback. If you guys have any other uh testing frameworks that you'd like or any Postgress frameworks you'd like to see us build for, happy to do that. So we have Drizzle OM test, we have Suba Base test, we have PG light test, um just regular PGSQL test um and yeah, check out pgpm.io O and uh happy to make any bug fixes, improvements, suggestions you guys