Software Huddle - From ORM to Infra: Prisma Postgres with Søren Bramer Schmidt

Episode Date: April 22, 2025

Today we have Søren from Prisma on the show. Prisma has been the most popular ORM in the TypeScript world for a while, and now they’re moving more into hosted infrastructure. We spend a lot of time talking about their new offering called Prisma Postgres, which is this unikernel-based Postgres offering. It’s a really unique offering from both a technical and a product perspective. On the technical side, they’re doing some interesting work compared to other Postgres providers. They’re running on bare metal in a colocation facility rather than the default public clouds like AWS, GCP, and Azure. Further, they’re using unikernels in a Firecracker VM, giving them unique startup and security characteristics. These technical decisions give them unique economics compared to standard providers, so they’re able to have a generous free tier and a unique billing model that works great for serverless applications with spiky workloads. Around all of this, it’s very interesting to see a company with such a unique spread of products — a popular, mature open-source library paired with a mission-critical infrastructure service offering. We talked about the difficulties in building a company that accommodates these two very different products. Timestamps 01:51 Start 06:08 Prisma Postgres 09:10 Accelerate 11:39 Why Postgres 17:32 How Prisma Postgres Works 21:32 Colocation Facility 22:05 Unikernels 27:56 CoLo vs Public Cloud 29:11 Building the team 31:46 Missing Features that are being worked on 32:31 Use Cases 33:37 Colo Locations 34:53 Cloudflare 35:42 Biggest surprises since release 37:34 More Unikernel adoption? 39:08 Supporting Prisma ORM 46:43 Mongo 47:51 Life as A CEO 53:04 MCP 57:23 Søren Questions Alex Software Huddle ⤵︎ X: https://twitter.com/SoftwareHuddle Substack: https://softwarehuddle.substack.com

So let's answer this question. Why Postgres? Why is Postgres so popular? Yeah. Why Postgres? Why did we choose Postgres? I, that's a great question. I don't want to ask you that because it really is, uh, it has taken off.

And, you know, I just talked to Sam Lambert, who is of course, like the MySQL guy. And he's like, I don't get why everyone loves Postgres. You know, y'all released this, I think five months, five, six months ago was like the initial one it's been GA now for a little bit, I think, five, six months ago, was the initial one. It's been GA now for a little bit. I guess, what are the biggest surprises from running it for five or six months now? It turns out that when you build what people want, you get a lot of people using it.

Tell me about Unicurdles. I read about Unicurdles as part of this thing. How do Unicurdles work? So instead of having a full Al Alpine, Linux or something, you keep only the tiniest bits from that operating system that you need to run the application. Alex, what's going on in your world? Oh, man.

Hey, folks, this is Alex. I'm excited because we have another good database episode for you. We have Sauron from Prisma. Prisma has just been like the ORM of choice in the TypeScript world now for a while. So like they've been huge. I've known the Prisma guys for a long time

back when they were Graph Cool, like this GraphQL thing. It's been fun to see their journey. And now they have Prisma Postgres, which is what we spend a lot of time talking about, which is this Unicurl based Postgres offering, super interesting around just like paper use, usage based billing, fast cold stars, all that sort of thing.

So we go into the tech behind that, just what it's like running this company with like two separate things, this Prisma ORM, and then also these like managed services, very critical cloud services. So really interesting conversation with Sorin, great to have him on. As always, if you have any questions, comments,

guests that you want on, feel free to reach out to me or to Sean. With that, let's get to the show. Sauron, welcome to the show. Alex, it's good to meet you. Yeah, absolutely. I'm excited to have you on. You are the CEO at Prisma,

which is just like one of those core foundational companies in the sort of JavaScript type script world, web development type world. So excited to have you on. I remember y'all like way back when you were Graphcool and talking to Johan's then and that stuff. So it's been fun to see your journey over the years now. But I guess like for people that don't know about you

or about Prisma, can you just give us an overview of who you are and what Prisma does? Absolutely. Calling us foundational, I think is kind. We've been around for nine years now, which is a long time. So the early days was GraphQL. We built this back in as a service that gave you a database, a GraphQL API

that may make that database and some way to run serverless functions. That was nine years ago. And people really loved that thing. What we found is that our best customers, they would build prototypes, and then they would validate the prototype and then go and rebuild it with proper technology. And we're trying to build a business, so that's a problem for us,

because that means all of the budget, it goes over here without our thing. So we spoke to those people and tried to figure out what was it you liked about GraphQL and could any of that be part of your real thing? And what they all told us was the data abstraction, the way you modeled your data schema and the way you interact with the database through GraphQL. They liked that part.

So that's what we turned into the Prisma ORM. If you have used Prisma, you know that it feels a little bit like Graph part. So that's what we turned into the Prisma ORM. If you have used Prisma, you know that it feels a little bit like GraphQL. You have this tree structure you describe upfront in such a query, then we go and load all of that data for you. The way you model your data structure looks like a GraphQL schema

because that's where we came from. Yep, absolutely. I remember, you know, I was back at Serverless Inc. back when this was getting started. I talked to Johannes and he like showed it to me and he was like all pumped about all the typing. Like you get all these types and stuff like that. And at that point, I was still like not in the typing world. And I was like, okay, like nicer autocomplete in your editor. And now I'm like, now I love TypeScript. I'm like, oh my gosh. Yeah, he was, you all were like way ahead of the curve in some of that stuff. And understanding like

unifying some of that front and back and typing stuff and just like how good it was. Yeah. It was a really interesting time where everybody was doing JavaScript. JavaScript was starting to happen on the server also. And there was this war between Flow and TypeScript, and it wasn't really clear which of them will win. Obviously, there was a lot of momentum behind Flow, and that was kind of tying into the React or the GraphQL thing. But at some point, the scale had tipped enough

that we could say, OK, TypeScript is definitely the winner. And also, TypeScript just enabled so many cool things. I think we were the first major library to really push the boundaries, use conditional typing, get all of this. You can do arbitrary SQL-like queries with Presma and we give you complete type safety of the input and the output. And right now it's beginning to be normal, but five, six years ago it was really new. It was really exciting.

