Drizzle: The TypeScript SQL ORM

Welcome to Syntax. Today, we've got, 2 of the devs on from Drizzle. We're really excited about this both because big fan of Drizzle myself, Drizzle is a TypeScript ORM for, several databases. We'll talk all about that in just a sec, but, also, look at these cool T shirts.

We are launching this new thing on on syntax, which is, sort of like collaborations with open source projects.

And part of it is, like, we're trying to figure out, like like, how do we do cool stuff but also, like, support open source projects. So this Drizzle tee, shout out to Drizzle because they were, like, one of the first to sign on. They're like, yeah. We'll we'll do that with you. $10 of this shirt will go straight to the Drizzle project and continue funding the work of it. So you got that. We got syntax on the back. You think that's it? You're not. Look at this.

There we go. There's a

really, really cool T shirt. You wanna go to syntax.fmforward/shop or click the show notes or anything like that, and and snap up a t shirt before they're all gone. So, we got Andrew and Alex. Welcome, guys. Thanks so much for coming on. Thank you. Thank you for hosting us. Yeah. You're you're welcome.

So let's start real quick with pnpm explanation of what Drizzle is for anybody who is relatively new or hasn't heard of it before.

Yeah. So, I can start. My name is Andrew, and I'm working on Drizzle for quite some time. And Drizzle is like our years of development and helping our projects to to work with databases.

And, like, initially, we made Drizzle just to help us as developers and help other developers in our company where we were working on, just to make databases easy in the TypeScript, in the way how we see it, how it we think it should be. Yeah.

Awesome.

And how long have you been working on on, Drizzle? Almost 4 years, I guess. Almost 4 years. Oh, wow. Three and a half years. Yeah. Yep. Oh, that's that's wild. And it it seems like probably in the last, what, like, year, year and a half, it's it's starting to really take off. Like, I've done a couple projects with it. It feels really good. You know? Like, the TypeScript inference is amazing. We will talk about that. But, it's it's amazing to think, like, you've been just chipping away at it for 4 years, and it's it's such a awesome, ORM for working with databases.

Yeah. It's in public for Yarn, maybe year and a half. Thanks to docs from SST helped us to just grow. So for us making this first video about us.

And previously, like, for year, it we were writing it in Java, actually, not in JavaScript or TypeScript. Really? And then we just wrote it to JavaScript and actually because we needed it there as well. So, like, the first first thing was it was project in Java, and there were no good programs.

And we did it for Java.

And then we wrote in the Java style, a lot of classes, open, open, that stuff was there. And then and then we were routed to the new version of just objects and functions.

What kind of stuff were you working on that it Wes was in Java?

We've been doing outsource.

Okay.

So you were just doing taking on projects for for companies? So do you have, like, a company then? Yeah. We've been doing TypeScript,

Python, Golang, and, Java projects.

Java and Kotlin projects.

So we've been through Hibernate.

We've been through Mybattis and other stuff. And then we sort of had an opportunity to write a an as we envision it in the in the Java land. And then when we fully pivoted to the TypeScript outsource, like, 95% of the TypeScript, then Wes sort of realized that we went through TypeScript. We went through SQLize, Prisma, etcetera.

And, we were lacking the the developer experience we had with our ORM, so we transitioned.

Yeah. So, I mean, that that kind of, gets into the the why make an ORM thing. I know people always say either use an ORM or you end up building 1 yourself. So you guys actually took on the the task of building 1 yourself.

Going from 0 to 100, how was that that process, and and what informed the design decisions you guys had?

We sort of listed all the problems we had.

Those problems, they sounded silly to us.

And we sort of listed all of those, and we made them manifest of how we see, conceptually the ORM. It should not be it should be everywhere opt in. It should be type safe. It should not have generation steps.

It has to be it has to have a discoverable IP API. It has to have SQL like, API, etcetera, etcetera. So we list everything down. And to this day, we follow all of all of those, especially when we go through conversations about the API decisions.

We follow all those rules except 1.

And that 1 in particular was TypeScript, 100% type safety.

Because in the Node run, a 100% type safety turned out to be a bad thing.

It has more downsides than benefits.

Oh, can you talk a little bit more about about that? Like, what does that mean? What what JS what does a 100% type safety mean when you're building a an ORM, and why is that bad?

Yeah.

So, we had an iteration where we're like, okay. We're gonna make you write, everything type safe. If you change anything, it should influence the joint column or the filter you Bos to the where statement.

We should infer everything and make you write the exact thing that will work on the database.

And the guys from have been blaming us that we don't have, like, a 100% type Sanity, that you can pass the wrong column to the Wes statement or the join or you can join the wrong column, etcetera, and it will break.

And, we know that, and it's a deliberate stating this publicly in the Twitter, is that when you make an API that way of the query builder, you have to first pivot from the SQL likeness because you now have to list all the things prior, to the actual query.

And then you have to reorder everything. And then when you write the actual queries, you will have, like, a massive TypeScript errors.

And, nobody except highly experienced, developers with TypeScript were able to parse those. We realize this is gonna be a huge deal breaker for us.

