AUDIO EDIT PodRocket - Will Madden - Prisma Next === Noel: [00:00:00] Hello and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. I'm Noel, and today I am joined by Will Madden,~ uh,~ here to talk about Prisma next and everything going on there. How's it going? ~Well~ Will: Good. Thanks. I'm really happy to be here. No. Noel: ~cool. Cool. Um, let's see.~ So last time you were on the podcast, you were talking about Prisma seven. ~What's, um, kind of what, I guess, ~what's been going on since then? ~How would you, how would you kind of, you know, like frame Prisma and like have dev developers and users think about what Prisma is offering today?~ Will: ~Uh, okay, well that's a few different questions at the same time, so let me try~ Noel: ~Sure. Yeah. Yeah. I'm sorry. I'm, I'm, I am laying a lot on you very quickly.~ Will: ~Oh, that's no problem.~ I guess to put it in context,~ um,~ at Prisma we have been on this journey of trying to migrate away from rust for some time. ~Um, ~and there's a few different reasons we want to do that, but one of the big ones is we want to be more flexible and be able to deliver,~ uh,~ more features faster. If you're a Prisma user or you're even on the sidelines watching, you've probably seen there's been a lot of frustration for a long time because. There are features. People want p prisma to support or,~ uh,~ database primitives. They want to access through the OM but they can't, or,~ uh,~ like a whole new database they want to be using and they can't, or they want to use Prisma in a specific environment, but it doesn't work there. ~Um, ~and we've been working our [00:01:00] hardest to try and,~ um,~ give users the things that they need. Like a lot of us used to be application developers as well. We feel this pain and we want to do these things, but we're a small team and it's a big code base and,~ uh,~ it has to work in a lot of different databases and environments and stuff. Noel: Yeah. Will: So it's been really difficult to make that happen. ~Um, ~so Prisma seven was a really big step in the right direction. ~We, ~we did this big refactor away from rust. So ~we, ~we took our core logic that was written in rust. We cross compile it web assembly and we shipped that to users in their,~ um,~ application bundles. And that meant Prisma could run faster, lighter without the complication of downloading rust binaries in the background and trying not to like, get in users' ways. So you had to actually be aware of them. Noel: Yeah. Will: there were a lot of advantages and that's where you were talking to me last time. Prisma seven had just shipped. That was the core component of it. ~Um, ~or Prisma seven was just about to ship. I think last Noel: Yeah. ~Yeah, yeah, ~yeah. ~Mm-hmm.~ Will: and this time we are doing something even more ambitious. ~We, uh,~ since then, Prisma seven [00:02:00] went out. ~We, ~we had to make a bunch of compromises to get it out in the timeline that we had in mind. Noel: ~Hmm.~ Will: ~Um, ~so it shipped,~ uh,~ without a lot of performance optimizations we wanted to bring, which we've since made. So it's now as fast or faster than Prisma six. ~Um, ~it was missing some core features and we've filled in a lot of those gaps. ~Um, ~one of the big omissions was Mongo support. Mongo's not a SQL database. ~So, um, ~we were able to port all of the core logic for the SQL databases over, but not the non SQL databases. And our intention was to come back and extend it. But that was really difficult. So between launching Prisma seven at the end of last year, and now we've done a lot of that work, but at the same time, we had to ask ourselves. Is this incremental migration from rust to TypeScript? Is it worth the effort? And Prisma next started as a prototype where we were trying to answer that question and the question of what do RMS actually mean in 2026? Noel: Yeah. ~That, ~that makes sense. ~Is there like, um, I guess kind of on, on, was there,~ did you guys kind of [00:03:00] change courses much ~kind of ~as you were early in that journey ~and, and trying ~and trying different things? Or ~was it, ~was it largely kinda led by this, ~you know, ~notion of trying to get NoSQL supported? Will: No sequel, no TypeScript,~ uh,~ sorry. No rust. Noel: Yeah. ~Yeah, ~yeah. I gotcha. Gotcha. I get, no, I mean, I, I mean, just like the, you said ~like ~catching up, you said catching up the,~ um,~ like Will: Right. Noel: compatibility for ~like, you know, Mongo, ~Mongo, like databases was ~kind of ~one thing you've been working on in tandem. Like ~how, ~how are you deciding where to focus your efforts? Will: ~Um, well ~this has been ~a, ~a long ongoing conversation internally where, ~you know, ~one of the things holding us back was this monolithic core. It's really hard to change anything, and we couldn't accept any external help because nobody could actually understand the code base. Noel: I see. Will: ~So, um, ~losing support from Mongo was a symptom. It wasn't the root cause. It wasn't the root problem, Noel: I see. Will: was a symptom of how complicated stuff had become. Noel: Gotcha. Will: ~Um, ~and that was through like, not because of negligence on our part that it became so complex. It was an architecture that [00:04:00] was designed for ~a, ~a totally different operation paradigm. We had tried to bring along with us, but the weight of this, these like legacy decisions, had reached a tipping point where it was now more valuable to cut our losses and rebuild from scratch than to try and incrementally,~ um,~ adapt the legacy architecture to where it needed to be today. Noel: ~I see, ~I see. Was there like much kind of, I don't know, pushback or ~like ~what was the sentiment of the community? ~Like ~did people ~kind of ~empathize with this and understand why you guys were doing what you were doing? Will: ~Um, ~I think yes and no. Prisma has, Prisma is a like household name in the JavaScript ecosystem, and we've bought a lot of goodwill over the years by giving people something that solves a core problem that they have and does it with a great DX and a smile on its face, even if it can't always do what you want, it'll try and give you a really good experience while you're doing it. I think we started with a lot of positive sentiment. ~Um, ~and over the course of the last year, we've been really trying hard to be open and communicative and [00:05:00] try to tell users, we think this is what you want. Here's our attempt to give it to you. What do you think? And then respond to the feedback we got. And I think that brought us a lot of positive sentiment as well. And we've been very open with the fact that we want to get to fully TypeScript. But I'm not sure people could really appreciate,~ um,~ the steps that we took to get there because ~they, ~they took so long, it was hard to see them as ~like ~one continuous set of coherent decisions to try and achieve one goal. Noel: ~Mm, I see, ~I see. And then ~you also, ~you also mentioned that kind of like part of this. Calculus was figuring out what an ORM is ~kind of in the, you know, in the, ~in the age of AG agentic coding in the AI era in general.~ What was that like? What were those, uh,~ what were the things you guys were kinda looking at and considering, how did that weigh into this kinda rework? Will: ~Well, ~I guess I can sum it up as one sort of mental exercise, which was the question that we posed ourselves. ~Um, ~agents are now, ~uh. ~A pretty typical part of most developers workflows, and I can ask my agent to just write [00:06:00] me SQL directly. So why do I need an ORM or a query builder? Like why should I use Prisma or Drizzle or Kely or any of the other equivalent tools when I can just have it write the sequel itself? Noel: Yeah. Will: ~Um, ~and the answer we came up with was in the past. The value of an ORM was making your SQL queries read like your application logic so that you as a human could understand it, right? ~Like ~that's what they do. They shift your abstraction level up. So instead of speaking in the low level,~ uh,~ terms of your database, this table and that foreign key in these indexes, you get to speak in application terms. I want my users and I want the posts belonging to these users, and I want the comments on those posts. ~Um. ~If I can just speak in that high level of abstraction to my agent, then the value of translating your high level speech to low level database terms has just disappeared. So do we still need these tools? Noel: Yeah. Will: And the answer we came back with after [00:07:00] actually trying that with agents was, yes, they can write sql. No, they can't write it correctly most of the time. And what they really need is fast feedback loops. They need a way to try something, see if it works, and then adapt based on the feedback that they get. And the shorter you make those feedback loops, the more effective your agents become. Noel: ~hmm.~ Will: And the other thing you need is to limit the damage that they can do. ~Right. ~So ~that's, ~that's the other big component, verifications or rails. Noel: I see. ~Yeah. What does that, I, I'm, I'm, I'm, I'm kind of curious, I'm curious on both, I guess I'm, I'm, I've,~ I think that this, like rapid feedback loop is a thing that kind of people are realizing across domains and that ~there's a ceiling to. How quickly, you know, there's a, ~there's a ceiling to the efficiency that like agentic coding can provide. That is how quickly can you get it feedback or ~like, you know, like give it, ~give it the context it needs to understand what's going wrong. ~Why do you, like, ~why is Prisma position unique in ~kind of ~providing a solution to that problem here? Will: ~Um, ~I think it's unique now, primarily because we've been thinking about it. I think as we go forward, more and more tools will be optimizing towards feedback loops, verification steps and [00:08:00] guardrails. Noel: I see. Will: ~Um, ~I think this will be the paradigm of the future. Right now,~ uh,~ what it means in practice is we've built,~ uh,~ frequent checks into just about every layer of the system. So anytime you interact with Prisma, what your,~ uh,~ agent's going to experience, or you as a human, you'll experience the same beneficial feedback loops. What you're gonna experience is, let's say you're writing a query. The first thing you do is you. You experience the type system, your editor will offer you auto complete suggestions and ~the ~the query structures that you experience, like they come with all this type information that says you can use these model fields and they have these potential filters you can apply to them. Your agent gets the same input, right? If you do something wrong, you'll get a type error that says, ~you know, ~you can't use this thing in this place. Your agent gets the same feedback. So that's the first layer of the type system. And this is the one that all of the other type safe ORMs and query [00:09:00] builders provide Noel: Yeah. And it was ~kind of ~there already, right? Like it was ~kind of ~like ~this was, ~this was what it was like before. Will: This was the promise for ages and ages. That's why any of us are using TypeScript. Noel: ~Right. ~Yeah. Will: ~Um, ~but then after you've written your query, when you go to execute it, prisma next, ~um. ~It knows the structure of your schema because you tell us upfront, this is my prisma schema. This is what I want my models to look like. Make sure my database looks the same way. Then when you're writing your queries, your query builder will not let you use database elements that are not backed by your schema. So you can't write a query, even if you escape the type system. The ~query ~query client won't let you construct a query that uses a table that doesn't exist, or a column that doesn't exist, or an operation that's not appropriate to that column type. So that's the second layer of checks. Then once your query is constructed, before it gets executed, we pass it through our middleware layer. The purpose of this layer is to implement,~ um,~ checks. So we've built a couple of very simple,~ uh,~ middlewares. One of them is the query linter [00:10:00] we're calling it, Noel: Okay. Will: and it works the same way as Es lint you. It has a bunch of like preconfigured rules. You can switch 'em on or off to decide which ones are errors and which ones are warnings, and it receives all the middlewares. They just receive your incoming query as an abstract syntax stream. And they can traverse it and say,~ well,~ you're asking me to do a delete, but you didn't provide a aware clause, which implies we're gonna delete the whole table. And I'm flagging that as an error. You can't do this kind of query. Noel: I see. Will: So every step that it passes through has these verifications and checks. And anytime you violate one of these steps, your agent gets structured errors that include where the problem occurred, why contextually it's an issue, and what it can do to fix it. Noel: Yeah, I, this is maybe ~a little more, ~a little more in the weeds than,~ um,~ we typically get into it, but ~I'm, ~I'm curious 'cause I like that it feels like the. A ST like I, I understand ~how you guys or~ how that could be built. ~Um, if like each piece of, like, if, ~if there's no kind of dynamic query building happening, ~is that, ~is that possible with like prisma? ~Like ~could I go in and like [00:11:00] build a query based on like variables and state? Is there any of that or is this Will: of course. Noel: ~so is there like, ~and ~I'm, ~I'm not talking about like parameters being passed into. Passed into functions, but I'm like dynamically including a aware clause. ~Like ~if, ~you know, ~like something happens like that,~ how,~ how do you guys build that tree when you like, are passing around? You have, when you have the capacity to pass around like a not yet executed query. Will: ~Um, well, the, ~the query builder constructs the, ~I mean, ~it's called the Abstract Syn Tree. It's a data structure representing a query, and you can change it however you like. That's what the Query Builder is doing internally. If you want to build that dynamically, there's, it's exactly the same operation. Nothing changes for you. The only thing that will materially change for you is if you're doing it dynamically. You lose a lot of the type safety. We can't tell you at compile time Noel: that's Will: it's not easy for us to tell you. Noel: ~right. ~Yeah. ~Yeah, yeah, ~yeah. ~Um, ~so it's ~like,~ Will: do is enforce it at runtime. You won't be able to construct an invalid query. Noel: I see. So ~are, are, ~are these middleware layers happening at runtime then as well? I see, [00:12:00] I misunderstood. ~I ~I was thinking that was like at a, ~you know, ~like a kind of a compile air quote, compile time step where ~it was, ~it was doing this validation. So how does that ~like, ~manifest in the application? ~Like if it, ~if it winds up trying to perform a query and you hit one of these, like, oh, this is a, ~you know, ~delete without a aware clause. Like how does that manifest? Will: You treat it pretty similar to how you would use ES LT in your development environment. You would configure it to throw a hard error, halt the application so that I fix it immediately. In production, you'd probably wanna pipe your warnings or errors coming from your linter to ~somewhere, ~somewhere else to your log or your error monitoring system. Something like that. Like you have queries coming in that are suspect for these reasons. I'm gonna try anyway, but you should probably look into this. Noel: Yeah. Yeah. Gotcha. Nice. Yeah. ~Are there, ~are there different, is ~there ~there different like configuration kind of settings as to how you'd want to eject out of various,~ like,~ I don't know, lint query verification failures? Or is it ~kind of like, you know, ~if ~like, ~you ~kind of, ~you ~either ~either have it hard [00:13:00] stop or just give you a warning Will: Right now ~the, ~the project's in a pretty nascent state. We only just built this thing. It's not ready for primetime yet, but it proves the concept. I can imagine configuring it a really similar way to lint where, ~you know, ~you can say which rules are errors under which conditions. Noel: Gotcha, gotcha. Did you, have, you found that using,~ um, like, ~like kinda having ~the, ~the presence ~of these, ~of these checks and the configuration there,~ um,~ like in the repos, does that inform kind of agents. As well. ~Like will that have, have you, ~have you found that there's less of a propensity to go and ~like ~write queries that would end up violating them by virtue of having the configuration there? Or ~like ~is that not really a bridge that the agents have been crossing in your guys' experience? Will: ~Um, ~honestly, the,~ uh,~ the linter rules that we have protect you against such egregious errors right now. Like we just built a handful of really simple ones Noel: Yeah. Will: they're not cropping up that often to begin with anyway. But they're good safety checks that like you're definitely not deleting everything right. Noel: ~Yeah. Right, right, right. Yeah. Was there, are there any kind of other, ~I feel [00:14:00] like ~this is, this is always, ~this is always ~kind of ~tricky. Like ~I've, ~I've been in this space, a couple of, ~you know, ~employments lifetimes ago, like I was working on an, like an ORM that we were building ~kind of ~internally ~for the, ~for the firm and ~like. ~I feel like there's always this kind of,~ you're,~ you're very much in the realm ~of, ~of ~trying to, not~ trying to glean what users want without ~like ~getting in their way. And now I think the problem's even a little bit more challenging if you're ~kind of ~playing defense against ~like, you know. ~Agents that are maybe not behaving well or doing what they probably want to be ~Are there, are there like, like I,~ I think I'm with you. ~It, ~it seems to make sense. There's probably some very high level kind of guardrails. Like you probably don't want to be deleting everything in the table when this happens, but ~like, ~are there other, don't know, specific kind of,~ um,~ behavioral patterns or like types of. Queries that you guys kinda ~have, have, ~have considered as things which may be in indi indicative of something being wrong and like ~how do you, ~how do you apply that to such like diverse domains in which someone might be using an ORM? Will: I think,~ um,~ your goal is to be able to quickly and easily write queries well,~ right,~ Noel: ~Hmm. ~Yeah. Will: and [00:15:00] agents like humans. Will benefit from,~ um,~ like reinforcement. So ~if you've,~ if we can inspire you through a couple of simple lint rules to start writing queries in a way that is already ~like, ~set up for success, your agent's gonna start copying the patterns that it sees, right? And the best query is no query. So while we have done some work on linting, these queries, those are a guardrail, they're intended to be like your. One of your final protections because you have written ~a, ~a pretty bad query to begin with. We are gonna try and stop you from shooting yourself in the Noel: Yeah, Will: but better is to give you a way of writing good queries so you can reduce the amount of query code you write pretty significantly with Prisma. Next, because we've given you for the first time, we are starting to actually give you tools to define your applications like domain vocabulary. Noel: ~Mm,~ Will: If you've used active record before, Noel: I have, yes. Yeah. Will: then you probably [00:16:00] remember scopes. Noel: Yeah. Yeah. ~Mm-hmm.~ Will: So we've built something that's a very close equivalent to that for TypeScript. ~When you, ~when you set up Prisma next, you can provide a collection class for one of your models for each of your models. And on that class you define functions which return wear clauses. You build them up using the same,~ uh,~ everyday model wear clause building DSL. So it looks exactly like writing a regular query, but you're just constructing the wear portion of it. And that lets you have named methods that say on your,~ um,~ posts collection, you could have a popular method which returns only posts which have likes above a certain number. ~Right.~ Noel: Yeah. Sure. Sure. Will: Anytime you use the Prisma client and you say DB posts, now you can say popular. So instead of ~like ~protecting you from writing that query poorly, you write it once and then you can reuse that collection method everywhere. And you can even use it on [00:17:00] relationships to other models. So you can Noel: I was about to ask. What if I'm like, what if I always pull this and like I'm ba virtually always joining it to something else. Is there like a,~ like,~ can you do the ~same, ~same for that relationship? Yeah. Yeah. Will: Anytime you access that kind of collection, you gain those kinds of methods. So you can say ~like, ~users, find id, whatever posts popular, and so on and so forth. Noel: Nice. Nice. Yeah, that, that's,~ um,~ I guess are ~to what, ~to what degree are you guys ~kind of ~hoping that becomes ~People kind of, um, uh, what's the, what's the term? But like, you know, that's, ~the way in which they build query. Like,~ Like, do you, ~do you like this idea of kind of scoping being like the top level thing? ~Or, ~or ~like, ~to what extent are you pushing that versus ~kind of building,~ building ~the, ~the whole,~ uh,~ query like in ~each, ~each place you might potentially need it. Will: ever wants to repeat writing a query. Noel: Sure. Will: ~do you, ~do you like using functions? Isn't it better to just write the code every time? Noel: Yeah, but I think, I feel like one, one could also just ~like ~write a helper function, right? That's just like on the side that kinda ~like does the, ~does the thing and they could call that everywhere and that they'd ~kind of ~be deduplicating in the same manner. Is there,~ like, you know, I, ~I'm assuming you're recommending they [00:18:00] don't do that and they do it, ~you know, ~this the new way is there,~ um,~ like ~kind of ~a, a, a. Will: Prisma X is very hands off. We don't tell you to do anything. We giving you these tools. Noel: of course. Yeah. Will: If you prefer to use,~ um,~ standalone functions, these new query,~ um,~ these new ORM queries that you construct, they're ~very, ~very flexible. So if you want to, instead of having ~a, ~a collection class, which has a filter methods on it. When you're building a regular wear clause in Prisma, the thing that it takes inside it is it's self composable. You can rip that out into ~a, ~a reusable, standalone function of your own, and you can compose those functions together. We also give you like logical operators an and function and or function and so on, so you can compose your own standalone, standalone filter functions together. However you please. You can even pull the other parts of ~the, ~the query apart and compose those into your own functions as well. Noel: Oh, cool. Cool. ~Um, nice, nice. Is there like, um. I guess are, are there, are there, like, is there any, I I'm, ~I'm curious now, because ~you've, ~you've brought this up [00:19:00] and ~we're, ~we're thinking about like ~kind of ~composing these higher level entities. I feel like performance always ~like, kind of ~creeps into my mind here. And now that ~you've got, ~you've got this kind of paradigm of having ~a, ~a middleware, like a linter layer that's ~kind of, you know. ~Putting some guardrails on. Is there any like, performance kind of checks? Like, oh, you're doing like a weird, ~you know, ~a weird join here, that there's ~like ~no good indices on and like, this could be bad. ~Is are, are there, ~are there any kinds of ~those, ~those guardrails in place? Will: Yeah, totally. ~Like ~that's checking that there's an index for something you're querying is one of the first linter rules we wrote. Noel: Oh yeah. Cool. Yeah. Yeah. Will: The other middleware that we created was a simple budget middleware, which the goal was to like prove the concept that,~ um,~ you can estimate what the time, cost, or performance cost of an incoming query will be before you run it and you can, or by doing an explain query to ~the, ~the server ahead of time, and then you can. ~You know, ~refuse to run a query that's going to be too expensive. Like it's got really simple logic for this proof of concept, which is just you tell [00:20:00] it upfront, like what order of magnitude you expect each of your tables to be. And then if you do a like unbounded query, we'll say,~ well,~ that's gonna be the whole table. If it's a small table, it's okay. If it's a big table, you're not allowed. Noel: Yeah. Neat, neat. ~Yeah,~ Will: performance ~is, ~is a part of it. Noel: ~yeah, yeah. I, because I, I do feel like that's something that's kind of ORMs have. I mean, I'm, ~I'm sure ~there's, ~there's places out there where it gets better, but ~like, I think, I think it's often it's, it's, ~it's hard to ~kind of ~catch those like n plus one, like problems. ~Uh, like when, you know, when, ~when you're writing 'em, especially when there's like higher level abstractions and like composability, you're not really thinking about it. ~You know, ~I guess a dev, you're just like, oh, I need this and then I need this. And then ~like, ~I'll do this. And then eventually ~like, wait, why is this one?~ Like if a user does this one thing on Tuesdays and all of a sudden like this one query becomes crazy expensive,~ like,~ Will: Yeah. And one of the things that's really hard to debug is ~like ~if you're looking, if you've got some part of your application that's slow and you're looking at,~ uh, well, ~why is it slow? And you've got your logs of which SQL functions were sent to the database,~ um,~ it can be really hard to piece together where they originated from. So Prisma X queries internally. When they're constructed by the [00:21:00] ORM, they carry,~ um,~ a grouping identifier that lets us assign. ~Um, ~if ~you know, ~you've done some complicated nested operation across several models, and to fulfill what you've asked, we had to execute a couple of queries in a row, and this is where your n plus one problems crept in. ~Um, ~in your telemetry coming out of Prisma next, there's something similar to ~like ~an O Hotel,~ uh,~ SPAN ID that tells you all of these things were related to the same original requests that you made to us, and we can piece back together what it was. Noel: ~Neat. Nice. Yeah, that, that, that seems pretty cool. How, how is that, um, like manifesting, uh, I guess, I mean this is, this is pretty new. How, ~how are you envisioning ~maybe~ that manifesting,~ uh,~ like in ~kind of ~debugging tools,~ like, you know, ~like performance analysis tools,~ like how to, how, how, how is that surfaced?~ How do you envision that being surface ~to user or~ to like developers when they're like looking at their production app trying to find pain points? Will: Well, a simple way that we could use this is, let's say you have a middleware and it's receiving incoming queries or query fragments, Noel: ~Mm-hmm.~ Will: ~um, ~and you want to construct something similar to. I don't know,~ uh,~ Datadog or Century or [00:22:00] something that's,~ um,~ aggregating the queries that you've done, wants to present to you a history of we did these things, they took this long, that middleware has all the information it needs to do it. It's got the original,~ uh,~ ORM queries. Attached to their ASTs. It's got grouping identifiers that say these things were associated with each other. ~Um, ~it's got timing information because it knows the beginning and the end of each query. It knows how many rows came back from them, how often they're executed, so that one middleware would have all the information that you need to build like a pretty sophisticated tracing application. Noel: Yeah. Very cool. Very cool. ~Well, ~yeah, again,~ I,~ I Will: you could plug it into any prisma next application and it would work the same way everywhere. Noel: Yeah. ~Right, right. ~Yeah. Yeah. Cool. ~Again, I,~ I feel like ~we're, we're, ~we're super ~kind of ~far down in the weeds here. ~Is there, ~is there anything else? ~Um, ~like ~kind of about the, the next, you know, um. About,~ about Prisma next. It's ~like, ~I dunno, ~kind of a, a fundamental, ~a fundamental shift in how like developers should approach it, especially for somebody that's ~been kind of out of the, or hasn't used Prisma in a while, or kind of ~been out of this space. ~Um, is, is, is there any like, new parent Go ahead.~ Will: A couple of fundamental changes, like the biggest one is,~ um,~ we built this thing to be [00:23:00] extensible so that,~ um,~ let's say you want to use PG Vector. You go on NPM install a PG vector package, you plug it into your config, and now your prisma schema, you can use vector columns and they understand they have length and they have,~ uh,~ certain kinds of ~like.~ Properties. And when you're performing your queries, now your query builder just automatically knows. You can do like cosign distance,~ uh,~ similarity searches on the vector columns that your models possess. So you're still speaking in terms of your models, but now you can search for models that are similar to each other. Noel: Nice. Neat. Will: That's a massive change for Prisma. And that was, that's like really the, one of the defining reasons that we wanted to. ~Um, ~adopt this new,~ uh,~ do this rewrite Noel: yeah. Will: that kind of extensibility. Noel: ~Was,~ are there any other ~kind of, um, like~ players in this space that~ are, that are kind of doing this, like, like have that kind of, uh. You know, like, uh, I like the, ~the membrane between the database and the ORM is ~kind of, kind of ~thin in this manner that you guys ~kind of modeled, ~modeled ~this, ~this ~new, ~new, I don't remember the term you used, but kinda like this modularity pattern where you can just, like NPM install something that's ~like, you know, kind of ~one of the [00:24:00] database features that you're using under the hood. Will: I think composing the configuration of your system by installing packages and injecting them together in ~like ~Runable, TypeScript, or JavaScript, that's a common pattern. That's ~like ~ES build and ES lint and. Noel: you name it. Yeah. Yeah. Will: Everyone does this, and it's a really sensible way of aggregating,~ uh,~ new behavior, but having database types that can pass through your system and augment your type system as well as your runtime system, that's not something that I've seen anybody else do. Noel: ~yeah. Yeah. That's pretty cool. Um. Yeah. Is there, is there, are there like, um, so again,~ you mentioned ~like, you know, Postgres, um, like~ Postgres specific,~ uh,~ features. There, ~is there, is there like, like how, ~how does that work ~kind of, if you're,~ if one's using like a different DB provider? ~Like are those, are those,~ is this composability? This modularity? Is it like ~kind of ~per backend? Is that how that's put together? Will: The backends themselves are injected. Behavior prisma doesn't natively know about any database anymore. If you wanna use Postgres, you have to first give it the Postgres package, and then you can give it the PG Noel: ~Uh, ~I see. Yeah. Yeah. How Will: We wanna do the ~same, ~same [00:25:00] thing for ~like ~MySQL and ~uh, ~also for Mongo. Like the Mongo story's gonna be so good. ~We ~we're working with the Mongo team,~ um,~ and it's just at the design phase now, but back in the day. The Prisma, ORM,~ uh,~ when we added Mongo support, we had to build most of it out of SQL primitives. Like you've got models and they have relationships to each other, and that's great. You get to think in terms of your familiar schema, but under the hood, it's gotta turn into communication with the database and it's still thinks in relational terms. Now with Prisma next, because the. The actual database target that you give, it is a provided extension. We can build ~a, ~a Mongo native experience that uses Mongo database primitives instead of SQL primitives under the hood. Noel: Oh, cool. Will: That means we can use their aggregations and their like client,~ uh, uh, ~field level encryption and stuff. Noel: Yeah. Will: Yeah. Noel: Kinda ~what, ~what, yeah, what ~whatever, whatever that, ~whatever that provider exposes, ~I guess. ~Are you are like, are you guys optimistic that the community will ~kind of ~[00:26:00] be able to leverage ~this, ~this kind of composability, this extension model a little bit more than historically, ~like ~was the norm with Prisma? Will: Absolutely. ~Um, ~whether you're talking about users using this composability for,~ uh,~ to extend their apps. Yes, absolutely. Imagine like it's gonna be so much easier to just go out and pick and choose the extensions you want to add into your application to suit your particular needs or the middlewares that you want to add, or,~ um,~ like being able to mix and match collection methods that are coming from some utility library. ~Like ~there's so many forms of extension users benefit from, and if you're an extension author, there are. A whole range of different extension points in the system where you can come in and author something that's unique that you wanna share, or even something that is specific to your organization that you just want to package up for shared components in your platform. Noel: ~Yeah. Cool. Yeah, I'm trying to, ~I'm trying to think of a good example and ~it's always, ~it's always tricky 'cause ~like, you know, ~it's like who knows what people are ~gonna ~gonna build or, ~you know, like have, ~have some other kind of data source that they're trying to like, [00:27:00] augment something with ~along, like~ along with their database queries or something. Will: So I can think of a really simple example that crops up all the time, Noel: yeah, please. Will: ~um, ~imagine you're building an API for ~your, ~your web application and you have incoming requests and some portion of the request body is a model. You want to validate that you're receiving a,~ uh,~ a model structure in the correct type. ~Uh, ~back in the day, there were generators you could plug into Prisma that would output,~ um,~ like Zod, validators, something like that. Noel: yeah. Yeah. Will: Now ~we, ~we output,~ um,~ adjacent representation of your whole database schema, including all of the tables, columns, what types they have, what models are available, how they map the tables, what their relationships are between each other. So you don't even need the generator. You can just,~ um,~ take this and the type information we give you. And you can do this at runtime on the fly for any model users want. Noel: ~Oh, cool. Yeah, yeah, yeah, yeah. That, that, exactly, that's a, ~that's a good example of ~this, ~this like kind of dynamic responsiveness to something that isn't implicitly part of the system. But ~like, yeah. Yeah. Would, ~would benefit [00:28:00] from this kind of bridge of ~like the, you know, ~the models that exist in the world and like the, your nice kind of type safe ~with all the, ~with all the checks and ~um, you know, safe the~ safeguards in place. ~How about this? Like, okay,~ let's ~kind of ~bring this back then to this,~ the,~ the kind of this middleware linter layer. 'cause I feel like you could take that example and be like, okay, and then I want to ensure that no queries are ever like doing something weird with this kinda, ~you know. ~The bespoke version of this thing that's only for my app. Is that pretty pluggable as well? ~Like ~is it easy to ~kind of ~write your own validation rules? Will: ~Um, ~yeah, totally. Like it's all TypeScript. You can pull it apart and look at how it works. Noel: Yeah. You Will: These middlewares are super thin. There's hardly any code in them. They just ~like ~receive a query, compare it to some,~ uh,~ expectations, and then throw an error if it's false. Noel: ~yeah. Cool. Cool. Is there, is there like, um. Do, ~do you en envision that~ those will be,~ they'll be ~kind of like a, I don't know,~ like a marketplace of those, ~or~ like those will often be ~kind of ~shared or ~brought in by, ~brought in by people. Like they'll be ~kind of, you know, ~best practices like ~pull, ~pull these lint rules off the shelf if you wanna, Will: That is exactly where I would like to see this head because there's a lot of practices that are gonna be common to every application that's [00:29:00] querying a database. You're gonna not wanna do the same kinds of,~ uh,~ mistakes prevent people from shooting themselves in the foot with the same foot guns, Noel: Yeah. ~Mm-hmm.~ Will: ~Um, ~I'd love to have ~like ~es lent standard packages of lit rules for Postgres and mys and Mongo. Noel: Yeah. Will: ~Um, ~and I would love it to be community maintained because there are people out there who know a lot more about this topic than I do, and I would love to have them involved. Noel: ~Yeah. Nice. What's the, um. ~What's the kind of migration path? ~Like how, how, if you're on, ~if you're on Prisma seven currently, ~what's that?~ What's that gonna look like for users? Will: And we're looking at a couple of options. It's early days, yet we haven't even stabilized the APIs you're migrating to. Noel: Okay. Yeah. Yeah. I know. I know. I'm jumping the Will: it's early to say, but there's ~sort of like ~two broad parts of migration that we're looking at. There's the,~ uh,~ I want to run both systems in parallel. ~Um. ~Option, and that should be really easily achievable. Prisma seven, introduce this concept of driver adapters, which let you have ~your, ~your driver as just ~a, ~a function in JavaScript that gives you a connection to the database. Prisma X has a really similar [00:30:00] abstraction, so we'd like them to be able to use the same connection to a database. So you can talk to one system or you can talk to the other, and they will both speak to your database the same way. That means you can incrementally migrate queries from different parts of your app to the new,~ uh,~ interface. But it's, that's operating under the assumption that you have to change all of your queries. And that's gonna be a big job for a lot of users. And we don't wanna make people do that if we don't have to. So the other option we're investigating is like an ~um, ~interrupt layer. Noel: ~Hmm.~ Will: Use Prisma next, but you put in front of it a compatibility layer and it will interpret any of your original Prisma query structures and turn them into Prisma next queries. So you get all the benefits of linting and,~ um,~ validations and checks that Prisma next gives you and improved performance. But,~ uh,~ and you get to keep all of your identical Prisma seven query structures. Noel: Nice. Will: I think you will still want to migrate to the new queries anyway because the new [00:31:00] query,~ uh,~ DSL is so much more flexible and pleasant to use and Noel: Yeah. Will: ~um, ~so I think people wanna do it anyway. But you don't wanna have to do it all upfront. Noel: ~yeah, yeah. I'm, I'm sure, ~I'm sure ~there's, ~there's,~ uh, you know, ~projects out there where there's thousands of these written and it's like, ~we just can't, like, we're gonna, they'll get, ~they'll get. Addressed when we are doing a feature or something in that area of the code base. ~Got that kind of, ~that kind of thing. Yeah. I guess you said you're exploring both of these options, ~like ~do you think it'll be like one or the other, or are these both gonna be things you guys are offering? Will: I would love to do both. Honestly, like the having both systems running in parallel, I think this is a very easily achievable goal. Building a compatibility layer that,~ um,~ works effectively and doesn't have any like unexpected quirks. That's a bit more difficult 'cause there's a lot of like hidden behavior in the original query interface. Noel: Yeah. Yeah. And ~it's, it's, ~it's one of those things where it's like, you can get it, it seems like it'd be challenging to get ~like, ~complete coverage. There's probably gonna be some like weird edge cases where they're gonna be hard to detect ahead of time and, Will: Yeah. Noel: ~like, things, things, ~things failing ~in, ~in prod, I [00:32:00] guess. ~How close, how you say you, again, we,~ you keep prefacing that ~like, you know, ~this is ~kind of, kind of ~in flight a little bit still. ~We don't know like where is the, um, like ~what's the timeline looking like? Where are you guys, whatcha guys looking at? Will: ~Um. Well, ~I shouldn't make commitments to deadlines, Noel: Oh yeah,~ I,~ I, Will: but my, Noel: to put you Will: ~no, ~no, that's okay. My very ambitious personal timeline is ~we, ~we just opened the repository today. Today it went public and the purpose of this was to let people see what we're doing. We wanna be completely upfront about our plans and ~like. You know, ~up until now we were trying to decide is this a good idea or not? And ~you know, ~it, it reached some critical mass and we're like, okay, yeah, this is a very good idea. We should definitely be doing this. So we're telling the world and that lets us speak openly about ~like, you know, ~when is Mongo's support coming? ~Well, ~it's infeasible to build up a Prisma seven, but we're working on it for Prisma next. And to make it up to you, it's gonna be even better than it was before. Noel: Yeah. Gotcha. Will: So now we can be totally open about our plans. Was the goal, but you can't use this thing yet. It's missing a lot of pieces and we haven't got the kinds of,~ um,~ thorough testing that we would want for a production product. So in this phase, we want you to,~ um,~ give us [00:33:00] feedback on whether you think this is a good direction or not, but we can't even accept external contributions yet because we're still changing the things that you would build, be building your extensions on top of. Noel: I see. Yeah. Will: In the next month, I want to get us to the point where we can actually start working with external contributors, where people can come in and they can start building, say, MySQL support. And they don't need to rely on us to be building ~the, ~the framework for them because all the pieces are in place,~ um,~ about a month or two after that, I want to be able to say to users, ~you know, ~we have one database, which is. Ready to be used in applications and we would love you to try it. The first database ~is, ~is Postgres. 'cause that's where we began. ~Um, ~we should have another database around about,~ uh,~ supported to prove that we can support multiple targets, but that's like the next milestone. So we're public today. In about a month, I want external contributors capable of operating in our code base. A month to two. After that, I want the first users to be using this in real world [00:34:00] applications. And a month or two after that, I want our first GA database so we can tell users, this is a production grade ORM. Noel: ~Mm-hmm.~ Will: You can use this in production applications. We are gonna be using it. We're already starting to use it in our own applications. And just eating the pain of the API changing every second day. Noel: ~Yeah, yeah, ~yeah. Yep. Will: But that's all the timeline I have in mind. We wanna move, we wanna give people something really special with this new,~ uh,~ iteration of Prisma. Noel: ~Yeah. What are you most, ~what do you think users will be ~kind of ~most,~ um,~ excited about and ~like, ~eager to get their hands on ~when you're, when you're, when you're, ~when you're saying like you're, ~you know, kind of ~apologizing for ~like, ~eh, we don't have support for ~like, ~Mongo and stuff yet. ~Like, ~what do you think will be the thing that most makes it up to people? Will: I think if you're using Prisma, what matters to you is you get to build your application, which is ultimately the thing you actually care about, right? You get to build your application in your application's own terminology. You don't have to think about sql, you get to talk in terms of models and their relationships. ~Um. ~[00:35:00] If that's what you care about, the thing that's gonna make the biggest difference to you is how you can build up your own applications data layer using Prisma. It's not just a query builder. You construct your own collection methods. You can build your own utility methods for doing the same types of operations on Prisma. Even if you're doing them across different models, you can build your auth layer easily in terms of,~ uh,~ prisma. The domain model that you give to Prisma, that's what I think the biggest difference to users is gonna be. That you have so much more,~ um,~ space and so many more tools to build application specific data logic now, Noel: ~Yeah. Nice. Very cool. Cool. Um, yeah. ~Well thank you for,~ uh,~ letting me pick your brain. Well, is there anything else you ~wanted to, ~wanted to touch on? ~Quick leave, leave listeners with?~ Will: ~um. ~I guess we would love to hear what you think of our direction. ~Um, ~right now the best way for you ~to, ~to do that is to join our Discord server and talk to the engineering team directly. We are here and we want to hear what you have to say. Noel: ~Nice. Nice. ~We'll be sure to get a link to the show notes to,~ uh,~ both ~the, uh, like~ the [00:36:00] repo and the discord server and everything so people can go and go find stuff easily. ~Um, ~yeah. But again, ~thank you, ~thank you for coming online and,~ uh,~ and chatting with me Will,~ and, and letting me, it's answering all my questions and catching me up.~ It's been a pleasure. ~Of course, ~of course. Take it easy.