Yep, yep, for sure. I love it. I guess I don't know how you measure all this stuff, but I assume is Prisma the most popular TypeScript ORM? It's the one I hear about the most for sure, and things like that. So we've obviously been looking at this very intensely, and it's difficult to get a clear picture.

But the best data we've settled on is just NPM downloads. Everybody can go and look at that. About two years ago, we crossed the line. We are the dominant TypeScript ORM and we continue to put distance to the next ones. That's a really nice feeling. Also, we are still the TypeScript ORM that gives you best, complete type safety. If you use some of the other ones, they have gaps. They will let you do things where you can get a runtime error instead of a compile time error,

because they don't do full type safety. Yep, yep, okay. Yeah, it's been fun. I love it. It's super powerful to see it. It's been fun to like see it grow and also that sort of stuff. And I want to talk about the ORM more, but I want to actually start with Prisma Postgres. That's why like we sort of connected in the first place and just talking about this, which is a new offering that y'all have. So maybe start off and give me the high level pitch on like what is Prisma Postgres? In my mind, you're the database man. You're the Dynamo man.

Is that right? Are you more of a serverless man? No. I definitely got into it from the serverless world and got into Dynamo accidentally there. Now I just found databases more interesting. More people I have on, we end up talking about databases. That's why I'm really excited to talk to you about this sort of stuff. But also like, I still do a lot of serverless

and TypeScript and stuff like that. So I love Frisma for that. But then, yeah, I'm interested in the Postgres aspect here. I'm interested in database because the serverless stuff, the compute side is kind of soft. It just works mostly. For a long time, we talked about Co-Stars and all this stuff, but we've kind of figured out how to work around that. It just works mostly. You don't have to pay for them unless you use them. It's just so freeing compared to where I came from.

10 years ago, whenever we wanted a new service, it was an AWS. You need to have a load balance, you need to have an auto scaling group, blah blah blah. It costs you $500 at least just to have a dev thing running. Databases are still in that world. Databases are still these fragile things that are expensive, and you babysit them, and you don't just get another one for each of your preview environments. And it shouldn't be like that. So we kind of got dragged into building a hosted Postgres service. For the longest time, we thought our specialty, our advantage was we were deeply embedded in applications. We thought databases are going to be commoditized to some extent. We're going to sit in between them and do something cool by being in the application and

working with multiple different databases. It turned out though that everybody who is using Prisma or thought they wanted to use Prisma, they also want us to host a database. So we've had this cloud product for like four plus years now and more than 50% of everybody signing up, they wanted a product that we didn't have. They wanted a hosted database. So at the end we just had to say, okay, let's do that. Let's build a hosted database. But let's figure out how can we build a hosted database that is better than what is out there? Because we're going to go through this massive effort. It's not something we take lightly. It is now the entire company is focused on this thing because to build a hosted database that actually works for individuals and that scale, it's a lot of work.

Yeah. Yeah. That's a hard problem. So you said, you talked about the post-growth, or sorry, the Prisma cloud for the last four years. Is that Accelerate or like, what's the, what's the cloud? What's Prisma cloud? Accelerate is the primary thing. So it's this proxy and caching system that sits in between your application and your database. The main benefit you get is we do global caching. So we work with the Cloudflare network.

If you deploy your application either globally on Cloudflare or if you have multiple different regions, you can use Accelerate and we will cache data close to your application. That's good if you have a read-heavy application. We also completely solved the serverless relational database mismatch problem where traditional databases really want long-lived connections. Serverless functions really do not understand how to do long-lived connections, especially if you do multiple regions. If you try to set up a super-based database, for example, and have any amount of just reasonable scale from a lambda

function, it just doesn't work because you have these stale connections that are hanging, they stay open in the database, it just falls over and it's difficult to debug. So Accelerate is this proxy. It sets it between, it solves that problem. Gotcha. Yeah. It's interesting. You talk about that connection limit issue.

And that's how I got into Dynamo completely, is because Dynamo did not have that issue. And so many people were using Dynamo with Lambda. Even though it was hard in so many other aspects. And I was like, well, let's figure out how to use this darn thing if it works for serverless. And there are trade-offs to that, upsides and downsides for sure. But it's amazing how long that's been an issue and still sort of is an issue. It's still an issue. For a long time, we were hesitant to solve it because obviously it's such an obvious issue,

the industry is just gonna solve it. We were looking at reinvent after reinvent after reinvent and they just never really solved it. AWS has various different things that kind of works and then got deprecated and like as mess. Yeah, that's exactly right. Like all of these like sort of goofy workarounds that all sort of work or like work in weird configurations. But yeah, it's exactly right. Like all these like sort of goofy workarounds that all sort of work or like working weird configurations

But yeah, it's interesting you say like you expected the market to commoditize this and in some sense it feels like Postgres hosting is like the most commoditized thing there is out there There's like a million service providers for all these different things. But so let's answer. Let's answer this question. Why Postgres? Why is Postgres so popular? Yeah, why Postgres? Why did we choose Postgres? That's a great question. I want to ask you that because it really is. It has taken off and you know, I just talked to Sam Lambert who is of course like the MySQL guy and he's like,

I don't get why everyone loves Postgres, you know, and it's interesting. I don't know. I don't know if it's like the, something about its open sourceness and its community around it or something around it's sort of, I don't know. I guess you tell me, since I imagine you looked into this, like why is Postgres so popular?

So I have never actually used Postgres in production. I'm not a Postgres fan. My entire philosophy is I want the database to be as simple as possible. I've used Dynamo a lot. I loved it. In fact, we used Dynamo for the initial prototype of GraphQL way back in the day when we said we had to move to a real relational database, we picked MySQL. Why? Because it's easy to scale. It's easy to operate. It's a simple thing.

Postgres, nine years ago, was difficult to operate at scale. It's a simple thing. Postgres, nine years ago, was difficult to operate at scale. It's gotten a lot better. It is being improved. But it is still a case that MySQL is more hardened, battle-tested, large-scale. And I know Sam talks a lot about this because all of their customers are like big customers. They're customers who spend a quarter million dollars at Aurora and then moving over to PlanetScale. It's interesting everyone.