That that makes a lot of sense. Because, we often talk about the TypeScript development on the show as there's, like, a couple levels of it. Right? Like, there's there's 1 level, which is most people, which is just simply using it. You know? You write a little bit of TypeScript, but simply just the the auto complete pops down. And you you hit enter, and and it all works. And sometimes there's errors. And then there's, like, another level of it, which is, I think, where you guys are on. I'm curious who does a lot of that work is, like, actually writing the, like, heavy lifting.

TypeScript is its own language, and being able to infer the fields from all of the queries and and the filters is is extremely complex. So who who is it? It is is it all of you guys that are working on the the TypeScript stuff, or is there someone that's just, like, a sick person that loves that stuff?

Nobody loves it.

Oh, yeah.

Yeah. So, originally, Dan was the 1st, person on the team who rewrote the class based approach to the in type inference, which, which made a huge leap to our library.

Mhmm. And then they continue to work with Andrew. So Andrew and Dan are both core contributors to the core of ORM.

I was originally in charge of Drizzle Kit. I sort of getting into this TypeScript, type inference stuff, or myself, just to, like, make DrizzleKit internals more robust and sustainable to iterations and breaking changes so that the TypeScript will tell us that you added additional something. Now you have to put everything in all these places.

Yeah. Mhmm. But my TypeScript level originally came from the back end development.

And, on the back end development, there is a a certain line.

And, if you surpass that line and you try to imply your TypeScript types knowledge, you make it worse, especially for newcomers.

So I I strongly against that. I'm I'm all about making it as simple as possible.

Yeah. I think that it kinda shines throughout Drizzle in general. It feels like it it keeps it all pretty simple for the user experience in terms of there there isn't a lot of, like, gotchas. You you do you follow the rules. The rules are are pretty basic, and you just use the ORM.

Do you think people, anybody working on data and data projects needs an ORM in every project? Is that, something that you've got? I know. Because there's, like, always a conversation about, do I need an ORM? And ORM folks are like, yes. Yes. Yes. And Yeah. Kinda like the ORM stuff. Yeah.

Database Twitter is wild. You know? Like, some of the most opinionated, aggressive people out there on Twitter. And I think that's why Drizzle has such a funny online presence because Yeah. It's a lot of these guys are insufferable.

Yeah. Yeah. So,

I guess the problem there that a lot of people think about ORM as the data framework thing.

The like, ORM should you so much that you forget about SQL JS much as you can and do caching for you and do a lot of this stuff that basically Wes won't use it. So I personally don't want to use, like, data frameworks. But ORM, on other side, JS like object relational mapping. Just map my data to the TypeScript objects, and then I will deal with them. Those this is what ORM about. And when you hear all those things like Oram about, they're making you a lot of bad things, bad queries, bad performance.

I guess people often talk about, like, data frameworks and not yeah. Like, HyperNet, not ORM.

And I think you definitely should use ORM at least on the some basic where you're building stuff. I mean, don't use migrations if you don't want to. Don't use some relational API like.

Just use query building. Just just just to find your schema, see the types, and make sure if you change the table, you will see some query that we changed and just help you to iterate faster.

In this case, if you will look at this, from this point of view, just ESLint ORM as a simple tool that help you to map your database data to TypeScript object, I guess it's really important to have in any, in any code Bos. Yeah.

Yeah. Even with TypeScript nowadays, it does feel like that smooths the pinpoint of connecting your data to your type system. And even the, like, ORMs I was using in the past, if they didn't have a good deep connection to the type system, I was writing types in, like, 4 different places, and it just got out of hand really quickly. So, yeah, I think y'all do a a great job of that.

I wanted to add that, first of all, on Twitter, Node asks if, they should use Drizzle or ORM.

Our account always responds no because this is number 1.

And second, if we have, like, layers of, how you can use ORM slash query builder slash data framework.

So each and every project will have a perfect sweet spot on this gradient of needs. And we made sure Drizzle is, pluggable into any of those.

So you can opt in to use Drizzle at any point of your business needs. You can opt in to use query builder or relational queries. You can opt in to result schema to be source of truth or not. You can introspect your database and just use the database as a source of truth. You can opt in to generate migrations with ResoluteKit. You can opt in to apply migrations with ResoluteKit or the ORM itself. So yeah. Yeah. Sick.

And if you want to see all of the errors in your application, you'll want to check out Sentry at century.ioforward/ syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on to reduce century.ioforward/ syntax. Again, we've been using this tool for a long time, and it totally rules. Alright.

Wes.

I got a question about filters, specifically someone who's coming from Prisma. Probably a lot of our audience, was probably coming from Prisma, and you you write a filter where you're gonna select some podcasts and you wanna say where the the show is equal to this number or where, the number of comments is greater than than 300.

And in Drizzle, to write a filter like that, there's there's kinda 2 ways. Right? You you have a function filter, which gives you access to the different methods, greater than, less than, equal to, etcetera, or you can import those those methods themselves, greater than, less than, whatever.

How come you have to do that? How how come you have to use the method to to compare them versus the the Prisma way, which is you can just add a property on the filter, which would be greater than, less than, or equal to.

