Why prisma instead of drizzle?
The only thing not to love about wasp is the decision to go with prisma instead of drizzle.
One of the articles in the blog talks about how other attempts of creating the "Lavarel" of JS failed likely because they got to tightly coupled to the wrong technology (next js, etc).
After reading Miho's answer in regards to replacing prisma with drizzle, I'm wondering if the Wasp team didn't, quite ironically, made the same mistake they pointed out on other wannabe JS full-service frameworks.
(at least, this sound a lot like tightly to me, and I'm afraid that a decision that made sense when it was made have become now tech debt we need to live with for the foreseeable future even when a much better alternative exists...)
8 Replies
Hi @Leonardo Schwartz. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Thank you for your thoughtful question about Wasp's use of Prisma instead of Drizzle. Based on the knowledge sources provided, I can offer some insights into Wasp's relationship with Prisma and their future plans.
Wasp indeed currently uses Prisma as its primary ORM and database layer. However, it's important to note that the Wasp team is aware of the limitations this imposes and has plans to expand their database support in the future.
According to the Github issue on expanding Prisma support, the Wasp team recognizes that they don't yet utilize everything Prisma offers and are tracking items they'd like to support in the future. This includes support for other databases beyond PostgreSQL, which Prisma allows.
Moreover, the Wasp team's vision, as outlined in their documentation, is to create a language that is not tightly coupled to any single implementation. They state:
"While it comes with the official implementation(s), Wasp language will not be coupled with the single implementation. Others can provide implementations that compile to different web app stacks."
This suggests that while Prisma is currently the primary database solution, the team is designing Wasp with the flexibility to potentially support other ORMs or database solutions in the future.
It's worth noting that the decision to use Prisma was likely made based on its popularity and feature set at the time. However, the Wasp team seems to be aware of the need for flexibility and adaptability in their technology choices.
While it may currently be challenging to replace Prisma with Drizzle in a Wasp project, it doesn't appear to be a permanent limitation by design. The team's vision suggests they are working towards a more flexible and adaptable framework in the long term.
That said, your concern about potential technical debt is valid and worth considering. It might be beneficial to raise this issue directly with the Wasp team, perhaps by opening a GitHub issue to discuss the possibility of supporting alternative ORMs like Drizzle in the future.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------
Sorry @Leonardo Schwartz, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist:
Perhaps try again in 15mins?
From what I remember Drizzle simply didn’t exist back then
And it’s not possible to just swap pieces of some tech in few minutes Also think about this: wasp chose Lucia for auth. Now Lucia is dead and no one could have foreseen this, there is better-auth now, but who knows if it won’t die as well? Building framework will all pieces being replaceable sounds nice, but simply impossible when framework actually provides something that you don’t have to think about. Of course with time and more abstraction it will become like laravel where auth doesn’t care what a you use, because you control flow of how things work and then you understand that Laravel is just a router with DI
And it’s not possible to just swap pieces of some tech in few minutes Also think about this: wasp chose Lucia for auth. Now Lucia is dead and no one could have foreseen this, there is better-auth now, but who knows if it won’t die as well? Building framework will all pieces being replaceable sounds nice, but simply impossible when framework actually provides something that you don’t have to think about. Of course with time and more abstraction it will become like laravel where auth doesn’t care what a you use, because you control flow of how things work and then you understand that Laravel is just a router with DI
Fecony is right, Drizzle didn't exist back when we started. Prisma was/is the most used ORM in the JS ecosystem and it made sense to use it. For the same reason we picked Postgres as our main DB, good, solid tech. Prisma proved great for us over time and we didn't really feel the need to swap it with anything else 🙂
@Leonardo Schwartz what would you say from your experience you are missing with Prisma that you have with Drizzle? I'm trying to understand if there is something we can improve in Wasp.
@Leonardo Schwartz , thanks for the input! It is awesome to hear that you read our articles, I often wonder how much people read about our vision :).
As a person that chose Prisma years ago :), I can confirm what @Fecony and @miho said -> Drizzle didn't even exist back then (at least I had no idea about it).
As for our vision of being stack agnostic vs tying ourselves to Prisma -> you are right in a way, but also what @Fecony wrote is very correct.
I will put it this way: We on purpose decided to go with specific technologies for now (React, Node, Prisma, Postgres) in order to limit our "battle front". If we make Wasp work as we want it to for this set of technologies, it is not hard to imagine it working also for Vue next to React, Bun or Deno next to Node, Drizzle next to Prisma, MySQL next to Postgres. Ok, that depends how much we tie in conceptually into these technologies, if we are super relyant on very core concept of Prisma that no other solution does then that would be an issue -> but we are being quite careful about it, even if that is not obvious from the outside immediately. We are not super heavily relying on specific parts of any of these technologies that you won't see anywhere else. Even Prisma's DSL/schema -> we had our our db model DSL that was Prisma-agnostic and we will probably bring it back, we put it aside for now to focus on other stuff. We are instead really trying to focus on being glue in between them. Not like Blitz that was based on NextJS, or Meteor that had one of main features rely on unique capabilities of minimongo.
Pinning down some of the tech in Wasp gives us space to focus on innovating on some other parts that we want to focus on now, till we get those down.
To go back to what I said -> we are making sure not to tie in too much conceptually. But, we gave ourselves some leeway to tie in implementation-wise, meaning that right now, Prisma is not an implementation of a DB interface/abstraction defined on Wasp level: instead it is indeed integrated directly with it. Why not immediately design a proper DB abstraction layer that Prisma is just one implementation of, so that we are truly agnostic? And also do similar for React as frontend library for example? Beacuse we didn't want to get ourselves entangled into guessing what this abstraction should be and then constantly fighting it, when we don't know really know enough yet -> we wanted to start with something, learn on the way, and then when we are smarter, figure out the proper abstraction. I don't think anybody can say for sure what is the right way -> sometimes, it does make sense to start with abstraction first, and I have often done that in other projects, but I always had a better idea of the domain and abstractions were simpler. So here, I prefer the approach of implementing IMPL1, then when you want to add IMPL2, is the time to look for common abstraction. Danger is that you get do tied up to IMPL1 that introducing abstraction layer becomes very tough, but I think we do have enough knowledge to have avoided that mostly. On the other hand, I don't we had enough konwledge to get the abstraction right from the first go, or even right enough, to not be PITA.
As @Fecony said, we expect Wasp to evolve in the sense that more and more of these abstractions crystalize. If I had to guess which ones are coming first, I would say Auth and Database. Entities also -> right now they are always DB models, but they could be more.
I am sorry I can't give more concrete answers, but TL;DR: You are right we are somewhat tied in impelmentation-wise, but it's not as much as it might seem, and we are careful about it, especially not to tie in too much conceptually-wise. We are in the background planning for those abstractions, and they will be coming.
Btw in the next month we plan to do a lot of brainstorming, and one part of it will be on Wasp's modularity and extensibility, of which one part will be these abstractions (especially Auth and Database since those are the clearest at the moment). So if it goes as we are planning right now, you can expect us sharing more info on our plans there, and we will likely also be asking community to chime in with their ideas, would be great to have you part of discussion there.
As for Drizzle vs Prisma, @Leonardo Schwartz I am curious because I don't know that much about Drizzle except for basics, where do you find Prisma is lacking the most?
for me when prisma dsl is a pain 😸
I didn't like it initially, but I liked the idea if new ORM, even tho it lacked json, tools, and some other stuff, like bringing new pain with migrations
with drizzle you still have migrations, and your table schemas depends on what db you use, each
drizzle/<db-adapter> has its own definition syntax and it's a pain..
yet it's not separate file with it's own dsl
also thinking about this, "lapsa" I was working on is implemented in react, if there will be new UI, I would have to rewrite it some way to work on vue (for example) so have 2 copies... maybe Astro approach of different ui's would fit Wasp in this terms, so future libraries are not dependant on any implementation, and won't die cause of some new ui feature@martinsos thanks so much for taking the time to share your thought process in such detail. From an engineering point of view I wholeheartedly agree with all of those decisions. I personally really dislike adding abstractions where there are no needed, and it's something I'm very weary of when I consider a library for instance (case in point: I absolutely despise Langchain, and cannot understand how they became kind of the standard!)
In regards to Drizzle, and this is also to respond to @miho 's question, there are several things, some subjective but some pretty objective and widely agreed upon:
The subjective one:
- I like drizzle syntax much more. Even if more verbose, it closely resembles the actual SQL query that's being built.
The not-so-subjective ones:
- Drizzle actually allows you to use the actual specific DB driver you need under the hood, which is not only faster and more efficient in most cases, but also gives you perfect compatibility with specific flavors of, let's say, postgres (neon, etc), sqlite (turso, D1 for instance is a must for me), etc.
- Drizzle is much more flexible than Prisma. With Prisma you can only do what the Prisma engine allows you to do, but Drizzle on the other hand, if you can do something in raw SQL then you can do it with Drizzle. Most apps might not need this flexibility, but then if you hit a edge case down the road where you need it and Prisma doesn't support it... you're out of luck.
- Of course you can do raw SQL with Prisma if needed, but then you lose the type safely. With Drizzle it's all type-safe end-to-end.
- Finally, the elephant in the room: Drizzle is MUCH MORE performant than Prisma, and will likely always be, since it's just a light layer of typescript over the native DB driver, while Prisma has to ship a full query engine to process their DSL.
- Also, for what I heard, while Drizzle dispatches any query (even complex queries with unions, joints, etc) as a single SQL query to the DB, Prisma may convert those into a bunch of queries instead (which is problematic on their own right, specially in serverless environments)
For a short and technical explanation: https://www.youtube.com/watch?v=Xk43fwSQ8No
For a really balanced comparison of both ORMs: https://www.youtube.com/watch?v=cTu9-C2rd-0
This is another unbiased comparison of the two: https://blog.logrocket.com/drizzle-vs-prisma-which-orm-is-best/
For performance benchmarks under different loads: https://orm.drizzle.team/benchmarks
Finally, I want to say that I did indeed read several of your articles and enjoyed then and shared the vision... that's why I'm here!
And yes, I honestly hate React and would have never considered using it. Sveltekit is so much more elegant and make sense to my brain. However, I came around and started looking back into Nextjs for a simple reason: nowadays most of the code we write is written by LLMs, and LLMs are usually much better at React and Nextjs simply because these are the most popular frameworks online.
DX is a must when you're writing the code, and as I say, I promised myself I wouldn't go back to write React.. EVER. But now if you want to be productive with ai coding agents like Windsurf or Cursor it makes sense to use what's more likely to produce less errors for the coding agent. I'm insisting on this because I think this is something that's not talked about enough, but I honestly think than within 2 years most of these abstractions we have created to make our life easier when coding (frameworks, ORMs and even programming languages) will be completely unneeded and so irrelevant.
All of this is understandable why drizzle is better
But… here we are :boifather2:
Yes, I perfectly understand the reasons why. Unfortunately I was looking for a SAAS starter kit I could quickly build on, but I guess I'll have to create my own on top of nextjs. Drizzle is a must for me, and also need a stack with full support for cloudflare workers, D1 and other cloudflare technologies. Love the vision and the project though!