So, but the Postgres. Just to aside, there's, man, his display name on Twitter is V. He works for Terso. I can't know his name, but like he's like, Hey, what are the biggest Postgres deployments out there? And it's hard to find the truly enormous ones that you see like in the MySQL world, like, you know, you, you see in the MySQL world. You see terabyte level ones and couple terabytes and single digit terabytes.

But in terms of the really enormous ones, that's all MySQL or Dynamo or Cassandra, things like that. Because at that scale, you can't really rely on the fancy stuff that the database can do for you. You need to keep it that simple and it's worth it to keep it that simple and invest some engineering hours and working around it. And the benefit Postgres has is it has all this stuff, the huge ecosystem of plugins and things it can do.

And it's really cool. And reality is most people live in a world where they can make use of all of that stuff because they don't have multi-terabyte databases that needs to be sharded across a hundred servers. It's just not a thing for most people. So when we look at the Prisma ORM user base, we have more than a million developers using the Prisma ORM. And when we look at all of those telemetry data we collect, we know what databases they connect to. And we can see it is primarily Postgres.

We support MySQL, Postgres, MongoDB, Microsoft SQL Server, SQLite. And it's more than 60% is Postgres. Wow, interesting. Okay. Yep. Interesting. Are you... And then... Huh, that's interesting. I think you're right in the sense of like, hey, Postgres works for so many of these people because they don't have to worry about

the true scaling problems and they can use all these things. It's almost like you all are creating the, and I'm gonna get more into Prisma Postgres, but you all are creating like the Dynamo, but with all the relational features, right? Like Dynamo works really well for serverless. It's connection, no connection limits,

no cold start type things. But then was built for the scale. So it had to take out all these features that people like from relational databases. And it just happened to work with serverless stuff. And then it's like, finally, something is coming along and saying, this works for serverless stuff,

but still doesn't take away all the things that we like about a relational database. Yeah. What I really like about Dynamo, I liked it 5, 10 years ago. I still like it. Is you pay only for what you use. You pay for the storage you use. You pay for the operations you perform.

And if you perform a lot of operations, it will just scale up. That's really nice. That's what you want from a data store. You want it to just work and you want to pay for just what you use. Yep. Yep. And the underrated thing I think about with Dynamo is just the forcing you to sort of use an index or the primary key is there aren't any surprises down the road when things scale. I've liked that.

I wish that there's a, oh man, I can't remember his name. There's a guy that worked at Facebook, and now he has a different company. And he tweeted about relational databases. And he was saying it'd be awesome if you could have almost a strict mode with a relational database where you have to specify the index you're going to use for it

so that you know you don't have these larger scans or things like that. Just so we would identify those queries that are going to blow up at some point. So I like that aspect of Dynamo as well. So we are solving this through the traditional way, which is separate tooling. We have the benefit that we are the layer in your application

where you interact with the database. So that makes it a little bit easier for us. But we have this optimized tool that looks at all of your queries and will identify bad patterns like this. Right now, it will give you a recommendation. So you should really do this. But we want to do this other thing where you can set policies

for the kind of queries you want to support. And a policy could absolutely be only do another table scans, only do index lookup, this kind of thing. Index, yep. Yep, that's pretty cool. It's cool when you can really have control of that layer, like when you're right in between the actual application code and the database where you can see those insights, see what the database is doing, instrument all that stuff and figure out how can I improve this in certain ways. Yeah, good stuff.

So anyway, tell me about Prisma Postgres. Again, we talked about it being like, in one sense, Postgres is like the most commoditized thing on the planet, but in another sense, like this is a very different offering from most things that are out there. So tell me about like how Prisma Postgres works. Postgres is still stuck in the 90s.

So Postgres hosting is stuck in the 90s, right? You need to buy a box and then you pay for that box every month. And it's a very simple mental model. You pay $50, $200 a month, and then you have a server with four CPUs and eight gigabytes of memory or whatever it is. And you can go and look at those metrics and see are you getting close to the limit? Should you think about upgrading?

And it works really well when you're deploying a single application. Maybe you have relatively steady workloads. It does not work so well if you're trying to give all of your developers It does not work so well if you're trying to give all of your developers preview branches. It does not work so well if you are vibe coding in your application every weekend and need databases all over the place. Then you need to do capacity planning for all of these databases. Who wants to do that? That's a mess. So what we wanted is something that is very similar to the Dynamo experience, which is you can create a Dynamo database and you do not pay for it. You put stuff in it or you pay for that stuff, you query it, you pay for those queries.

So there are a few things we are doing on a technical level to make that possible. We can talk about those, but really that's the goal we set out for ourselves. Okay, we're gonna go and build this database everybody wants us to do. What do we do differently? We want to be able to just create hundreds of thousands of databases, not worry about

it, have them scale automatically. Gotcha. And so those are like the initial goals. Hey, be able to create these databases, create them quickly, scale up and down quickly, and sort of usage-based costing. I would say, like, hey, true serverless database type stuff, which we sort of like, people have tried in different ways to get partially, you know, offer some of these things or in different ways, but there's often like some caveats

and things like that. So given that, I guess, tell me about the technical things that, like, given those high-level goals, like, what were the technical things that y'all had to do to make this work? So there are a few things to talk about and the first one is the cost structure. A challenge with relational databases and the kind of queries you can do against them is that a query can be really cheap, like a point lookup at an index that returns almost no data. It could be extremely expensive.

A full table scan, yeah, with aggregations or whatever. It could be many orders of magnitude more expensive than a regular query. So some other host databases, they have tried to figure out how to deal with this. Can they have a pricing model that kind of captures that? And maybe you can charge for rows scanned, the time it takes, or something like that. And the approach we've taken is, let's see if we can reduce our cost by so much that we can just charge a flat fee per query and have that work out. So that's the approach we're taking.

We'll have to see how well that actually works in practice. For now, we're happy with the early results. So how do we reduce cost a lot? The first decision we made was, let's move outside the AWS ecosystem. Because over the last 10 years, computers, servers have gotten just incredibly cheap AWS ecosystem. Because over the last 10 years, computers, servers has gotten just incredibly