I yeah. So I can explain. You you are talking about 2 places where I can use it. So first is like a query builder that is SQL like. There, you can use only functions that you can, import, from Drizzle. And then there's relational API where I can use, like, both things.

And about relational API, I just wrote a post about that that we think that our, like, our rational API right now is awful and we understand that. So we did this, like, 1st iteration after using it. We understood, okay, our relation define in schema is hard to follow, understand our queries. There is and filters as well a bit hard to understand.

And we have this big discussion for relational we do where we changed completely the relation's API schema and the filters where you will have an object, just an object as you ask. But like it's just Sanity it won't be functions. It will be an object where you can do and or like great equals all sort of stuff there.

It will be changed. But in SQL like query builder, it will still be the functions.

The case is our query builder is not inferring anything from schema. You put schema inside query like DB inserts user stable, for example. So you put an object inside the query and then use and then put the, those object inside the fields just and so on. So we can just infer that.

You need to put it inside. And to put it inside, you need to have a function where we need to put this this value, for example. And a lot of people saying to us that, okay, it's hard. You always need to import those tables. You always need to import those functions. It's it's really bad and awful, but when I have a big code Bos, and I personally when doing such stuff, it's so easy to just click on user's table object and go directly to my schema and see what is inside and then go back. Mhmm. I can go from every part of query inside my schema and check it. Because as a developer, I often check query and then I need to understand what else I have in schema, for example. And it's easy for me in the project to navigate from and to. And we still think this is really great feature of our SQLite build. Yeah.

And, I I mean, we've been bombarded by this question for, like, over a year. And we usually have a a chitchat in Twitter, and we elaborate that we went through every possible way for you to compose the filters in the WER. And this is the best, which has most applications, the best common denominator.

Yes. You will have to import, and that's the only downside. But you now have the composable API, which you can, pass through the function as a filter.

You can, compose the filters, above the query. And what people, don't think about usually is that for whoever's gonna build on top of our API, this is now gonna be way easier and, to do.

And you can ask, payload and you can ask and whoever is gonna build on top of our APIs. So we have to think about all those stuff because we build the query builder as the lowest obstruction possible on top of SQL so other people can build on top, whatever they want. Mhmm. And you will see on Twitter that people even in in their own just project they do for, as a job. They are building abstractions on top of Drizzle because it's the easiest.

It's very easy for them to do having that API.

Yeah. I think you think about that. The the benefit of explicitly importing the schema is is really handy because then you can click through to it. Because I have some projects where it's just magic, and I say, okay. Well, where is this defined? You know? And then I gotta go look for my model's, folder somewhere and and find it out. So the the explicitly importing it and I the reason I asked that is because often, I come across these, like, slightly different ways of approaching something, and I can just, like, feel myself being like, this is not what I was expecting, but there's probably a really good reason behind it that I'm not a good enough developer to know. And that's why I I asked that. So that was a that's a great answer. Yeah. I've always seemed to like the importing myself and using that as a filter.

It just feels like a little bit more solid to me than, how I've done it in other instances.

I wanna talk maybe a little bit about the difference in approach between some of the other big ORMs or at least the newer ones. You know, I I guess you could say Prisma is still a a newer ORM, all things considered.

So, like, Drizzle versus Prisma versus, I I suppose, Keasly, is it? Keasley, I believe, is is one of the the big ones. Do you feel like your approach differs completely from theirs? And and if so, like, what makes your approach better?

Wes, well yes. So, we are vastly different from Prisma.

We were vastly different from Prisma, and we truly believe that we enforce them to follow our game. So we truly believe that we made the most balanced instruments on the market and the most flexible one.

And we are the only one around which has dialect specific, branches.

So if you're using SQLite, we have everything for SQLite possible, and it's prefixed with SQLite. If you're using PostgreSQL, we have everything for Postgres. And we developed them as a separate dialects, as a separate code basis.

And we went with the query builder first, and then we introduced queries to help people transition from the world to ours.

And we were betting on the SQL like first, performance first, and then introducing new features without trade offs.

So we've had a a vastly different values as opposed to Prisma, as opposed to Kisli.

I don't know. Off top of my head, I have to think.

Yeah. Yeah.

Like, thing is Wes are a bit younger than than those 2 tools. And before, Wes public, we were going through the API, the half, trying to use them on projects. And to be honest, we took something from both of them.

From some like, we took more for some, it took less.

And maybe we changed a bit, but, those 2 tools helped us a lot also with the decisions we have because those are already built. You already can use them on projects. You already can evaluate what decisions were good and what decisions were bad from them, and then imply it in what we have. So for example, right now, we thought we did good relations API. And now after time, we evaluated that it's bad and we need to change it.

And all things before, we already had existing tool where we can just check it right now because already people using it. So, like, we differ from them, and I'll ex explain that. But also, we took, some approaches from them that are familiar for you if you like, relations API is really similar to Prisma's Node, and thanks them for that.

And the thing we do like, did more for that, we took the API, but we did this 1 query, generation for any complex, relation query we have.

