Prisma was one of the first dev tools I ever used and today, I'm interviewing Soren, the co founder and CEO of Prisma. How was it that Prisma built one of the biggest communities in the whole of dev tools and got tons of developers including me to use it? How have they prioritized building the right features especially when they have such a big community? And why did Prisma launch their own database product? Finally, how has lowering their infrastructure cost helped them to launch a much simpler pricing model?
Enjoy. I was actually, for this episode, like, kind of because I knew I'd used Prisma, like, back in the day, honestly, like Yes. Really early on in my journey. And I was going back, and I was, like, figured out the exact course that I did, which was this Andrew Meade course, kinda introduced me to Prisma while I was doing, you know, learning about Node. Js and and all that sort of good stuff.
And I I could imagine that was, like, a big driver of, like, adoption was when you get into because it was, like, pre had, like, a 100000 students or something, I would imagine. Yeah. Was it was it something that you kind of, like, intentionally, like, planned, or was that just kind of chance?
I remember Andrew very well, and we worked we worked directly with him, supported him. I'm not sure if he found us, so we found him. I suspect he found us. But this strategy of working with educators, or maybe you would call them influencers today, that was very deliberate. That was our main growth strategy in the early days.
So we worked with people like Andrew. We worked with upcoming frameworks. Redwood JS, for example, is bundling Prisma. That's because we worked with them early early on, sold them on this future promise of what Prisma would be and got them convinced to to include it by default. And a lot of our early adoption was really was really based on this. People finding, getting excited about, the possibilities of Brisbane and then talking about it. We would help that a lot.
Yeah. And how how does it, like, translate? Like, because I think when I was first you know, this was, like, 6 odd years ago, and I, you know, I was a massive noob. You know? I did have a programming job, but I was, like, very much not, like, in any way, like, decision maker and stuff like that. And, like Yes. Did how does it translate when, you know, you're kind of working with the kind of, like, education you know, there's really early people in their career.
It's a it's a long term strategy. Right? What you're asking is, what is the return on investment for this kind of thing? Yeah. Yeah.
And there's no doubt it's a long term strategy. Today, we're speaking, and and you used Prisma, like, 6 years ago, and that has value. It's very difficult to to quantify that value, but it has real value because there are probably millions, at least hundreds of thousands of people like you who use Prisma a long time ago and and have some amount of affinity to our products, to our brand, who understand what we stand for. It has huge value, and that's really how we looked at at our investment in, you could call it, marketing or community engagement early on. It was, what can we do now that has maximum impact 3, 5, even 10 years in the future?
This episode is brought to you by WorkOS. If you're building a dev tool, at some point, your customers are gonna start asking you for enterprise features. WorkOS offers you single sign on, skin provisioning, and audit logs out the box. WorkOS is trusted by Perplexity and Vercel as well as Workbrew, a home brew management startup that I recently interviewed. I just told Mike that WorkOS is the sponsor and this is what Mike said.
Yeah. So WorkOS isn't paying me any money for this. I I pay WorkOS money for this, but WorkOS is like one of the best developer tools I've, like, ever used. It's it's the documentation and the experience with building with them is so, so good. Like, I initially was almost like, okay.
This seems expensive, but then I built an integration with them in about 20 minutes. So I had spent 2 days banging my head off the wall trying to build it directly with Okta. And then with Workhorse, I then have, like, many, many SSO providers, like, supported instead of just 1. So, yeah, like, for me, Workhorse is one of the nicest developer experiences I've encountered in the last like 5 years probably. And it's so surprising because a bunch of the developer team are ex GitHub and therefore are very good at their job.
Go to workos.com to learn more. Yeah. That makes total sense. And I remember when we got connected on Twitter, I was, like, really excited. Like, I know Prisma. Like, I this was one of the things one of my first, you know, tools I ever used. Yeah.
So the other thing we did very early on was we really needed to get the to build some awareness. So we we had this strategy that every month, we wanted to do something that that landed on the on the top of Hacker News. And sometimes it would be very directly related to what we are doing. For example, very early on, we were very much involved with the GraphQL community. So we built various one off projects around GraphQL, and those were wildly popular.
Everybody was trying to figure out what is this GraphQL thing. It's a huge new thing. We want to get involved, but nobody really knows. So by being an entity that consistently put out great stuff around GraphQL again and again and again, we could land on the top of Hacker News. And that means get a whole bunch of developers who are not going to turn into users or customers, but they look at our thing and they see our name.
And the next time, the third time, they're going to recognize they'll be interested again. And over time, that pays off.
Yeah. And it's a pretty big, like, community. I think you have this huge community, I think. Like, it's a lot of people. And was that primarily driven by kind of this, like, strategy around, like, kind of getting top of Hacker News?
So that was the early early days how we really got things bootstrapped. At those times we were looking at, we have 500 users this month. The next month, we have 800 or 2000. Those are really small numbers. Right. And anything we could do to really get the growth curve started was worth it. Now the numbers are much bigger and they are much more driven organically. There's very little we can do to meaningfully impact the growth of Prisma
Interesting.
Apart from, making a really great product that people continue to to love and use.
Yeah. That that's really interesting, actually. How how do you like, when you can't, like, you know, do a thing and then see growth, how, yeah, how do you kind of, measure if you like you're improving things in a sense? You know?
It's hard. It's really hard. That's the truth. So we're looking at we're looking at 2 things. Right? We're looking at a a dev connections team. That's the developer advocates and support people. Then we're looking at our product development. And those are 2 separate things, but they both impacts the growth of the of the Prisma community in separate ways. And both of them are hard to measure.
But we look at the at the work happening in those two departments, and then we try to quantify that. So in in developer connections, a huge focus of ours is to show up where people are. We have about a 1000000 developers who are engaging with with the Prisma ORM every month. That's a lot of people, and they are in many different places. So we we try to show up wherever they are engaged in what they are talking about, make sure they have a positive experience.
If they have a misconception about something, we'd first maybe help correct that misconception. Yeah.
Having this, like, like, really big community, I think it's like it it obviously is amazing in this. The the kind of plus sides to that, like, almost fairly obvious, but I think there's, like, a lot of challenges there as well. Right? When you've got this, like, huge community of lots of people have, like, probably different interests, different things they wanna do with Prisma. What kind of challenges do you, like, see in that?
Well, the the benefit that a startup has is that it's small and nimble. You can make changes quickly. When you have a 1,000,000 developers, 100 of 1000 of large organizations that depend on your software, that stops to be true. If you look at at other ORMs that are less used, they can make changes quickly. They can they can move around.
They can break things, and people don't complain too much because not that many people use them or rely on them for for for large applications that have been in production for a long time, and they maybe don't even have people developing them anymore. They just needed to continue to work. For us, that's very different. We don't want to break things. We want to to make sure that, all of these people relying on Prisma, they can continue to rely on Prisma and upgrade to new versions without having to spend hours and hours fixing things.
So that slows us down. As a company, we want to make changes. We want to to make sure we can we can ride on the new wave. We can we can go where the market goes. But at the same time, we don't want to, upset all of our users because if we if we did that, then we would lose the biggest benefit we have, which is this huge community that is using Prisma that is trusting us.
Yeah. It it just from my own experiences of, like, my really small dev tool I made and, as soon as people start using it, I feel like especially with dev tools, it's like everything is kind of, you know, any things that go wrong are, like, quite unacceptable. And I think it's it's a lot more scary than I think most of a like, if you're just making, like, a cool little, like, mobile app or something that people use, like a social Absolutely. Something. It's like
That's a funny app, it goes away. It doesn't matter.
Yeah. It's like whereas, like, this is something so crucial to their entire business. It's like Yeah. It it's, yeah, it's much more challenging, I think.
It's it's challenging, and and developers have this mindset that we could just do it ourselves. So why why rely on this thing that might be introducing other challenges and might be breaking. Just do our own thing. It's a common challenge in the open source community in particular where the developers have this entitlement around open source projects, getting really rude in in GitHub issues. And as as a company, that's okay.
We can deal with that. Right? Because we have money. We're employing people. We're professionals. But I know for for regular open source projects, that is a huge challenge and it's also burnout with it.
Yeah. Like, if you're not kind of essentially getting paid to some extent from Yes. Either directly or indirectly, it's, like, kind of, yeah, hard to take, I guess.
Yeah. Guess why deal with all of this stuff when when you're not getting paid for it? It doesn't make sense.
Yeah. How so, actually, I was gonna say, so for researching this, I have a friend, who's amazing, Joe Roddy, who was working with you guys for a little bit, I think.
Oh, yeah.
And, so I was getting his help with, kind of questions and stuff. That's great. Yeah. He says hi.
Yeah. We've worked really very closely with Joe. Joe is great.
Yeah. Yeah. Yeah. He's super cool guy. And one of the things that we were talking about was, like, kinda how to, like, prioritize issues and stuff and, like, prioritize the direction, when there are so many directions that you could go and different people with different use cases and stuff like that. How do you think about prioritization?
Oh, that's very difficult. It's the thing that we have we're doing it much better now than we have in the past. The challenge with lots and lots of users is that they all want all kinds of things from you. Right? And they will come and tell you.
The benefit of being an open source project is that GitHub is a very well understood way to kinda take in those requests and prioritize them. We have more than 3,000 open GitHub issues, and it becomes really challenging to manage. Many of those are feature requests that makes a ton of sense. Obviously, we should introduce this feature, and they've been open for 4 years. And it is very clear that that starts to become a frustration with the with the user base because every single one of those is, like, relatively simple.
But because there are so many, they just add up to way more developers than than we can, that we than we can invest. So last month, we we put out what we call the the Prisma ORM manifesto that lays out in in great detail how we are going to prioritize bug reports, speech requests going forward. And it's really very simple. There are 2 inputs into what we're choosing to work on. One is strategic prioritization that we make as a company.
For example, we might say that it is really important that we become the best ORM to to use with AI data to forward back to search and so on. That could be a strategic initiative. But then the majority of the work is directly taken from input from the community. It's literally as simple as going to the GitHub issues, sort by uploads, and then see from the top which ones make sense to work on in the next sprint. So that's what we're doing now.
We've been doing that for for about a year before we put out the manifesto just to make sure that that process really works. And it works amazingly well. It it's, it's an improvement for us, for for engineering teams because they can clearly see what they should be working on, and they know they're working on something that has high impact. And it's it's working for the community, for the customer user base because they have a clear way to go and signal what they think we should work on. Just gonna create an issue or upload an existing one.
And then they can see that we actually go and implement the things that they want, that the community wants. And the new features we put out there are the ones that, have the most impact that most people want. It's so so silly, so simple. We've been doing that for a year, and that has completely changed, I would say, the the tone in the in the general feedback we get on Twitter, social media. There's this feeling that that Prisma is now much more responsive, receptive to community requests, and moving faster.
Yeah. Even though it's not necessarily changed how many issues you're closing or how much work you're doing. It's just the communication around it that, like or maybe people even feel like they have agency and that, like, okay. Well, if it's a really big deal for you, maybe you find a load of other people in the Prisma community that grew
Get your friends to come and and upload. Absolutely. And that works because then we will work on the thing.
Yeah. That's that's so good. I I love it. I love it. I think everyone should have that. And I And
it's it's it's absolutely true. We had we had the team is the the size of the team is the same. It is just that the features we now work on, they they they impact many more people, many more customer users experience. Oh, they implemented a feature that I that I wanted because we are working on the mode the highest impact features.
Yeah. I absolutely love it. I always talk about this, like, analogy that I heard a while back of, like, apparently, the this hotel was having issues with, like, us people complaining about a slow lift. And Yeah. And and you know this one. Right? Like, they I think
they got this one. Yeah. They put a mirror,
and people stopped complaining.
And it's
like because now they
had something to do.
Yeah. And it's like, sometimes it's you think the obvious answer is like, oh, okay. Close more issues. Like, hire 10 x the number of engineers, but actually Install
more lifts. Make the lifts faster. Not what you need. You just need to communicate clearly.
Yeah. Yeah. That's really cool. And, yeah. So one of the other things I wanted to talk about is, I know that, Prisma now is quite different to Prisma when I was using it, 6 years ago, and you've been on kind of this evolution, and I love to hear a lot about
Before we go there before we go there, do you mind, just talking through the story of you finding Prisma, adopting Prisma? What was that experience like?
So this was so I think at the time, you know, I wanted to learn, I I knew a little bit of Node. Js, but I wanted to get better at it. So I, you know, found this course on Udemy, and I think I was building I think I was pretty interested in, like, real time stuff at the time, and I was trying to make, like, a chat application just like as a toy. And I remember, that I was using Prisma with well, yeah, GraphQL. And it I think it was, like, kind of the intermediary.
Right? Like, the kind of, like, layer in between.
Yes.
And I was using the real time stuff to kind of have, like, just, like, okay. If I can type something in one browser tab, and then, like, it pops up in the other one, I was like, oh, this is magic. You know? And so that was kind of what I did, and I think I wrote, like, some like, a little article on it for myself and, like, yeah. That that's kind of what I did, and I don't think I ended up using it in my job directly, but it was a really cool kind of, you know, learning experience.
I think that that's what it that's how I used it from what I remember 6 years ago. So, yeah, my memory is pretty, flaky at this point.
So so what you used back then was either Graphcool or Prisma 1?
I think it was Prisma 1 because when I was doing this research, I don't have memory of Graphcool, and I Okay. Like, I feel like it was Prisma because, yeah, I I really don't think I used graph unless it was, like, under the behind the scenes, I was using GraphQL, and I just didn't really know. But I don't remember seeing, like, GraphQL.
Oh, okay. That makes sense. So so when Prisma started in 2016, we were a back end as a service called GraphQL. We were competing with Firebase, PaaS, or something like this. We we thought that with GraphQL, we could make it back into service that that would scale with you, that would actually work for building real applications.
So that was GraphQL. It was a it hosted database in the GraphQL API that directly talk to the database through security rules that you could implement in the UI. And it was wildly popular. We got about a half a 1000000 applications deployed on this thing in in the span of the year. That's unbelievable.
But what we found is that, our best users, our best customers, they would use GraphQL to implement a prototype, validate that prototype, and then go and allocate a budget for a real engineering team that could build the real product with real technology. And that was obviously a problem for us. We needed to be part of that of that real application that would be able to sustain us as a company over time. So we made this big decision to say GraphQL is obviously an amazing product, but the way it's been put together prevents companies from using it for real things in production. So what is the what is the the most important part from GraphQL that we can then rip out and build as a real technical component that that large engineering teams could rely on?
And that that was this database abstraction that became Prisma, the ORM as we know it. Prisma 1 was a a transition towards that where you still have to run a server that spoke GraphQL internally, but you didn't really see it. And then Prisma 2 was the first real version of of the Prisma ORM as as you know it today. The the API of the Prisma ORM is hugely inspired by GraphQL and and that time of GraphQL. The way you kind of specify the top root and then relations from there is this kind of graph looks very much like writing a GraphQL query.
Mhmm. Yeah. That that makes sense. So it's kind of evolved. You've kind of taken, like, the kind of most useful parts of each, step in the iteration and brought it forward into, like, something a bit. Well, I guess you got smaller and then got bigger sort of thing.
Yes. And now we are slowly building our way back to that original GraphQL addition. The the cloud products we have released, they they use Prisma, the ORM, at the core. But then they build some of that those magical capabilities from, from GraphQL and from Prisma 1 back into our cloud product. So a few years ago, we released Accelerate, which is a global database connection cooler and caching solution.
So if you query database from all over the world, from serverless function, from edge functions, Accelerate helps you cache that data at the edge so users have a good experience all over the world. And last year, we introduced Pulse, a separate product that reintroduces that real time capability that you you experienced with with Fresno 1 where you can write a request and it shows up in the other browser. And you don't have to do any of the stuff in between. Until until now, you have only been able to to work with these real time capabilities from the back end. So then you would have to implement your own permission rules and your own, WebSocket handling.
But this project we've been working on with with Joe, Joe Rody, is to, to bring that capabilities all the way out to the browser. And we're going to to have an early access version of this ready in a month or 2, something like that. I'm I'm very excited for that because then we are, capability wise, all the way back to where you started 6, 7 years ago.
But it's much more, like, modular. Right? Like, you is that kind of the key?
It's built to actually work at scale in a way that, that real engineers, decision makers, and large organizations can can be can feel comfortable about deploying production.
Super cool. And you have, like, actual databases as well right now? So you can actually, like, run Postgres with Prisma.
So we we've assisted that for a long, long time. We've had people who people who need to to operate things in production. Surely, they want their database to be with AWS or PlanetScale or some other, like, serious database provider. It turned out we were entirely wrong. So we have had our our cloud platform, customer platform, available for about 4 years.
And for a long time, we we struggled with very low activation rate, and we we we could not figure out why. And what we learned over the last about a year ago, we learned that more than 50% of everybody signing up to our cloud platform, they were not interested in any of the products we have. Many of them haven't even used Prisma before. They just they wanted a hosted database, and they knew somehow that Prisma is the database company in the ecosystem. So they just went to our website.
They didn't read anything. They signed up to the cloud product because you need a host database. You have to sign up. And then they clicked around for, like, one and a half minute and just closed the thing down and then it came back because we have a database for them. So now we do.
We we launched FirstBuild Postgres in early access, late last year. In the beginning of February, it'll be GA. So it means you can now actually use this in production, and we've built it with some very, very cool technology. We can dive into it.
Yeah. That's, it it makes, I feel like there's this kind of, you know, there's, like, 22 sides. There's, like, the kind of people on Twitter saying, like, you know, manage your own database. Like, everyone should be able to steal this stuff and, like, you know Yeah. People people can do it, but then there's also, like, the reality is a lot of developers don't wanna do all that stuff themselves. They just want, like, an easy they it's one easy life kind of thing. Right?
Yeah. Easy life. Sure. Don't don't work. Don't deal with this stuff.
And and I think that is going to, to change even more now that that is becoming so much cheaper, so much easier to build applications with modern, AI tools. That's a whole other topic we could talk about later in the 1. But we are seeing this change where applications used to be something very serious, very bespoke. You have engineers working on it for months months years to this new thing where you can just get a real useful application built in a couple of hours by chatting to an LLM. But this this app needs all the usual infrastructure.
Right? But when it takes a few hours to build the app, you can't spend days or weeks setting up infrastructure on AWS and and VPCs and subnets and all this kind of stuff. It's just, 1, it takes too much time, too much friction, and 2 is too expensive. You can't have that. So we've designed the Prism and Postgres service such that you can you can create an unlimited number of databases.
Creating another database is essentially free for us because of the way you have implemented it. And then you only you only pay for for what you use. For compute hours or gigabytes of memory or anything like that, you pay for the request that is made from the application. So that means if you're somebody who who makes, 5 applications in a month, maybe for yourself, contract work or something, you can have them all work with first with Postgres. You can you can fill out tens or hundreds of these applications.
And as long as they see very little use or no use, they don't cost anything. And then when the application starts to to become successful, you're on Hacker News, the database just scales up to to support you. You don't need to configure anything. You don't need to worry about a delay in scaling up or something. It just works, and you pay per request.
So you can calculate the exact cost for you per user. There are no no surprises around. Oh, now now my database is using so many computer hours. I I didn't realize that.
Yeah. That's actually one of the questions I had is because, you know, most database companies kind of do price on, like, kind of compute or or they tend to have, like, buckets of, like, you can have this much usage for the $50 plan and, like but you went, I think, very differently to all of those, and and as you said, you were doing it by, like, queries, I guess, is the how did you make that decision? And then also, like, did yeah. Like, what are there any practicalities around making that this kind of a pricing kind of setup?
So we made the decision based on on input from from developers. We we talked to to so many people trying to understand what they thought about the existing pricing model. And I think there are there are 2 existing models. 1 is the kind of the dominant model is what AWS does. It is you you reserve an instance of this size, and you pay this amount of money per per month, and that's your cost.
If you want to change it, you have to go in and reconfigure it so it grows or shrinks. That's one model. Then a new model that is starting to emerge, Neon is a great example of this, is you you pay for what you use, which is great, except, the dimensions you pay, and they're really confusing. So when you sit down there and you're building your app and you're trying to estimate your future costs, it's quite difficult because how many compute hours do I need? How do I know?
Nian will scale up and down and it will pause, but it's difficult for you to figure out what your monthly bill will be unless you go and try it. So the approach we're taking is let's figure out a way to build the service such that we can charge by the number of requests. It's still a variable, but as a developer, you have a pretty good idea of how many requests your application makes for a business to decide. You can estimate how many requests a user will make in a month. So you can you can go and do some some simple math and say, if I have a 1,000 users if I get 10,000 users because I'm on a server, I can yes.
This is what it would cost. It's very predictable. So we knew pretty early on that that's the that's the model we wanted to have. Then it was all about, okay, how do we how do we make that reality? How do we make that feasible? How can we build that and and make sure that, that we can have positive margins operating the product?
Yeah. This this is something that I've thought a lot about for my own project. It's like, there's this sometimes this friction of, like, what would make sense to the user, and it's easy for them to, like, kind of plan out and map. And then also, like, what makes sense in terms of your margins because, like, if you have this I guess if you have, like, a very simple, like, a pricing by query, someone could do, like, an incredibly complex
Yes.
Query that actually costs you a lot more than your pricing for. And then, like, sometimes we, you know, we worry, like, you know, it's like you you kind of have simple pricing, but then someone comes along and does something, like, absolutely mad that, like, cost you a ton of money. And then it's like this kind of this is the constant struggle that I think about with, like, my stuff. And so how did you kind of because you've got this lovely simple pricing of, like, just queries. But then how do you think about, like, making sure that someone can't just come and
Abuse it, basically. Yeah. And I think the the the most extreme example of how you could abuse it is cost base allows you to install extensions. So you could install bitcoin mining extension, and then every single request and single query mines a bunch of bitcoin and uses all the compute, and it's it's really expensive. So that is a that is a real challenge.
And there there are 2 ways we are overcoming this. 1, by making sure that our our own costs are as low as possible. So that means we're not operating on AWS. We're operating on significantly cheaper hardware that we fully own, and the other is the other is, having limits in place. So we're saying, what is a what is a reasonable request for a normal application to a database?
What does that look like? We think it will take less than 10 seconds. Things like this. So those limits are in place. You can make a request. Yes. But it cannot be a request that that lasts an hour. You don't want that in normal applications anyway, but we are imposing that as a limit on on you now to make the the billing math work.
Okay. That makes sense. And then I guess I assume that you have, like, some sort of, like, absolute edge case. Like, you could just an account manager or something could just look at it and be like, yeah. That's fine. Or, like, I
guess, if
if it's a real logistic like, they're not mining Bitcoin. Like, they they have a real reason to to do such a long query.
Yeah. So we've mapped it out such that even in the most extreme case, the cost to us will not exceed what the user is paying.
Oh, wow. That's amazing. So let's talk a
little bit about the the technology and the implementation detail. Most of these database services, they run on on the big cloud providers for good reasons. It makes a lot of sense. Most of their customers run on these cloud providers. Most of our customers will run on on these cloud providers.
If you are using Vercel and Netlify, for example, your serverless functions run on these cloud providers. So you generally want to have your database be as close to your application as possible. But the downside of being on the cloud providers is that they're extremely expensive. Many years ago, it was kinda reasonable, but as the cost of compute storage has just dropped dramatically, the cloud providers haven't changed. So that means paying for raw compute on AWS is maybe 10 times more expensive than if you go to a a top tier colocation center.
You buy your own servers, and you you set that up. Mhmm. Networking, even more crazy, like, a 100 times more expensive.
Really?
So those are those are costs that all add up. And if you build a a service on top of AWS, Google, Microsoft, you need to pass those costs onto the user, and you need to be very careful about what you allow them to do. If you allow them to do something that you don't account for in your billing model, you can be in big trouble because the the the unit economics, the base cost is so high that you can't you can't build in a lot of buffer. Whereas if you operate on your own infrastructure, in in normal data centers, then you have you have so much buffer because the base cost is so low that you you can be a lot less careful about having to to pass on every single cost to your customer.
Yeah. And how how much work is it to kind of, you know, to actually do it this way, versus just using AWS? Like, how much? I I I so it's a very vague question, but, you know, like, is this significantly harder to do it this way?
So if you're on Twitter, you many people will say, just just get a VTS. Just pay $5 a month to Hestner or whatever. And that's essentially what we're doing, except we're doing it at scale. So we are not setting up a lot of small VPSs. We are we're getting our own servers and operating those.
And these are in data centers that are right next to AWS. So there'll literally be a fiber connection between our data center and the AWS region. So that means that, the latency, not a big problem. But there is a bunch of work you have to do as upfront work. When you need to pay for those servers, you need to set them up.
You need to manage the networking yourself. And as somebody who just wants to deploy an application, that makes no sense. That's why you go and buy VPS or something like that. But for us, venture backed company looking to have, hundreds of thousands of customers, it's not that big of a deal, because it's a it's a cost, but it's a fixed cost that is shared between all of our customers. And you
could just hire someone to manage it. Absolutely. Yeah. Yeah. That makes sense. And then, also, maybe this is, just going off piece, but, like, you said that, you know, it's, like, 10 10 x more 10 x cheaper potentially or a 100 x cheaper with networking. And if you're using, like, a Het Snore or something, is that, like, somewhere in the middle, I guess?
Hetsnore is really cheap, but they are somewhere in the middle. Yes. Okay. And Hetsnore is great, but they're not a they're not a top tier data center. They're not right next to AWS. Okay. So that's that's the budget option, and we want to we want to do something that is comparable to being in AWS.
Okay. So that's also a so you're getting you're getting a similar performance, basically the same performance as AWS, but a lower cost. Whereas if you're at Hasner, it would be, like, a bit lower cost than AWS, but it also would and it would be less work, but it's Yes. Also not as good as sense.
That's the right way to think about it.
Okay. That makes sense. That's very, very interesting. Yeah. I I I spoke to Railway, recently, and they're kind of doing yeah.
What are they doing? That that's that's a really fascinating company.
I I think they're opening their own, data centers, across the world, They're saying, like, multiple locations. Yeah. I think they're actually I think they, like, rent office space and, like, you know, rent space and stuff and do the buy buy everything.
Building up there. That's an exciting world.
Which I is that another order of magnitude that
you could save me? Yes.
It's, it's funny as, all the dev tools are doing this themselves now.
Yeah. So I'm really curious how this market will develop over the next 5, 10 years. Yeah. AWS was a great deal in the early days because you could offload all of your server management, all that kind of stuff. But then they have it reduced prices according to the market, and the open source world of managing servers yourself has gotten so much better.
So the the value to cost ratio has just completely flipped. And I'm wondering if they are going to respond to that change over time or if there's still so much, unmet demand from large enterprises that are just doing this lift and shifting into the clouds. They can just continue to to run with these elevated price as well many more years.
Yeah. It's a it's a very interesting time. I don't know. It's a and they're making so much money, so I imagine that. I don't know.
I would like to keep that going. Absolutely. Yeah. Yeah. One of the
things I wanted to ask about, is the database world. So, you know, you're you're now in the Postgres world, and, you know, there's there's there are dev tools. There are kind of options. And I I I wondered, like, how you think about kind of, like, differentiation. Yeah.
So we launched Prisma Postgres not because we made a strategic decision that we need to get into the database hosting business, but because our users, our customers came and told us to do it. Yeah. Begged us in some cases. So so I think that is our main differentiator. It is this massive community of software developers that buy into the brand value behind Prisma that loves our open source products and want to have a fully integrated experience.
So that's what we are delivering. Then on top of that, we are we're doing some of these technical innovations that I think will make personal post quest more attractive than than other offerings. But, really, that's secondary. The primary thing is that personal post quest is fully integrated. Use the personal or end, put a new application.
It's gonna just work out of the box. Prisma has this in it command that helps you set up a project that uses the personal ORM. In the future, that will enable you to also just spin up a database and business focus. You don't have to worry about it. You don't have to manage your credentials or anything.
It's just there. And when you think about a future where people build applications in hours over a weekend, that becomes important because you need to do it again and again and again. You don't want to waste time with all of this bespoke setup and infrastructure management feature. You don't want your apps to be set up differently. Right?
Because then all of a sudden you have 10 applications, 50 applications you need to manage. And if they all work differently, it's a mess. 1, you want that standardized. Standardization used to be a thing in enterprise, right, where you wanted all of the teams to work in the same way. But it's also a thing for individual developers, for small teams that are now increasingly working on on many different applications at the same time over time.
Yeah. Yeah. Yeah. It it's interesting that, like, it's like you're building it for your it sounds like you're largely building it for your own community that wants this, and it's everyone wants everyone has different preferences, and everyone has different things, and you're building what they want. Your your audience. Yeah. Audience community. Yeah.
And we're not trying to build a a general purpose post quiz offering that people building Python servers should use. They could, but we don't really care about that segment. We care about people who use Prisma, who are in the no TypeScript ecosystem, people who understand what Prisma is and the kind of sensibilities we have around developer experience. Those are the people we care about, and those are the ones we're building a database hosting platform for. And this is a large group of people.
Right? As I said, we have more than a 1000000 developers every month just in Prisma. Lots of people.
Yeah. And, I know you, you know, you said you specifically didn't necessarily want to build, like, a database. You kind of almost, like, dragged into it. But when you look at, like, the kind of, like, public dev tools, you know, like, publicly traded dev tools, like, a lot of them are database companies. Yeah.
There's a proportion. So that that's also, like, exciting that there is this kind of huge opportunity there. And there's, like, this track record of, like, big companies being built at databases that provide databases.
Absolutely. And some of these the new database companies, they've been on a similar trajectory as us. Have you met with the Tersa team?
Yeah. Yeah. Yeah. Cloud has
been on. They're they're a great team, and they have they have essentially been speedrunning that same, trajectory we've been on for the last 8 years. They started out building a back end as a service, had a database component. They get out of it. They should really refocus on the database component. Now that's their whole thing. Databases are universally necessary. Right? You you need a place to store your data.
Amazing. And, okay. So two final questions. The first one is, what advice do you have for dev tools founders?
So things are different today. Right? I really think 2025 is it's gonna be all about building applications with AI, with LLMs. It's just gonna be hugely transformative. The one thing we are thinking about is the fact that now developers can build many, many applications.
And what does that mean for development tools? Think the the biggest lesson we have learned as a company is the value in, in really growing the community early on. It's just a massive massive force that we are now writing. The fact that we invested so much in community management and getting on hack on the hills and and doing SEO content early on and growing this huge community, has been such a help for us.
Amazing. And, what dev tools are you excited about right now besides Prisma?
So there's one I'm really excited about. It's a little bit nerdy. It's called Ferdera. It's a stream processing engine. I think most people using Prisma are probably not that excited about it.
But I'm excited about it because, one of the big challenges I I had in previous job was figuring out how to scale our database system such that we could avoid doing doing joins at read time. Instead precompute that data. And is an incremental view maintenance engine, essentially, that is really efficient, written in Rust, and I'm really excited for that. I want to see if there's a way we can integrate that with Freshman, make it a part of our data platform.
Amazing. How do you spell it?
F e l d e r e.
Okay. Amazing. Amazing. Check it out, everyone. If you've got anything that people should check out, right now,
go check out Chris and Postgres. By the time this I don't know. How long does it take for you to get these episodes live?
It's probably gonna be about a month, I would say.
About a month. So by the time you hear this, Christmas postcodes will be in GA. It will no longer lose your data. It'll have backups and everything. Go try it out. It's a it's a generous free tier. Spin up a bunch of databases. I think that's, that's my that's my ask.
Amazing. Amazing. Soren, thank you so much. This was awesome, and, thanks everyone for listening.
Thanks, Zach. This was this was great.