cheap compared to what they were when AWS started. And AWS has had some cost reductions. They had a lot of cost reductions in the beginning, but the last five, 10 years, not so much. So AWS is actually extremely expensive compared to if you just go and buy and rack your own servers. Yeah, I totally agree. So then I guess like where are you running this? We are at the moment just renting space in a colo facility because we are relatively early scale. And as we scale up, we'll be building this out.

Gotcha. And so are you like run just you're yeah, you're doing a colo, you're running all your own stuff in it. You're running, I don't know, Kubernetes on it to like schedule all these little instances and there's no Kubernetes. No Kubernetes. Okay. Tell Kubernetes, okay. Tell me about Unicurdles.

I read about Unicurdles as part of this thing. How do Unicurdles work? How is it different than maybe the container-based vision I have for everything else? How do you do it? What's going on there? So that's the other decision we made. We want to be able to run millions of databases

on a single bare-metal server. And how do you do that? Well, you do not have the running containers managed by Kubernetes. That is simply too slow and too resource, too much resource overhead. So what we're doing instead, we are using a modified version of Firecracker to run these micro VMs. And inside a Firecracker micro VM, we run a unicolonel. So let's talk a bit about what a unicolonel is.

Unicolonel is an idea that has been around for a long time. I remember looking at it back in university. I never really thought it would actually turn into something real. But then I found this company from Germany, Unicraft, that has made it real. So the idea of a Unikernel is that you take an operating system, a single program, you kind of plot them together and you compile that into one unit. So the general idea of tree shaking an application, you're left with only what you need. And here you do that not just with the application, but also with the operating system beneath.

So instead of having a full Alpine Linux or something, you keep only the tiniest bits from that operating system that you need to run the application. Yeah. OK. OK, so you basically have this unicorn that's like the Postgres engine and enough of the, I don't know, IOU ring or whatever sort of IOU stuff

and that stuff that it needs, and everything else is gone. And this is just like the smallest image. How big is that image maybe compared to, like, hey, if you're running Docker, or sorry, Postgres within like an Alpine Linux Docker image or something like that? Postgres is actually pretty difficult to kind of compress. So it uses a more universal image.

And I think we're about half the size of what you would think of with an Alpine image. Over time, that can come down. But the more important aspect is that all the stuff that used to be at the operating system layer is overhead. And it's there because you need to have permission checking, user management, file system safety. And when you have a single operating system running, you don't need any of that. So that means Postgres running on this uni-kernel can access, memory can access the disk directly.

It doesn't need to go into the kernel and wait for a bunch of checks and then get the data back. So ordinary I-O operations are faster this way. Interesting. OK, did you have to make many changes to Postgres itself to make it compatible with this? Or does that Unicraft type stuff just handle that as part of that compilation step? That's a Unicraft type stuff, just handle that as part of that compilation step.

That's a Unicraft thing. So Unicraft is an open source system for compiling Unicolonels essentially. So you can just go download this thing, it's a CLI that'll do that. You can create a Unicolonel image, you can run it, and all the work they're doing is creating this Unicolonel operating system that can then be compiled with your application. And all the work they're doing is creating this unicolonel operating system that can then be compiled with your application. So all of the compatibility work really is going into that. It is not modifying the Postgres application.

Yep, gotcha. Okay. And then what about, okay, so let's just talk about this at a bigger level. If I spin up a Prisma Postgres instance, am I going to be on a single instance on this, like in your colo facility, like, hey, there's gonna be, I'm on this instance somewhere,

probably with other tenants as well, but like all my unicornals are gonna be there, all my storage on one instance? So we treat individual databases as separate entities. So you create an account with Prisma, you can go and create a hundred databases. They'll end up on different bare middle servers. They have no relationship to each other.

So one way you can do multi-tenancies, you can say here's a security boundary and we are gonna spend a lot of resources maintaining that one and we put all of your resources inside that security boundary. That's not what we do. We treat every single database as an independent entity that is completely isolated from the rest of the world. So when I schedule a database, you schedule a database,

they just get tossed into the pool. They live next to each other. And to make that work, of course, we need an Ingress routing layer that can find your database. And we're using our existing Accelerate product for that. Accelerate is this proxy that sits in between your application and the database, and it does routing. And now it also routes to prison postgres databases. Gotcha, gotcha.

Okay, but then the database I have, it'll be on one machine. So like one thing I was worried about is just like, you know, if you're spinning up all these compute instances, what about just like memory buffers and things like that are loading? But different unikernels can share the same memory for a given database? Is that like if I spin up a new, if I make a query that

has to spin up a new unikernel to execute this query, it's not like it has to go to disk for every single read. It can use existing memory buffers for my database instance on that same machine. So when you have a database, you have only one unicolonel image running with that database. So many requests come in. They all go to the same.

We can dynamically change the allocated CPU and memory. It's a little tricky with memory in Postgres because it really does not like memory to be changed underneath it without a restart. We really do not want to wait for Postgres to restart. So we're doing some trickery to make that work. But all of your requests go to a single virtual machine that runs this Unicolonel. Yeah. Okay. That's interesting.

Okay. What's been your experience, I guess, building on in this CO little facility compared to the public cloud. I know you said economics are much better, but just like, what has that experience been like? Has that been good? Has it been hard? I guess, what's that been like? It's not been a challenge at all, really.

The biggest issue is a thing you kind of take for granted when you work with AWS is you can just hit their API, get an instance and it'll be there. We know from experience that if you ask for a lot of them, sometimes they'll say, we're out, please try again a little bit. But if you go and provision your own hardware, well, you need to buy it and put it in there. It takes a while. If you rent servers from someone, they might list them, but then they are not actually there. It will be there next week maybe if you ask for it. So just the speed is slower and that means there's some capacity planning we'll have to do. It's pretty easy for us because we have one kind of workload that is the Prisma Postgres

offering. We are like an enterprise that are doing all kinds of weird internal applications and trying to figure scheduling out. We have one kind of application, one kind of workload, and they kind of behave the same, and we can instrument it really well. Yep, yep. Has it been hard, I guess, to build the team DNA to have, I mean, now you have these hosted offerings, which you've had now for a while, Accelerate,