And I hope, I don't know, the latest Prisma upgrades for performance when they did joins finally.

I hope that we make some impact on that, and they took some assumption from us as well. So Yeah. It's great for both worlds, actually. Yeah. Yeah. Totally.

Yarn you guys friendly with the the Prisma folks at all? I know there's a a lot of, poking that goes on along online.

I'm curious if you ever have calls with them or anything.

Yeah. We had 1 call with meeting, Gupta.

I believe he's his chief operational officer there.

Yeah. We were talking through potential collaboration with them, but never something specific.

Rather than that, we haven't met or called, or talked to anyone out there. Oh, yeah. But we send them the hoodies we've printed to Berlin headquarters, but they never ever, responded back. That was heartbreaking.

Oh, that's funny. Yeah. When we

were, introducing relational queries to the, drizzle, we sort of came to the common agreement that, the future of ORMs, at least in the TypeScript world, is gonna be basic CRUD plus queries.

So you gotta have a query builder, and then you gotta provide the easy to use relational API for full stack developers, front end developers migrating to back end and lazy back end developers who don't wanna.

I'm joking.

This API, like, the query API is superior in terms of the development experience, but you've gotta have the the good solid query builder for you to build any kind of a SQL query.

So we call it query prop plus CRUD.

And the the fact that Prisma is now building an SQL query into Prisma, which is nuts. You know? I truly believe that they they had the philosophy that you should never write a scale. And seems like we forced them to go to SQL world 2.

And, we Scott of, going to meet in the middle now, which is gonna be a sweet spot for every other rail that RAM that's gonna come out. They will have to be here in the the most Yeah. Perfectly balanced sweet

spot. Yeah. I appreciate that, though, because we we have some projects on Prisma. We have some on Drizzle. We like to try everything out. So if y'all could keep on improving each other, that'd be great for us.

Yeah.

We're just here for the benefits of it all. Yeah. Alright. I do wanna ask. So Drizzle supports Postgres, MySQL, and SQLite. And then of all of those, they support, like, many different implementations, lots of, like, hosted versions. You Node, Cloudflare d one is a little bit weird, Vercel, Neon, things like that. I'm I'm curious if you were starting a brand new app, what would you use both in database as well as, are you using the query or select?

The database is a tricky question because we've been sponsored by many databases out there.

We'd potentially pick one of those, I'd say. Okay. Yeah.

But, in terms of query or CRUD, it will depend on the business demand solely.

I usually lean to queries, of course, because it's simple and straightforward.

And, I will be honest. I don't really like Wes SQL.

I'm not a big fan of. But we know that the SQL is gonna stand, and it's not going anywhere. And we just wanna make the SQL experience better. Yeah. And you're making the

Yeah. Yeah. Yeah. I just wanted to add that Alex said that that he's, like, for queries API, and I'm fully joined guy. So I'm always, like, do joins. Joins. Yeah. Yeah. Yeah. Yeah. Yeah. Old school joins. And the thing about choosing databases, it's really, really important.

I know a lot of database providers are sponsoring us, but you don't need to choose it just because it's it's just some fence in your provider or that it has some specific feature. You always need to remember that behind the, like, database provider, there JS, like, a core of database. It's PostgreSQL.

It's MySQL.

It's SQLite.

And all of them have different features, limitations, and all that stuff you need to think about when you're doing some project.

Either it's heavy on reads, heavy on writes, you need to do sharding, you need to do there are a lot of things we need to think about.

And after that, you need to choose the core. So you chose, like, pause rescue. And after that, you can find the providers who can give you the most of what you need. If you want just some hobby project, just use Torsosculitis really easy for us. So this is what I would do. But Or so very performance.

Yeah.

That feels like it has to be, like, one of the most complex aspects. I mean, considering how many different technologies you support, does that part get exhausting having to make sure that you're covering every angle? And, like, how do you how do you make sure that you don't introduce something that's going to to break 1 specific project?

That's the beauty of us not having, like, a common dialect for everything and just having a separate dialect per specific database.

And, let's say the Xata, which are our sponsors, they have, like, a version of PostgreSQL with its own, like, obstructions and extensions.

And we will just fork the Bos SQL dialect for them. And then we're gonna without damaging anything else or intruding in anything else, we're gonna have everything that extra there. We we're gonna have it as a separate dialect. And this way, we can iterate faster and not having to maintain the burden of common dialect and trying to not introduce new things and don't break Mhmm. Wes previous ones.

Yeah. Actually, this is one of the important things in Drizzle. We don't follow, like, dry principle at all. We just copy all the stuff we have. So we have postscripts dialect. We just Scott to my sequel, change the naming, change the features, then we copy to escalate, change to rename and do the stuff. And then if you need to add anything to Postgres, you just edit there. You don't need to think about obstructions, how you should do in a way it will be in Postgres, but won't be in MySQL.

You just copy it and that's all. If you have a feature that's in 3 of them, yeah, you need to do 3 times Node thing. But in the long run, it's easier. Yeah.

Yeah. We don't have, like, a huge budgets. We have a lot of motivation, and we have to iterate, efficiently.