and Optimize, and things like that. But also it's like, hey, on one end you're building a library, a very advanced TypeScript library, which requires like a certain set of skills. And the other one you're doing a database hosting service. It's like, man, that's a tough thing to jam together. Hasn't been hard to build that team and DNA? It has been really hard and much harder than I anticipated.

It was part of our initial strategy when we pivoted from GraphQL It has been really hard and much harder than I anticipated. It was part of our initial strategy when we pivoted from GraphQL to Prisma all these years ago. And I did not anticipate how hard it would be to have these two different streams in a relatively small company that are supposed to support each other, but really also have their own life. We want Prisma ORM to continue to be the best ORM. We want it to continue to grow in adoption. So you need to really have full on dedication to that thing. And also I need to have this cloud product that really works, can never go down, that ships in a completely different way from the ORM.

And I need the ORM to fully support that thing. It's been really difficult to manage, yes. away from the ORM and I need the ORM to fully support that thing. It's been really difficult to manage. Has one of those aspects been harder or is it just like the integration between those has been the difficult part? I think the most challenging thing is that they're just two completely different ways of working. The ORM is now a very mature product. I think we found that half of the Fortune 2000 companies are using the Prisma ORM in some capacity. That means we have serious people and serious companies that depend on this thing, so we cannot mess it up. That has been the case for a

number of years now. That means we do very fixed cadence for releases every three weeks as a new release. They are all minor releases. You can upgrade with no problem. We'll never break anything. Once or twice a year we'll do a major release. There can be breaking changes. They'll be well documented. There'll be an upgrade guide. And then this cloud product is completely different. It's very new. It's a lot of excited people who are using it. They want new features.

They want us to catch up to the missing functionality. They want us to move a little faster. And also it's cloud products, but it ships all the time. But also if you ship a bug, you break stuff right now for people who are using it. In their data, in the most important part, you know? Yeah. So, yeah, interesting. You You mentioned missing features and stuff. What

are the things that people are really clamoring for that you all are working on? One thing we get asked for a lot is you can connect to Prisma Postgres to Accelerate, which you can only do through the Prisma ORM, which is fine for most things. But if you would like to use TablePlus to connect to your database, currently you cannot connect to Prisma Postgres because we do not support direct TCP connections. So we're working on that. In addition to the HTTP based ingress layer through Accelerate,

we'll have traditional TCP ingress. And we want that to not be a side thing. It needs to work well. It needs to be a high performance, good uptime. Again, we talked about how the Postgres hosting is like a crowded space. Is there like a certain, like what, who are the users or use cases or applications that you're

like, hey, Prisma Postgres is right for you, or maybe certain ones that are like, hey, you know, maybe not right for you given your trade-offs and needs. Who are you focusing on? So we want Prisma Postgres to be right for everybody below a certain level. If you're somebody who wouldn't think twice about spending $2,000 or $5,000 a month on planet scale, Prisma Postgres is not right for you right now. But if you are somewhere below that,

if you have multiple different databases, if you like Postgres, if you are a Prisma user, certainly, Prisma Postgres is probably a good option for you. If you're currently using a host of database where it's annoying that there are these old school kind of fragile things where you would like to just create more of them and only pay for them when you use them, definitely check out Christmas Postgres. Yep, absolutely. Do you have, you mentioned Co-O, do you have like one Co-O facility?

Do you have a couple different ones? What's your plan there? So that's the other thing people are asking for. Right now we are in three locations. One co-op facility, do you have a couple different ones? That's the other thing we were asking for. Right now we are in three locations. US, East, EU, and Asia. We need to be in more places. We need to be in all the places. We are picking these locations strategically to be very close to AWS data centers. And AWS region has multiple availability zones and there's some network latency between those. The data centers we pick,

they are in between these availability zones. So we can usually get latency to an AWS region that is the same or less than between availability zones. Okay, that was gonna be one of my questions too, is just thinking about, yeah, are you seeing, will you see latency like that? Like if you're running an AWS, but it's not crazy. It's like going cross AZ rather than going, you know,

cross-regen or something like that. Yeah, it's not crazy. And there are ways for us to optimize it. AWS has this ability for you to run a fiber pair directly between their locations and these colo facilities. So when we get a little bit further with this build out, that's what we'll be doing. Yeah, okay. You mentioned Cloudflare earlier too.

Are you able to see, or maybe just from talking to customers, is it still heavily dominated by AWS, or are you seeing more people running applications where they're reaching out to a database on Cloudflare or something else? We see the majority of our traffic from Cloudflare. No, sorry, from AWS. AWS is the majority. And we aren't really sure, but from talking to people, I suspect the majority is from services like the Netlify,

where it's really serverless functions. It's some fully managed thing. Gotcha. Yeah. So it's people that aren't running a lot of infrastructure themselves using more managed services and things like that. Very cool. things like that. Very cool. Y'all released this, I think five, six months ago, was like the initial one. It's been GA now for a little bit. I guess like what are the biggest surprises

from running it for five or six months now? It turns out that when you build what people want, you get a lot of people using it. So that's been a really positive surprise. Accelerate is a product we have had out for two years before that. want, you get a lot of people using it. right. Wow. Okay. We're really happy about that. We see the growth numbers are good. We see a lot of people kind of toying with it, playing around, deploying a bunch of apps. That's really cool. But we also see steady state production workloads. So the uptake has been faster than I had expected. Yep. Cool. What about the operational

aspects? Has that been, you that been sort of what you expected? Has it been harder, easier, anything like that? It's been about what I expected, I would say. We're having to build a bunch of tooling to support it. We work with the Unicraft team. They've been phenomenal. If you want to really nerd out with a team that is deep in the operating system stuff, get them on.

They are a fun bunch. Right now, we have this relationship, but we have a shared Slack channel. They help us with a bunch of things. Their product is very early. So when we need to do new things, it often involves working with them. Yeah, OK. And you said it's an open source project, but then there's some company around it providing support and things like that? Yes, that's right.

Okay, cool. Do you think we're going to see more unicorn adoption going forward? So it's a good question. And there's really two ways to build multi-tenant systems. Either you can do it at the system level, using containers or micro VMs, potentially using Unicornals, or you can build it at the application level. So if you have a traditional SaaS application, that thing handles multi-tenancy at the application level. Some people have done the same thing with Postgres,

modified Postgres a little bit, and be able to do multi-tenancy in the database. When we were running GraphQL all those years ago on MySQL, we just had a separate schema for each database. And that worked well until we got to half a million or something, and there was some overhead we ran into. But it is really, really powerful to be able to do multi-tenancy on the system level. And doing micro VMs and unique kernels just enables you to do that a lot more efficiently.

So I think we're going to see a lot more of this. And I think we'll see some large players, maybe even AWS, adopt this. Interesting. Yeah. Yeah. That'll be fun. Yeah, the whole firecracker thing,

which you all said you're using in a modified way, it's been interesting to see that pick up in different places, like Fly doing some stuff with it, and y'all, and just different things. And just like, yeah, it's been interesting to see some of those evolutions that are happening. I want to talk about the ORM a little bit. First of all, is it tiring to support a super popular open source library?

First of all, so many needs, can't break anything, but people always want more too. What has it been like to be with a very popular library for a long time that's used for a lot of things? Yeah. I mean, if you talk to open source maintainers, they are always on the verge of burnout because it's just a fangless thing. We're lucky enough to be a well-funded company doing this thing. So we can hire people, pay them well to work on this thing. And that means we can deal with all of that. It has been difficult for us to kind of adjust the way we operate,

to where we are in the maturity of the product and of our users. So in the early days, it was really important to move fast, to show that we're doing new features the same way that that bun is an exciting project now that is always like doing new things because it's early days they're trying to capture the attention and imagination of people. We did that in the early days but then at some point that started to not really work. It started to become counterproductive. People want the opposite. They want the stability. So transitioning the way we operate and accepting that some of your early users who liked you for that mentality of just doing stuff and breaking things,

they're going to grumble when you become a little bit more boring and corporate. And that shows up in social media, it shows up in GitHub issues, and it is exhausting. Yeah, I know. It's a thankless job. You hear good things, people say good things all the time and stuff, but you also see the grumbling too and that sticks with you more. I just remember working on serverless too and seeing some of that stuff as well. It's hard to be open source like that.

It's like what Bezos says about customers being delightfully dissatisfied all the time, no matter what happens. They always want more. And it's fun to do it, but it's also tiring for sure. Yeah. We had a new engineering manager join the ORM team half a year ago, Will, and he put out a manifesto for how we want to be operating. If you go and search for the Presma ORM manifesto, you'll find it. And that has really helped us

tune in to this near reality we're in. We've gone out and closed just a whole bunch of old issues, pull requests that we never really got around to reviewing or merging. Just clean things up and that has made the team more productive. Yeah, sometimes you need that where it's like, hey, you're also just not reiterating the same story in every pull request or issue or things like that. You can tell people, hey, here's our guidelines and this sort of fits outside the guidelines.

And if you need a different library, you need a different library, but this is what we're doing. And we think this works for a lot of people. If it doesn't work for you, it doesn't work for you. But just that clarity, and both for the users, but also for the team of just understanding what are we prioritizing and things like that.

Absolutely. And they also like early decisions made in a library like Prisma that were right at the time but at some point you realize they're no longer right and you need to just you need to put in the hard work to move on so you can stop thinking about it. And for us one of those things has come up recently is the fact that we have this Rust query engine. So when we first built Presmahorium, our idea was, well, TypeScript is clearly a thing. It's being used on the server, but there's also Java and Python and all this other stuff. And eventually we want to go and serve teams and enterprises. It has all this existing stuff they need to maintain.

So we need to be able to work with these language ecosystems. So we put all of our work into building the query engine in Rust so that it could be reused in multiple different language ecosystems. For a long time, we had the TypeScript one, the community maintained one for Go, for Python, for other languages. But the reality is nobody really used Prisma in these other language ecosystems. There's like less than 1% of all of our users.

And the reason for that is Prisma is awesome. Prisma is cool because it takes advantage of the unique capabilities of TypeScript. TypeScript is just a unique language that way. If you go and look at Java, Python, any other language, they can't do the kind of things TypeScript can do. So therefore, we can't really provide something that is that much more compelling than existing toolings in those ecosystems. So we made the decision we're going to focus entirely on TypeScript. And that means the decision that follows from that is let's get rid of this Rust thing. Rust is cool and all, but it's also this 10 megabyte binary you need to download and it's

annoying. It has all kinds of complexities. It's really difficult to contribute to the code. So the team has done heroic work over the last six months to kind of take bits and pieces of that, turn it into Wasm so we can keep using those, but then rewrite the other stuff in Rust. And I'm really excited for that work. The most recent release last week was the first bit of that. Interesting. Without the Rust binary? the first bit of that. Interesting, without the Rust binary? Yes. Interesting, wow, that's close.

Yep, so do you have like a timeline you're sort of aiming for for cutting a release with that where that is the default? Yes, but not a public timeline. So I think this year, that's what I know. Yep, for sure. Oh man, yeah. So was that part of the ORM manifesto?

It was just like, hey, we're TypeScript only now. We're getting rid of Rust. Yep. Okay. Just that clearly. Let's simplify. Let's get it cleaned up. We really want to get to a point where the community can just contribute functionality in a normal TypeScript code base

and not having to deal with the Rust toolchain and compilations and all this stuff. Yep. Yep. One thing that I thought was interesting, just looking at the, I was looking at the blog post you put out about that is like the actual, the new query engine is actually faster in most respects, not all of them. There was like one or two that was, that were slower, which is surprising me. Cause everyone thinks, you know, rest super fast. Is that just because of like the overhead of

communication between two processes or like what sort of or just like understanding or like what's driving some of the speed ups there? It's the it's the serialization and deserialization overhead. The way if you look at a queries lifetime in this old system with the Rust query engine, a query comes in, then it gets transformed into some internal representation. It goes to the query engine. The query engine makes the direct request to the database.

That happens in Rust. It gets the data back. The data then has to do a bunch of stuff in Rust, which is fast, because Rust is genuinely fast. But then it has to be serialized and put back out to the TypeScript layer. The TypeScript layer does some more stuff and gives it to the application. That just takes time. There are a few kinds of queries where that speed up in the Rust grow engine is worth it, but most of the time it is not. It's a penalty.