So Wes thought of this, this is gonna be the most efficient way to iterate and the best developer experience for people. Because we don't truly believe in this concept of, I can just now switch the database from PostgreSQL to MySQL. We just don't believe in that stuff. And, we decided that whoever is, like, influenced by this statement is not a potential user for our case and letting him use all the tools.

Yeah. We are all about the you have to commit a particular dialect, and then yeah. And we're talking. Mhmm. Oh, okay.

Upfront. That's that's really interesting. Like, the 2 things you said there. 1st, like, copy paste driven development. You're starting to see that a lot more in, like, React component world lately as well where people are like, I'm sick of high order components and composability.

You know what's better than that? Copy paste. I can just do that directly.

Oh, yes.

Also, just picking it up, picking your database up front and, and learning. I'm I'm curious, like, if you did have to ever switch your database, like, how much of the the code would be different from Node to another? You know, like, let's let's say I'm going from Postgres to, MySQL.

Yeah. You will have to change your schema. Queries would mostly stay the same.

For the schema, you'll have to change some particular parts. It's not gonna be a big chunk of work.

And I also wanted to spoil that we're about to build a migration tool because Uh-huh. Migrating data between databases would be a way more, complicated, yeah, chunk of work than changing schemas in your code and queries.

So, yeah, this is something

we are working on behind the scenes and, potentially introduce this Yarn as an open source for That's cool. That's one really cool thing that Drizzle does JS there is obviously Drizzle and all the adapters, but there is, DrizzleKit and DrizzleStudio.

Let's talk about Drizzle Studio, which is a a GUI for basically editing your your database and viewing your data, which I love being able to have a a GUI for that type of thing. So, like, you might be used to, like, a a TablePlus or, what are the other ones that I've used in the past? SQL Pro, MySQL Workbench. You guys just casually built a database viewer as well?

Yeah.

This is a very interesting story.

So we've launched the, last summer, last May, we've launched the relational queries.

And people Yarn like, okay.

Our number Node, deal breaker with Drizzle is lack of Prisma Studio.

And they were like, come on, peeps. Just use Beekeeper. Just use TablePlus.

Please just use Yeah. We don't wanna build, Drizzle Studio.

Wes use those tools ourselves. They are great. Just use them. And they were like, no. No. No. We're not gonna migrate until we have, like, drizzle studio, command.

Let's do it. So we did it. We spent the months. We spinned up the 1st version, which was mostly the copycats of Prisma.

And then people started using it. And we started using it ourselves, and we were like, okay. This is this can go somewhere.

So we started iterating on Drizzle Studio.

Then they introduced Drizzle Studio v 2, which is a major upgrade.

It is now, like, 1 step, behind 1 step, before it's gonna become, like, a fully fully functional database tool for people to use as a stand alone application.

And then we started experimenting. So we've introduced the concept of embeddable Drizzle Studio, and we've signed with 5 companies.

The first one was Torso.

Then we've signed with Neon. We've signed with Next Hub, Decosix, and, Hydrasar.

And all of those companies, they now have natively embedded version of Drizzle Studio into their UI, which is outstanding.

It's awesome for us. And Hopefully, good for them. Yeah. That's for anybody

using any database, not just if you're using Drizzle?

It is for everybody. It's completely Drizzle agnostic.

It is, like, composable. You can have or not have Wes SQL query runner, And it works Yeah. Mostly exactly the same, for everybody. I mean, like, we have a a version for SQLite and Cloudflare d one for Max Hub.

We have LibaScale for Torso. We have PostgreSQL for NEON and and others.

And, yeah, we build it completely, crystal agnostic.

And it's just a web component for you, so it's completely secure.

It just asks for a callback to run queries on the database, and that's it.

So you are in charge of credentials, etcetera. So it's a a beautiful concept. Yeah.

Man. Wow. So you took one of the most annoying parts about using Cloudflare d one and made it awesome. So they launched a Chrome extension that you can just hook up to different databases. But because Cloudflare is kinda weird in that you can't there's no, like, connection string to to Cloudflare. Right? It has to be inside of a worker.

You can't just, like, connect to a string and view your data, which is what everybody wants.

Yes. And you guys figured out how to how to get around that?

Yeah. I've spent half a year talking to Cloudflare about that, And we are really trying to tell them that this is the perfect product for them to have natively.

And we were going through conversations with PlanetScale, and we were going through conversations with.

And we are not have not landed yet, but I'm not gonna give up.

I'm gonna knock that door again and again.

So we were like, okay. We're not gonna this is a very inertia, like, stuff to do.

So we decided to think differently, and we were like, okay. How how can we get there? And the the answer is the Google Chrome extension.

We can just see what the requests they're doing. And we are just sending essentially those requests through your web page, to the API they have, and then we represent the data.

So we've built it, like, within several days.

And, we now support Vercel, Postgres, PlanetScale, and, Cloudflare d one.

And we are going through conversations with them.

So if we can't get to the the vendor native dashboard, maybe there is a potential collaboration