Yeah. Okay. Interesting. Well, that'd be fun. That's exciting to come out. One more thing. I know you all support all these different databases, Postgres, MySQL, SQLite, and Mongo. Does Mongo add a bunch of problems like not being a relational database, or is it not that hard to do that? Well, it adds complexity, but it's also not that hard.

The way people mostly use Mongo is it looks a little bit like a relational database. And that's the pattern we support within Prisma. You have your tables, you can do relations between the tables, you can follow those relations. And Mongo has gotten pretty good at doing these more relational style queries over the last few years. Yeah, I always tell people like Mongo is almost a relational database. Like, it's got a very smart query planner, you know. It is, like, totally different.

Like, it feels weird to group Dynamo and Cassandra with Mongo as no SQL, because, like, Mongo is in a separate world, and, like, given the existence of the query planner, it's a lot closer to Postgres and MySQL, you know, without some of the typing stuff, but yeah. Mungo is good. Yeah, it's good stuff. So, all right, cool. Last thing I want to talk about is just like your life as a CEO and some of that stuff.

So some business, some of that, I guess like, first of all, do you still get to develop very much? Oh, for quite a while, the team has asked me kindly to not mess with their stuff. But I also found that it's useful to once in a while just dive in, be with the team, sit down, work for a few days. And when I do that, I try to be a friendly coworker who just follows, more of a code monkey. I enjoy that. It also helps me understand some of the challenges the team have,

suggest things we could improve. And then I do a lot of prototypes. So, So, Crispin Postgres, we built it in a remarkable short amount of time. From the team started to the GA launch was six months. I think that's incredible. But I've been thinking about it for a few years. So I built an initial prototype of this thing, not using Unicornos, but using Firecracker, kind of just convincing myself that this could work and would be a good idea. So those are the kind of things I do, where I don't risk destroying stuff that the teams own.

Yep. Yep, for sure. How do you think about AI usage at Prisma? This week or last week, we saw Toby at Shopify saying, hey, you need to be thinking AI first on all of this stuff. How do you think about given that both the ORM, super technical and deep into TypeScript, running a database service, Unicurl, there's not a lot of prior art for some of those things to where, hey, if I'm building a B2B SaaS or something like that,

that's like, hey, I can honestly generate a lot of this stuff, I guess. Give me some UI screens and yeah. Yeah, yeah, how do you think about? Spit out some tailwind. Yeah, exactly, that's like all I do is like, tell it to spit out some tailwind and I'm good to go. How do you think about that?

How are your teams thinking about that? So it's fascinating, as an industry, and I'm good to go. just a few years ago. But also it's like not quite there yet and it's really frustrating. Every few months I take a day and I try to do some vibe coding and it feels really good for the first hour and then it feels really bad because nothing works anymore. But used carefully, cursor, windsurf, get a copilot, whatever you want to use. Really helpful. The tap completion, I personally use windsurf and I love it.

Just tap, tap, tap. And it keeps my context in mind. I know I did this thing recently, so maybe I need to do it again. Super helpful. So three months ago, we asked all the teams what their kind of attitude towards AI was, and we got mostly lukewarm feedback.

And now, two weeks ago, we did the same thing and everybody was kind of excited about it and used it for something. So what we're doing now is we have an AI tooling budget. We just ask people to use whatever they want, put it on the company credit card. If they find something that works well, share it with the team. And I think that's the right approach right now because it's all kind of crappy and it all moves really fast

and there's no reason in having a top-down mandate on the AI tool to use. Yeah, yeah. Have you seen any, I don't wanna say like, like increases or just changes in Prisma usage now that like vibe coding has become more popular, given that Prisma is so popular, tons of examples out there,

it's like a really good, it's a well-typed thing, so which helps with a lot of this coding and like vibe coding type stuff. Like, are you seeing any changes in usage there as this continues to take off? It's difficult because we are this open source library. We don't really get to understand

what people are doing with it. We have telemetry that you can opt out of. The telemetry only runs in development, only on your developer machine. And sometimes we can see some patterns that are really interesting, where it really looks like some AI developer tool is using this particular version of Prisma and running those three commands in a row and all of a sudden there's like a lot of them happening.

So that's interesting. But other than that, we don't really know much. We are talking to these AI app building platforms, these kind of platforms, because they have the need that Prism Postgres is uniquely created to solve, which is create lots and lots of these applications. Super cheap databases. You should base, but otherwise not going to be hanging around. Yeah, yeah. Good stuff there. I know MCP has been huge, and you all release some MCP stuff. How do you all think about MCP?

MCP is still early days in my mind. But you need to do this JSON config janky thing. What is that? I think MCP is going to be really cool. Our MCP server enable you to configure a cursor or whatever you're using to just automatically work with Prism and Postgres. So it can go and create databases for you, it can migrate them. You probably need to watch it a little bit so it doesn't destroy everything. But if you're just developing, it's really nice.

The big issue is you need to discover this thing. You need to install that thing. And that's just really weird. What you need is a marketplace kind of situation where Cursor will suggest to you that, hey, it looks like you need a Postgres database. Go and use this NTP server. So that's what we're talking to these IDE companies about. I think that will happen in the next few months. Yep, yep. Interesting. Yeah, it's been interesting to see I haven't like done a ton with it because like, honestly, you know, just like the Prisma CLIs and stuff like that work pretty well to do all this stuff. And it's or just like all that it's like,

I don't need to be updating records or doing migrations that way when I have like the, like the standard ways that have already been optimized to be pretty easy and clear and debuggable. So yeah, I'm still a little nervous on MCPs generally. It'll be interesting to see, you know, I mean, as we get into this more like agentic world, like probably going to be useful, but for now I'm still nervous about them. Yeah as a software tooling company what I'm really excited about is it does seem like we are going to see a tenfold increase in the number of people doing some version of software development. I think that's going to happen over the next few years. The same way when we went from traditional photography to digital photography and computers. People

used to have to have like dark rooms in the basement or something and very few people bothered with that stuff. But when you could edit family photos on the computer, lots of people became part-time professional photo editors. The software industry is going through that same transition, right? And we don't think about it like that because we all the nerds in our dark rooms editing the photos right now and we we love this industry. We make a lot of money. We know how everything works But there's a whole world out there that is right now being enabled to do the same thing without all the janky stuff that we have put up with for the last decades