for them to sponsor our development of Chrome extension. Yeah. It's gonna be, yeah, maybe there. Cloudflare, come on. Yeah. Yeah. Yeah. It's so it's so much better than what Cloudflare gives you. They give you, like, Node of 10 of a 150 rows, and then you can you have the ability to click on update, which takes you to a separate page, and they just give you checkboxes to to update them. Like, the the experience on Drizzle Studio is a 1000 times better than they certainly should at least be sponsoring. I have a meeting with them tomorrow. Hopefully, they will. Good. Well Nice.

Yeah. Tell them I said they should. Yeah. Yeah. Also, you got a a syntax theme for, Drizzle Studio, so you can rock the syntax theme if you search for syntax fm. Oh, yeah. Oh, yeah. I did this. Yeah. I remember that.

And You should give this a a whirl. So okay. So let's talk about, a minute about, like, drizzle kit itself.

I I know, like, that was a big hang up for me was I I don't have a ton of experience in migrations. I came from a, like, a MongoDB heavy world. So when I started getting into doing more Postgres in my Wes, it's like, I need a tool that will handle migrations for for me. And I really do feel like Drizzle Kits migrations tool has done more for me in learning how migrations work instead of obfuscating it completely.

Was was that intentional to make it like, hey. This is a a thing you kinda have to know about, but we'll help you with it, or what was the strategy in creating the migrations tool?

I I guess the intention was completely different.

So you don't need to think about writing the queries, and Keith will just generate it for you. So you need to okay. I need to create table. How do I write this query for creating table? I just hit generate, and it will show me. Oh, I hit push, and I just have it in my database right away. And I don't even know what happened under the hood.

So I guess this is for the first intention for that. But, like, the history of Drizzle kit with like, when this this was Java version of Drizzle RAM, we had some tools that we built to make the migration, but it was inside the ORM.

Wes you're just on the Scott up of the back end of script, you write the, like, user stable Scott create, user stable dot, like, alters something. And it Wes, like, builder pattern of those migrations 1 by 1. This should be applied. And we thought it's great until we understood it's not because if you change your schema, migration will be changed as well because it's right here in code. Mhmm. And when we started changing the schema and new person in the project start running it, we understood, okay, something is wrong. So we need to think about that. We had this idea of how did we call it? Migration cemetery.

Yeah. Migration cemetery. They just

Yeah. Before you delete the table, you put it somewhere else so you can apply migration of deletion of the table. So it was

awful. Yeah. But he was struggling through it. Yeah. Yeah. And then we understood that there's already everything invented. You just need to run a scale files 1 by 1 and, mark them in the database of the applied ones. So this Wes, like, 20 years ago, 30 years ago, and we need to do the same thing. But writing migration queries can be really hard and sometimes tricky. Yeah. You can handle everything, but you need to think about how the things work. And sometimes you just need to fast iterate and don't need to think about the stuff. Doing push, doing generates, right here. So I guess this is what the intention. Nice.

Yeah. Yeah. It it's been Node for me, like I said, coming from a a Mongo background where you don't even think about you just change the data, so you start working kinda fast and loose, and, this allows me to continue doing that while making it easy to to change later.

Yeah. We've worked with Mongo for a long time too.

Like, when we began doing outsourced, we've been using Mongo.

And we realized really fast that the, freedom you have will catch you up later.

And then after a couple Yarn of commercial development, we realized that having this strict schema is a restriction, but it it makes you do disciplined decisions.

And it protects you from doing wrong stuff further down the road.

So, yeah, essentially, Wes at certain point in time, we landed on the SQL databases and, yeah, as a source of truth for most applications.

And Yeah. You you probably will never support MongoDB, with the the API. Right? On Twitter, we will,

but no.

And and why why is that? It's just because it's too too different of an animal?

Yeah. It's not an SQL database. We are an SQL.

So yeah. But Drizzle Studio potentially will support MongoDB.

Yeah. Not not this year, but next year. Wes.

Yeah. Because that that I guess that makes sense. You're just getting data and able to see the data.

I I did notice that there was, in one of your later blog posts about supporting PG lite, which is a WASM based in browser Postgres database.

That's really super interesting. Have you guys been considering how to make Drizzle maybe a little bit more, I don't wanna say, like, compatible, but useful in the local space, like the local data storage space?

I can elaborate on that.

So first of all, we already support support PG lite.

Andrew, like, Node, I don't know, like, within an hour, he made some patches, and we've supported PG lite as soon as they announced it. Yeah.

And, we already have made a support for native Aesculites in Expo.

We not only have the native driver for Expo SQLite.

We also support live queries.

So for whatever changes in database is gonna reflect on the UI. And we've also made the Adrizzle Studio as an export dev tool.

So you can now now browse the data on the actual device of yours. And we are going for a conversation with can I have, like, couple of meets and potentially land in their docs as a go to tool for browsing database? And Drizzle since, Drizzle JS, runtime agnostic, our demo that's Drizzle dot studio is supported. It's like a, SQL JS driver.

So it's fully a competitor it's fully deployable to a web application.

You can use it without Node. Js or Bos or whatever.

So you can use it as a since day 1. Yeah.