Yep. Yep, yep. I know it's hard for me to imagine, I totally see what you're saying. The hard thing for me to imagine is, what is our world gonna be like with a hundred times as much software? Like not that, and I'm not at the place where I'm like, oh, we have exactly as much software as we need right now,

but just like, what is it gonna look like with that much more, it's hard for me to even picture. I think that's like the wild stuff. But I don't want to sound like the guy that in like 1900 that's like everything that's been invented has already been invented, you know? But yeah, it's just hard to read a picture. I live in Berlin, Germany. So for once we might get rid of effects machines. That would be really nice. If you go out there in the real world and really look at it, you realize that it's just so much software that is not implemented, it's not written, that is missing. People do all this crazy ass stuff, like they use fax machines. What is going on? Yep, I went to Japan last year and I was

talking to some people there and they're like, yeah, a lot of stuff is still faxed. And I'm like, wow, are you serious? Yeah. Or actually, my brother-in-law, he works in the medical field and it's amazing how much they fax records back and forth. Even in the world of EMRs, they're still faxing records and then scanning them into the EMR. It's like, why? That is wild. Yeah. So, but that's because software is so complex and so expensive. So there's the demand for software far outpaces the supply of software. And it looks like that's about to change. And that's exciting. Supply is going to get a lot cheaper, which is good.

It'll be fun. Yeah, just disconcerting because it's like, man, what I've been doing for the last 10 years is totally going to change. But it's also a fun time, too, to see all this happening. Alex, what's going on in your world? Oh, man. So it's a fun time to see all this happening. Alex, what's going on in your world? Oh, man. I've been doing independent consulting now for like five years. And it's like change in different ways.

A lot of Dynamo stuff for a while, a lot of teaching and training in that. I still do a lot of that. But also, I miss doing some app development. So I've been doing more app development back into that, like the last two years, at least half time doing that. So that's fun. It's been fun, you know, playing with, you know, I haven't tried windsurf,

but I've been a cursor guy for the last six to 12 months. And I think that's pretty good. So it's been fun just like doing that. And the thing I like is just like, I'm like traditionally like a backend guy and not very good at front end at all. But now just being able to like do that enough to where it's like you can do, you know, it's a basic rate, but like, yeah, you can do like a full stack thing and just like, it's, it's a lot more fun to just be like doing that. So I'm, I'm really enjoying that part of it. Like trying to get my kids

involved. I like my oldest kid is 12 and I got 10, eight. Yeah. Like trying to get my kids involved. Like my oldest kid is 12 and I got 10, eight. Yeah, like trying to get them thinking about stuff like, hey, let's go build something or things like that. It's hard to find the time, but like just all that sort of stuff. It's a fun time to be a software developer, I think. Have you tried a bold or lovable? I haven't, have you?

Like I know you talked about it in like integrations and stuff, I guess like Give me the pitch for them. So my wife is a PM, not a software developer. A few years ago, I tried to get her into TypeScript stuff, that never worked. But she wanted my help to build a web app. I was like, just go use one of those things. So she sat down with Bald, I think, and got really, really far. Could build amazing things. The integration with the database was a little complicated because there was some super base and some overflow and copy credentials, whatever.

But other than that, she could just talk to the thing, look at what it did right there in the browser, have it change all kinds of things. Super cool. You should try this with your kids. I think that's the way to go. I really should. Yeah. I see the people making games and stuff like that.

I'm like, oh, I should just sit down with the kids and do something like that or that. Or honestly, you talk about the apps that your wife wants. My wife has been saying, our kids' school, they have to like listen to all these like video or songs every week, like some recitation type stuff. And she's like, it's so janky. I have to go on my computer and do it. I wish someone would just like make a mobile app that was like so much easier.

And she's like, you should do that. I'm like, yeah, I know. I need to, I need to, I'm like, yeah, just give me a week off of this stuff. And yeah, I want to go do that. So I should check out BOL. That'd be fun to do with the kids. Can you like, I guess, eject,

like once you have like a good core, can you eject and get that in your IDE and take it from there? Or is it like always in the Bolt level ecosystem or what's that look like? You can eject, I think they both connect to GitHub so you can just take complete control. And at some point you'll want to do that

because it gets really frustrating to try to just yell at the thing, and it continues to make it. What they always do is, you build a relatively sophisticated thing, and then you want a new thing, and it breaks the old thing. And then you try to fix the old thing, and oh, and it's just this Jenga tower. Yep, yep.

I've noticed it's like, you have some of that software engineering background, and you're like, okay, implement this database access pattern. Now implement the endpoint to do it. Now implement the front-end code to access that endpoint. Now implement the front-end feature. If you can walk it through and make sure each step is fine, rather than just saying do this whole thing,

because then it's confused, it's going off everywhere. But if you have the patterns in your application and you like make sure you're going sort of step by step, yeah, it's like amazing how much faster it can be for that sort of stuff. So yeah, it's been fun. I'm in digging it, so. But Sorin, thank you for coming on.

This is great. I've been paying attention to Prisma for a while. Like I think they're a fun company and yeah, great to get. It's fun to see your journey from GraphQL to Prisma for a while. I think they're a fun company and yeah, great to get. It's fun to see your journey from GraphQL to Prisma ORM and now all these hosted services as well. So I guess if people wanna find out more about either you or Prisma, where should they go?

So Prisma, www.prisma.io. If you want to talk to me, go to Twitter, send me a DM. I'm always open to talk to people. Don't send me emails, I don't read emails. Go to Twitter, send me a DM. I'm always open to talk to people. Don't send me emails, I don't read emails. Go to Twitter. We have an active Discord, we are very active in GitHub. If you go and open a discussion, there'll be somebody talking to you within an hour probably.

Just go build some stuff. Yep, exactly, that's the way to do it. Well, I think Prisma is well positioned, you know, for this new AI world with some of the history built up and all the type stuff like, yeah, it's good stuff. So hey, Soren, thanks for coming on today and best of luck going forward. Thanks for having me, Alex. This has been fun. Cool.