That's amazing. Yeah. Yeah. Cool. Alright. I wanna talk

about, one thing. Like, it's impressive enough that you guys have have built this thing, but the thing thing we haven't mentioned yet is you guys are all from Ukraine. Right? Obviously, a lot going on in Ukraine right now. Yeah. What's what's life like in Ukraine right now?

So, like, if talking, alone, we can talk for hours about that. Yeah. Talking short JS just it's Yarn, to be honest.

I I guess

anyone get can get used to anything around them. You just need time for that.

And, seems like we found some ways how we can, like, schedule our day, how we can schedule our electricity and Internets so we can work, how we can schedule all of that stuff.

Thinking about Wes, if it's possible, I mean, you should you should do that.

In in any way, you can do that. You can go to swimming pool. You can go to some, like, therapy or any anywhere anything that's, like, helping you to rest.

Yeah. It, like, it should be in your routine.

Yeah. So I don't want like, as I said, we can talk about that a lot of maybe something you're interested in.

Yeah. I'm I'm I'm you can try to explain. Said you have to schedule schedule your Internet and schedule your your your power. And even I told Scott, I'm like, hey. These guys gotta record before whatever because they have a, Outages.

What Wes the Yeah. Outages. And, what was the word I I used, Scott? You said curfew.

Curfew. And Scott's like, how old are they? I'm like, no. It's not Node a age curfew. It's the it's gone. So there's Yeah. Tell us about that. There's outages of power and Internet?

Yeah. Yeah. So, through, like, last months, we've got a lot of rockets hits our power stations, and it hits like Wes already, lost around 75% of whole power in Ukraine. So we have only 25% of thing that can generate electricity.

And right Node, we have, like, 40 sales degrees.

I don't know how we will be in Fahrenheit. It's a lot. No. It's a it's a Canadian podcast. We don't we don't convert for Americans. Yeah. The rest of the world listens. Yeah. Thank you. Well, it's 40 right now? That's 40. Right now. Yeah. We'll we'll convert we'll convert for the Americans.

Alright. Yeah. A 104.

Yeah. Okay. So Yeah. You need to use air conditionings, and they took a lot of electricity.

And that's why our government need to, separate you by groups. So, for example, this area will have electricity from 10 AM to, for 2 a like, to 2 Npm, for example. This group will have Internet from 5 PM to 8 PM, and then you don't have electricity at all. You don't have Internet for sure. You don't have even you don't have, like, a mobile, you can't use it because it also Node an an electricity to get to the power and get you the in, like, the Internet or, like, whatever. And right now Wes have, like, it's crazy right now. We have around 14, 16 hours a day without electricity and 8 hours only visit.

So we have this, like, blue Yeti. We have this Show Bos. Like space

I I can actually show it to you. Yeah. Let's see. No. No. Don't leave. Don't leave. Just show us the MacBook here.

I have the iPhone. So we have this station here.

I don't know if you can see it. Yeah. And we have,

so we have Internet on air outages.

Yeah.

And, just because we are Scott, Linux guys, we can work on the MacBooks, for quite quite some time

because of the

Oh, because

of the battery. Yeah. Yeah. Yeah. Yeah. If we were Linux guy, Drizzle would stop. Yeah.

So you're running I'm on Starlink right now. I'm I was actually a little bit worried because we're getting a the remnants of a hurricane right now, and I was a bit worried that it would cut out. But we're hoping that get rid of the Starlink soon because we're getting fiber, where I am. And a lot of people say, hey. When you when you're done with your, your Starlink, send it to Ukraine because I have the original one, which is apparently the best in in Ukraine. So you're you're running that on a big power bank?

Yeah. Yeah. We have a power station. We have 2 car accumulators.

So we charge them when we have electricity. And when go to and don't have electricity, we supply the power to notebooks or the StuntLink. Yeah.

Mhmm.

Wow. That's really, really smart, though, to be able to get that set up and, be able to to to work through those types of conditions. Do you do you feel like, it affects productivity on the project? Do you feel like the project isn't inspired more inspired because of it, or is it just something you deal with?

It's draining. So in order to create, you have to have this creative energy. And, it depletes really quickly when you have, like, explosions, etcetera.

And you have to run through those conditions.

But, I mean, thanks thanks to the human psychological, like, core, we we're capable of adapting. So we are adapting and, just grinding through. Yeah.

Yeah. Yeah. And actually, like, electricity is the least actually if you think about. Because, I mean, you can charge this big power bank. You can you can think about Starlink.

When the rocket hits Yeah. Right near you and your door is opened and windows just doing this this thing. I don't know how to Jeez. Really? It's it's it's really hard.

It's also happened at night. So you want to sleep. You want to recharge yourself, but you can't because you need to go to shelter.

You need to do all that stuff.

So electricity JS, like, the easiest thing here, to be honest.

Wow. Yeah. And the experience of that is whoever is gonna tell you they know how it is, but they've never experienced this in their lives, there's no way I'm gonna believe them unless you, like, feel the overwhelming power. Yeah. You're not gonna understand what it is psychologically.

Yeah.

Yeah. But we try to not brag. Yeah. We're trying to we're staying, positive in all senses. Yeah.

Oh, man. Like, props to you guys for that because, like, I I can't like I said, I can't even imagine what that is like, for that type of stuff. Where where in Ukraine are are you located? There's there's 3 of you. Right?

Yeah. Yeah.

Keith and Dini Crow.

Okay.

Yeah, man. I mean, there JS not only 3 of JS already. That's also a subject, for discussion.

We have recently enlarged the Drizzle team, and, we now have 14 people working on either different parts of Drizzle, either the core or the knowledge base or the community management.

And we are also working behind the scenes on other products.

So we've, sort of sneak the picked, the broccoli or bro CLI.

We call it senior library for it's gonna be like a competitor to commander GS. It's a TypeScript CLI builder and stuff.

So we are also Oh. Trying to spread now and do other stuff we are capable of because we truly believe that we can.

Sick. Yeah. Wow. Yeah.

And is this your full time job then? Right? Like Yes.

How how do you do that? Right? Like, obviously, we're trying to sell some T shirts, but it's not gonna not gonna pay for 4 guys full time. So, is this it's sponsorships?

Yes. And, I mean, we were making some profits until we sort of transitioned Wes developers in Drizzle and committed, like, doing it full time.

And, now we solely believe that we can both spread the open source, venue we have. Also building some complementary products for people to to buy. And, we actually are losing money right Node, regardless of, the sponsorship's been wild. I mean, those numbers in the open source world, I mean, I I believe we are in top 1 or top 0.1% of the projects, in terms of amount of sponsorships. Yeah. But, if you translate it to salaries, those are not gonna stand out much.

So yeah. So we are reinvesting. And just because we truly believe into the what we build and how we build, and we truly believe that we can, by losing money, invest I mean, not losing. Me investing money, I would say. We are investing money into the future. Yeah.

Yeah. Wow. Yeah. And, I mean, it shows the the care that you guys put into the product shows. You know? Every time you release something or drop something or improve something, it's awesome. So, shout out to what what y'all are doing. And I I really personally really enjoy using Drizzle. So I know a lot of folks do as well. So, yeah, congrats on making such an awesome project. Yeah. Let's get into the part of the show where we talk about sick picks and shameless plugs. A sick pick is something you're enjoying right now, and a shameless plug is something you wanna shout out. Do you have a sick pick and shameless plug, Andrew and Alex?

So this was a thing that maybe I can share in chat here so you can look at it. Yeah.

So I just recently found so, like, my background, I was I'm I'm like, for 8 years, I would do in professional swimming and doing, like, 2 times a day trainings and go into the stuff like that. And I was all about things that you could use while you're swimming. And this is new goggles I found that can just show you on the screen, on their your pace of swimming, your heart rate. You could it could show a lot of stuff for you right here. And if you open water, stuff, it can show you where you're going like a GPS ESLint. So you can go and track what you're doing. So this is crazy, and I really wanted to try that. Wow. Because we were in Greece with Alex on the

Ocean man.

Yeah. On Ocean man, Wes can choose like 2 kilometers, 5 kilometers, or 10 kilometers in the sea, and you can just do this race and Yeah. And that's it. And I remember how hard it was to navigate through the open water because all my life I was doing, like, swimming pool trainings.

You see, yeah, you see where to swim. But open water, if you do Node, like, a few degrees right or left, you're going somewhere.

Like, it's really hard to navigate. And that's like, and these goggles can show you where you're swimming. So this is really crazy.

Yeah. That is crazy. It's like just like overlays on top of the goggles while you're swimming. There's a little projector on the side. Yeah. That's cool.

I'm I'm at my cottage right now, and I have the the Apple Watch. And when I go swimming, it immediately goes and shows you how deep you are. So I've been trying to, like, see how deep I can go without, like Dying. Imploding. So I'm not I'm not a strong swimmer, though, so it's not very deep yet. Yeah.

I didn't come up with anything.

No? Okay. That's alright. That You can You don't have to. Wes can shameless plug something. So is there anything you guys would like to plug?

Those 2 links to our biggest fundraising that helps people in Ukraine.

You can choose whatever you want to help, like hospitals. You can help people who need to leave their houses, that need to rebuild their homes, and all all of that stuff. You can read about that if you want.

I guess it's really important to share those Tolinski. Right?

Yeah. Absolutely.

We'll make sure those are available on the show notes.

And as Wes, if you wanna, help support the Drizzle project, you can sponsor them directly, or you can pick up a Drizzle shirt on, syntax.fmforward/shop.

And, yeah, rock the Drizzle shirt. I actually I'm not wearing mine because I wore it yesterday. So I I've been loving this shirt.

It's pretty sick. I love the green.

So yeah. Thank you. Pick on pick 1 up. Yeah. Awesome. Cool. Well, thank you guys so much for coming on. Really appreciate all your work on Drizzle, all your work on all of this stuff and sharing, what's been going on with you guys. I appreciate all your time.

Thank you. Thank you so much. For having us. Alright.

Peace.