Drizzle is pretty great. I spent so much time fighting with prisma do get it to do what I wanted. Although I did have to write a library worth of custom types for drizzle , i was able to get it working
Yes, the author should be passing an array of values to db.insert(productDiscountCode).values() in the drizzle example. To be fair to Prisma, it's also possible to separate productIds into a call to db.productDiscountCode.createMany() rather than using the connect syntax.
@@xavier.whisper.underneath Behind the scenes, it's still creating all those queries for every inserted object, so it's still N+1, but from the perspective of a developer, it doesn't look like it. With Drizzle, you immediately see it
ORMs like Prisma etc. generate large files when you have 100s of relational tables. Specially when you use extra plugins for validations and such, it quickly starts to unravel. Best for smaller apps with less than 30 tables. The amount of code / metadata generated by Prisma and other plugins is humungous.
I like that point of view. We mostly read people having a very black/white view on things. One is good other is bad. For me as a solo dev in a project I prefer the simplicity and DX of prisma, drizzle syntax is a lot more complex imo, but I can see how it's better at bigger or different types of projects.
@@prawnstars3160 I think the whole point of Prisma was DX. Meaning it abstracts a lot of complication mainly from the model definition and does it for you, like for example creating many to many relations being literally just 2 different lines, it's so easy to do and to read/analyse. But if I hit speed bottlenecks in the future I'd gladly switch to drizzle
Drizzle is the first ORM I've used. I like that it uses TypeScript instead of Prisma's own solution, and that it's closer to SQL. However, I believe it's not mature enough yet to implement it in a big project in a productive way. I spent a couple of days setting up Drizzle with NextAuth, only to find out that the Drizzle Adapter doesn't implement some features Prisma offers out of the box , which would have saved me lots of time.
I've fought so much with Prisma to get performance in cases of join. Ended up writing my own statement cuz Prisma does join very inefficiently with on and stuff. Hope this solves it!
Because there are still things only SQL can do like common table expressions, views and stored functions which are super useful for complex queries ruclips.net/user/shortsjLcbLVaz4ms
so far only thing that feels strange in drizzle is pgTable and other such staff like if i want to change database i would have to siginifically change my code.
While I knew just about all of this already, it's great to see your examples and explanation for people that didn't and are just trying to pick their ORM. Great video!
Kyle, do you know if Drizzle also has performance gains for row reading? From what I know Prisma reads all rows from a given table, then filters the request data in its Rust binaries. It can be costly. Does Drizzle only read the rows specified in a given query?
@@KennEjima Awesome! This is the performance I was looking for! I have little knowledge in SQL, so I will keep starting my projects using Prisma, then migrate to Drizzle for production.
Prisma don't scan all the table every time. It create a query with all condition you determine. Prisma can ignore distinct field and filter it only in Rust. Also Prisma don't create joins and filter by joins only in Rust after 2 sequential queries. But these cases are the only, for usual crud operations Prisma create a corresponding query with your filter conditionz
Wouldn't call Prisma declarative, you're still creating rows and such yourself, it's just a little bit more declarative since you can for example add children directly when creating a row. If you want a declarative ORM you might want to take a look at MikroORM.
@@BeBoBE I think you dont know what declarative means. In Prisma you just need to declare what you want the row to be created. In Drizzle you are imperatively doing the creation of the row.
For God, no!!!! I used to have Kysely + Prisma in my projects, and now I have SO MANY PERFORMANCE PROBLEMS that I could not recommend it to anyone! It is serious, man, stop, just stop, it will kill you. Please, PLEASE, NOOOOO!
@@jonnyborgesdevperformance problem how ? With that combo you would ONLY use prisma migrate system with its schema file (so no touching prisma client) and then it's just sql with kysely? How on earth would you run into performance problems with just sql? Did you also use prisma to do things which defeat the purpose of kysely ???
@@jonnyborgesdev Elaborate? I find Kysely + Prisma to be the best combination we've ever used in a project. and the performance increased a lot more than using plain prisma
@@akash-kumar737I'm late but performance isn't worth it if you're going to rebuild all the relations you need. That's why I went with Prisma rather than drizzle. Drizzle's query API feels incomplete
Just when you feel like you learned something good enough, something new comes up(not saying it in a bad way but we need the urge to learn constantly in this field)
From some times I start to use objection-js as orm and knex-js as query builder if I need low level control. Also there is Kysely from creator of objection, but I dont used it before
I don’t have much experience with node backends(the only project I’ve worked on used kysely), I haven’t used drizzle nor prisma, but looking at your examples I see why people might want to use prisma and why I already hate it. Drizzle seems to be much more like an actual query builder as opposed to prisma which tries to abstract away everything. Having worked with such solutions in other languages it was always great until the abstractions broke in unexpected ways, like hibernate generating a few hounded joins where two would suffice
Thanks a lot for the great video… Please consider creating a short tutorial on implementing live updates (real time) notifications for a very simple social media functionality like (some liked your post). Simple app the aim of which is to show how to implement notifications (not chat app) in Nextjs 14 with the server actions. TS optional but preferable! 😅
As someone who moved over from Prisma to Drizzle, it mostly came down to Prisma's horrible SQL perf and the overall level of "magic" it uses to power its DX. Prisma's "magic" also doesn't play well in production, with serverless environments and mono-repos either, because of how it needs to generate individual underlying Rust engines and generate the typescript types off of that before you even get to the "tsc build" step of your app. I'm not saying that it can't be done, but it is a 'non-zero' amount of time which can feel horrible when applied to a real production codebase. Contrast this with Drizzle where it's all just typescript... that's it. Also, as you start writing bigger apps with beefy databases, and you start running more complex queries on your DBs, I've found that the overhead required to run my queries through Prisma just isn't worth the performance hit that I end up taking. Running a Prisma query has the following overall flow: Send an instruction from the JS-layer to the Rust engine, hopefully the engine generates something close to a performant SQL statement-set, execute the _statements_ in the engine, get the response and parse it in the engine, and finally return the validated response to the JS-layer. With Drizzle, I'm really just running an "SQL statement"... that's it.
"Just use SQL" is my least favorite take in software development. I don't understand how you can stomach the DX of plain SQL when there is an intuitive, readable, popular, type-safe ORM available (Prisma) that hardly takes any time to learn or understand. Literally just compare the queries! There's not even an argument for me
The syntax for defining tables and relations in Prisma seems like almost equivalent to SQL. If you write SQL first, and have an ORM with code generator for the sake of generating type safe models, you can extract more out of your database's capabilities, while still getting the DX benefits.
I love the t3 stack (create-t3-app ftw!) so of course I tried drizzle when they added it as the preferred ORM for the stack and I felt SO much more friction when using it compared to prisma. I really appreciate your breakdown as it helps me see a few of the benefits that I couldn't quite see from the depths of learning curve hell.
Yes. You can do multiple inserts in one statement. That would be better, but this repo was purely a demo that I was using to learn/compare Drizzle to Prisma so this was pretty quick and dirty.
That Prisma uses it's own weird rust engine and doesn't just do single queries, doesn't allow you to do left, right joins, etc. should be a non starter. Just learn SQL and use Drizzle
OK, so if you are building a portfolio project or just starting out use Prisma, but if you're building for production, then you'll have to use Drizzle. By the looks of it Prisma would be a nightmare while the system scales.
If 10% more code means I can have control and speed, drizzle all the way for me. I've experienced enough of Prisma's definition mismatch due to delayed codegen to be a loving fan.
1: Yes it supports it, just add @default(uuid()) but you SHOULDN'T. There is no single good reason for you to use uuid in 2024, Prisma supports cuid too (which is better than uuid in literally everything). I use Snowflake, and I have prism.$extends to add support for it, because Snowflake is better for larger systems, but cuid is good enough for all types of systems, and uuid or autoincrement are not good for anything.
HI, can i ask you one question? (if u do this stuff) How you manage filter paramas in a GET request? how you work with operators? like in prisma you can simply use NOT:{id:3} , {age:{lte:18}}, ecc. In sequelize you have like Op.gt, Op.in ecc.. But you can't use them from the client or im wrong? When request is static and with same filters its ok, but like my clients have a feature like visual query builder, and always be boring with other orms to manage the request params Thanks
@@mrika1995 i have a mapping for my request params and my table columns for example i use something like route/?gender=not_male and in the code handle the validation of query separately
@@mokshchadha9151 Can you make me an esemple with more complex/nested object filter? how the server understand not_ or_ gte_ ecc? like if includes("_")? Thanks
can you please do another video on Prisma's typedSQL , prisma pulse and prisma accelerate there isn't much content on them other than prisma's YT channel which of course will be biased
You don't. But once you grow your team to more than one person, or you deploy several iterations of your application, then you'll see the value of migrations. It's OK to start small, learn the essentials, feel the pain, and then add more sophisticated tools to your toolbelt.
Hi Guys, One problem in my eyes is the TypeScript support. Prisma's TypeScript support is at version 4.7.0 but my project is running version 5.3.3. Prisma has a better DX for me than Drizzle when it comes to complex queries, and I have really complex queries in my project. I don't want to write raw SQL, and the limitations of Prisma are completely okay for my queries. However, if I cannot fix the TypeScript problem, I cannot use it due to missing type safety. Am I the only one who is struggling with this? It would be nice if you could give me some advice. @web
I really wanted to like Prisma, but I couldn’t get its rust-powered tooling build/migrate on a remote CI/CD pipeline in conjunction with Turborepo. Drizzle is a happy medium and has the big benefit of just being a JavaScript library.
@@hanserlabber4164 The relative pathing to the prisma binaries would break (ex. @packages/db), which I got around with some build-scripts. But the dagger was npm install would install a binary that was incompatible with the target linux env of my build agent. It all worked great locally inside a docker dev container. So if you have the ability to deploy as containers I bet it would work better. I didn't have that option unfortunately.
So, I played with both for about 2 weeks. Drizzle is not ready for prod IMO. The combination of lack of docs, the current state of the docs (you will find conflicting instructions because it is evolving so fast, and no 2 articles will even show you the same thing, and even this video is guilty of this), the likelihood of things changing significantly, and their focus on things that do not matter (like, use dbeaver or similar to look at your databases, this is a stable tool with every bell and whistle you could ever want, for free) make me want to wait till 1.2 or later. Its a neat idea and IMO a better approach and syntax, but its not there yet.
With prisma you get 50% of performance... i think it's the same with drizzle. When you have complicate query, orm will fail. I tried prisma and now i use raw sql query.
Prisma provides you with a nice DX but that's where the positives end for me, their weird rust engine is so bad for performance when working with any reasonable amount of data. That and the fact is ships with a big binary is problem. I also much prefer writing my schema in typescript than prismas own schema language, the fact its marginally more verbose is a small price to pay for the flexibility it gives you
While prisma can work with all kinda dbs, seems like drizzle was specifically made for relationsal databases. As it's syntax is pretty similar to the sql. Well, imo until you need more control over your queries whic you won't need that often, prisma is fine. Prisma is good enough to handle everything, easy to use and pretty straight forward. Btw these js ORMs are not anywhere close to the C#'s EFCore.
I think drizzle inspired by Laravel ORM and Prisma inspired by Django ORM. php developer could love drizzle other side Python developer should love prisma
- prisma doesnt work on some serverless environments, like supabase, because the underline engine connects to dbs though a tcp connection and deno in edge function doesnt have a tcp engine. - to address that, and i assume similar issues, they have created accelerate, which prisma successfully connects to through https, and its like a cache level for you db from what i understand. - accelerate costs more money, so i dont see it as a selling point, they couldve fixed thr underlying issue -_- Just use drizzle tbh
Let's say I have a full-fledged, complex E-commerce Backend and Frontend. With the whole management scenario, this backend allows to manage multiple stores and allows to add new ones. Which ORM would be better for this? If I learn it now, I want to understand if it will benefit me in the 1-2 month project I want to start.
You can flip a coin or make a cost benefit table. Prisma is convinient, hit the ground running and dx is great save for ts types if you need that. Drizzle will give you types But can get in your way for minor times when you have type mismatch or if you are using validations. Either works. Pick your poison. Want to eat noodles with a fork or chopsticks?
I dont understand why devs of prisma or drizzle dont want to implement DSL in migrations. Native sql in migrations is such kringzh. So, I think that sequelize and typeorm are much better.
I feel the description of the developer experience is biased towards prisma not for technical superiority but for personal design preference. Prisma is more abstracted than drizzle, which is highlighted again an again as being preferable, but this isn't objectively true. I get confused when something is abstracted so much that it works in a completely new way as opposed to something which is longer but simpler to understand or at least closer to the technology which is being abstracted, which I have previously spent the time to undertand. I spend more time thinking and reading (whether it's docs or code) than typing when coding, so is having something which is harder to understand(unless researched thoroughly) but less lines of code always better? Well that's your own opinion and should be represented as such. Not as a fact
Honestly, what is the use of any of these, over just writing queries? Tried Prisma once and it was just super slow and bureaucratic, only delaying the project.
These simplify most of the queries you write, which enable you to work on projects faster without much of performance tradeoffs, for complex and performance requiring functionalities, using SQL queries might be the way to go.
Bro if you're reading this comment, can you please make a video on how to use state management libraries like Redux and Zustand in Next.js 14? The tutorials I found were based on Next.js 13 and didn't help me understand much. The concept of having a per-request store is really confusing. I don't really understand why you'd need to do such a thing. Also server-side rendering makes it even more difficult to understand.
@@MerkieAEEven if we only try to use them in client components the problem is that you can't create a global store. This means that your stores can only be per-request, meaning per-route. But I don't understand why would we need to do that.
There's a really great ORM that sits somewhere between drizzle (query builder) and Prisma (high-level data management) - it's called objection.js. It nails down the ORM part, it deals well with relations, it's bullet proof. The only thing it lacks is the nice Typescript support (many things are just strings).
I’m a visual learner do you know of any VS code extensions that will allow me to visualize program flow of typescript either on desktop or in VR quest three? I work in Angular so typescript.
Why do we need either? Why use another black box that polutes the code, when Node or PHP can connect and talk to any DB? SQL no NOSQL? I don't get it. If datatype safety, null safety and Data modeling are the concern Typescript and Dart can do that already.
Kysely is great for a smaller project if you want to just focus on the queries that get data with a simple type-safe query builder, without much overhead and stuff. If you have a complicated db with a lot of relationships between entities and need ORM features like easy migrations, better and stronger type-safety - DrizzleORM is definitely the choice
@@DarkzarichV2 In my experience ORM's are great for very simple crud style queries and fail on the more complex joins. This is especially bad if you rely on typed query responses as switching to raw queries requires manually typing the response.
Really prisma schema is better?, tell me how can u create functional index, generated columns, index part of column, index hash in prisma. Man prisma is for hobby projects
I don’t see any reason to use prisma or drizzle.. both would make work with the database more komplex for no reason. Prisma has just one big schema file?! Why?! Imagine building a GraphQL backend and being in need to create a DB schema, a graphql schema and types for that and have to sync all that stuff manually, because your ORM wants to keep everything in a big schema file… Imagine just using typeORM with type-graphQL and use just one file per model to get all in one place with much smaller code footprint for relations and so on… I don’t get why ppl go for more complex solutions just because of more complexity.
Drizzle is pretty great. I spent so much time fighting with prisma do get it to do what I wanted. Although I did have to write a library worth of custom types for drizzle , i was able to get it working
thats what copilot is for
@@snipernosnipey8162Copilot is unreliable lol
Waiting for a new Prizzle ORM after a few weeks 🥴
Just go the Laravel bubble for 2 week and you will find this thing absolutely trash
rizzma
@@flavourfulski ligma
Thank you for your thorough research. I needed the expert's opinion about those two.
Expert is a big word
haha calling someone an expert who talks about ORM xD Learn SQL kiddo
The code for product discounts at 10:22 is an N+1 query which is bad. Drizzle’s lack of magic makes it more clear what’s going on behind the scenes
Is the way Prisma is doing avoiding N+1 query or not really?
@@xavier.whisper.underneath not really
@@xavier.whisper.underneath not really
Yes, the author should be passing an array of values to db.insert(productDiscountCode).values() in the drizzle example.
To be fair to Prisma, it's also possible to separate productIds into a call to db.productDiscountCode.createMany() rather than using the connect syntax.
@@xavier.whisper.underneath Behind the scenes, it's still creating all those queries for every inserted object, so it's still N+1, but from the perspective of a developer, it doesn't look like it. With Drizzle, you immediately see it
Kysely as query builder, and Prisma for studio/schemas/migrations ✅
such an unpopular opinion
dude just use something stop overcomplicating stuff
Query builders suck. Either use ORM or don't.
ORMs like Prisma etc. generate large files when you have 100s of relational tables. Specially when you use extra plugins for validations and such, it quickly starts to unravel. Best for smaller apps with less than 30 tables. The amount of code / metadata generated by Prisma and other plugins is humungous.
I like that point of view. We mostly read people having a very black/white view on things. One is good other is bad. For me as a solo dev in a project I prefer the simplicity and DX of prisma, drizzle syntax is a lot more complex imo, but I can see how it's better at bigger or different types of projects.
@@0.amonymous
drizzle syntax literally looks like standard SQL. dunno what u mean by more 'complex'
@@prawnstars3160 I think the whole point of Prisma was DX. Meaning it abstracts a lot of complication mainly from the model definition and does it for you, like for example creating many to many relations being literally just 2 different lines, it's so easy to do and to read/analyse. But if I hit speed bottlenecks in the future I'd gladly switch to drizzle
Drizzle is the first ORM I've used. I like that it uses TypeScript instead of Prisma's own solution, and that it's closer to SQL. However, I believe it's not mature enough yet to implement it in a big project in a productive way. I spent a couple of days setting up Drizzle with NextAuth, only to find out that the Drizzle Adapter doesn't implement some features Prisma offers out of the box , which would have saved me lots of time.
Will be implementing nextauth adapter soon, what issues di you face with drizzle?
yep, and I prefer the syntax of Prisma. easy to understand
I don't know if Drizzle follows the semver, but the version is not yet 1.0.0, which usually means "ready for production".
Drizzle is not an ORM.
Looking forward to the drizzle crash course!
I've fought so much with Prisma to get performance in cases of join. Ended up writing my own statement cuz Prisma does join very inefficiently with on and stuff. Hope this solves it!
I've seen my guys videos for a while now and i just noticed how much he wobbles his head left and right constantly, now i cannot stop seeing it
bobblehead
thanks, now i can't unsee it
Why learn SQL when you can learn a dozen ORMs instead?
Because there are still things only SQL can do like common table expressions, views and stored functions which are super useful for complex queries ruclips.net/user/shortsjLcbLVaz4ms
So true 😂
Why use ORMs for autocompletion, type safety, faster development, better development experience, scalebility... When you can use raw SQL 🤡
Just raw dog it bro 😂
good trolling
so far only thing that feels strange in drizzle is pgTable and other such staff like if i want to change database i would have to siginifically change my code.
The insert method of Drizzle ORM also accepts arrays, allowing you to insert multiple discounts...
I did not know this… Thanks bro!
Exactly!
An excellent comparison. Thanks!
While I knew just about all of this already, it's great to see your examples and explanation for people that didn't and are just trying to pick their ORM. Great video!
Kyle, do you know if Drizzle also has performance gains for row reading? From what I know Prisma reads all rows from a given table, then filters the request data in its Rust binaries. It can be costly.
Does Drizzle only read the rows specified in a given query?
Yes. Better yet, Drizzle guarantees a single call always results in a single SQL.
@@KennEjima Awesome! This is the performance I was looking for! I have little knowledge in SQL, so I will keep starting my projects using Prisma, then migrate to Drizzle for production.
Prisma don't scan all the table every time. It create a query with all condition you determine.
Prisma can ignore distinct field and filter it only in Rust. Also Prisma don't create joins and filter by joins only in Rust after 2 sequential queries. But these cases are the only, for usual crud operations Prisma create a corresponding query with your filter conditionz
Love your vids!!! Please create a video: "How to convert from prisma to drizzle orm in latest Next.js LTS with absolutely zero issues!"
A good example of Imperative vs Declarative syntax.
Wouldn't call Prisma declarative, you're still creating rows and such yourself, it's just a little bit more declarative since you can for example add children directly when creating a row. If you want a declarative ORM you might want to take a look at MikroORM.
@@BeBoBE I think you dont know what declarative means. In Prisma you just need to declare what you want the row to be created. In Drizzle you are imperatively doing the creation of the row.
As a front end developer I have never heard of any of this
Thank you, Kyle.
I'm liking Kysely + Prisma. Although you can argue that it's a lot of overhead
Why, why whyyyyyyyy
For God, no!!!! I used to have Kysely + Prisma in my projects, and now I have SO MANY PERFORMANCE PROBLEMS that I could not recommend it to anyone! It is serious, man, stop, just stop, it will kill you. Please, PLEASE, NOOOOO!
@@jonnyborgesdevperformance problem how ? With that combo you would ONLY use prisma migrate system with its schema file (so no touching prisma client) and then it's just sql with kysely?
How on earth would you run into performance problems with just sql? Did you also use prisma to do things which defeat the purpose of kysely ???
then it is ok@@congminhluu5068
@@jonnyborgesdev Elaborate? I find Kysely + Prisma to be the best combination we've ever used in a project. and the performance increased a lot more than using plain prisma
Finally someone showed what a DX nightmare Drizzle is, especially when it comes to relations. It is a deal breaker to me.
What your thoughts on Prisma which struggle with performance and perform unwanted queries for join statements.
@@akash-kumar737It does not really matter unless you are working on a very large scale.
@@akash-kumar737I'm late but performance isn't worth it if you're going to rebuild all the relations you need. That's why I went with Prisma rather than drizzle. Drizzle's query API feels incomplete
Just when you feel like you learned something good enough, something new comes up(not saying it in a bad way but we need the urge to learn constantly in this field)
You don’t have to learn all the new tech
Got recommended drizzle to me. I had never heard of otr
From some times I start to use objection-js as orm and knex-js as query builder if I need low level control. Also there is Kysely from creator of objection, but I dont used it before
Prisma has always been weird. Typeorm has been serving us very well for years. Drizzle is just like a slightly lower level typeorm.
I use Kysely. It's the best. And prisma for schema and migrations.
I don’t have much experience with node backends(the only project I’ve worked on used kysely), I haven’t used drizzle nor prisma, but looking at your examples I see why people might want to use prisma and why I already hate it. Drizzle seems to be much more like an actual query builder as opposed to prisma which tries to abstract away everything. Having worked with such solutions in other languages it was always great until the abstractions broke in unexpected ways, like hibernate generating a few hounded joins where two would suffice
Thanks a lot for the great video… Please consider creating a short tutorial on implementing live updates (real time) notifications for a very simple social media functionality like (some liked your post). Simple app the aim of which is to show how to implement notifications (not chat app) in Nextjs 14 with the server actions. TS optional but preferable! 😅
pusher
As someone who moved over from Prisma to Drizzle, it mostly came down to Prisma's horrible SQL perf and the overall level of "magic" it uses to power its DX.
Prisma's "magic" also doesn't play well in production, with serverless environments and mono-repos either, because of how it needs to generate individual underlying Rust engines and generate the typescript types off of that before you even get to the "tsc build" step of your app. I'm not saying that it can't be done, but it is a 'non-zero' amount of time which can feel horrible when applied to a real production codebase. Contrast this with Drizzle where it's all just typescript... that's it.
Also, as you start writing bigger apps with beefy databases, and you start running more complex queries on your DBs, I've found that the overhead required to run my queries through Prisma just isn't worth the performance hit that I end up taking.
Running a Prisma query has the following overall flow: Send an instruction from the JS-layer to the Rust engine, hopefully the engine generates something close to a performant SQL statement-set, execute the _statements_ in the engine, get the response and parse it in the engine, and finally return the validated response to the JS-layer. With Drizzle, I'm really just running an "SQL statement"... that's it.
Real man write queries 💪
Only thing I like from them is studio.
I use DataGrip
"Just use SQL" is my least favorite take in software development. I don't understand how you can stomach the DX of plain SQL when there is an intuitive, readable, popular, type-safe ORM available (Prisma) that hardly takes any time to learn or understand.
Literally just compare the queries! There's not even an argument for me
The syntax for defining tables and relations in Prisma seems like almost equivalent to SQL.
If you write SQL first, and have an ORM with code generator for the sake of generating type safe models, you can extract more out of your database's capabilities, while still getting the DX benefits.
I love the t3 stack (create-t3-app ftw!) so of course I tried drizzle when they added it as the preferred ORM for the stack and I felt SO much more friction when using it compared to prisma. I really appreciate your breakdown as it helps me see a few of the benefits that I couldn't quite see from the depths of learning curve hell.
hey Kyle, when is the big video coming that u talked about in ur previous video
im eagerly waiting
10:35 didn’t drizzle let you do multiple insert? It’s way better than calling insert multiple times
Yes. You can do multiple inserts in one statement. That would be better, but this repo was purely a demo that I was using to learn/compare Drizzle to Prisma so this was pretty quick and dirty.
@@WebDevSimplified fair enough, great content!
That Prisma uses it's own weird rust engine and doesn't just do single queries, doesn't allow you to do left, right joins, etc. should be a non starter. Just learn SQL and use Drizzle
Half of your sentence is outdated if I am not mistaken, give it a look. They sorted many of the stuff you mentioned.
ORM's are a bit too invasive for me. A good Query Builder (Kysely) has the same benefits but stays closer to SQL and doesn't take over your project.
These aren't ORMs.
OK, so if you are building a portfolio project or just starting out use Prisma, but if you're building for production, then you'll have to use Drizzle. By the looks of it Prisma would be a nightmare while the system scales.
ok can you explain how?
If 10% more code means I can have control and speed, drizzle all the way for me. I've experienced enough of Prisma's definition mismatch due to delayed codegen to be a loving fan.
Hi I have an idea 💡 can you create youtube video downloaded using javascript? I hope hear from you
Orchid ORM has entered the chat
Drizzle also have query like prisma interface like find in prisma isn't it. On query not insert update and delete.
Great video!
does prisma supprot uuid in postgres ? can u do an exemple
1: Yes it supports it, just add @default(uuid()) but you SHOULDN'T. There is no single good reason for you to use uuid in 2024, Prisma supports cuid too (which is better than uuid in literally everything). I use Snowflake, and I have prism.$extends to add support for it, because Snowflake is better for larger systems, but cuid is good enough for all types of systems, and uuid or autoincrement are not good for anything.
Hey can you help me in my build about prisma getting some errors aint getting what the heck are they.
Drizzle is the way to go. If you are not comfortable with the SQL like syntax, you can use the query.
Haven't tried it yet because I heard they truncate tables a lot when running migration
Which is better prisma and drizzle
I like the ease of use and simplicity of Prisma.
which is better prisma or drizzle
me still using sequalize
HI, can i ask you one question? (if u do this stuff)
How you manage filter paramas in a GET request? how you work with operators?
like in prisma you can simply use NOT:{id:3} , {age:{lte:18}}, ecc.
In sequelize you have like Op.gt, Op.in ecc.. But you can't use them from the client or im wrong?
When request is static and with same filters its ok, but like my clients have a feature like visual query builder, and always be boring with other orms to manage the request params
Thanks
@@mrika1995 i have a mapping for my request params and my table columns for example i use something like
route/?gender=not_male
and in the code handle the validation of query separately
@@mokshchadha9151 Can you make me an esemple with more complex/nested object filter?
how the server understand not_ or_ gte_ ecc? like if includes("_")?
Thanks
can you please do another video on Prisma's typedSQL , prisma pulse and prisma accelerate there isn't much content on them other than prisma's YT channel which of course will be biased
I find the migration stuff confusing. If I already have a database and I just want Drizzle to connect to it, do I need that?
You don't.
But once you grow your team to more than one person, or you deploy several iterations of your application, then you'll see the value of migrations.
It's OK to start small, learn the essentials, feel the pain, and then add more sophisticated tools to your toolbelt.
Drizzle kit can introspect an existing database to create a schema I believe
Hi Guys, One problem in my eyes is the TypeScript support. Prisma's TypeScript support is at version 4.7.0 but my project is running version 5.3.3.
Prisma has a better DX for me than Drizzle when it comes to complex queries, and I have really complex queries in my project. I don't want to write raw SQL, and the limitations of Prisma are completely okay for my queries. However, if I cannot fix the TypeScript problem, I cannot use it due to missing type safety.
Am I the only one who is struggling with this? It would be nice if you could give me some advice. @web
Oh I think the Problem IS only in 5.3 or so ... Because 4.7.x should be the Minimum requirement. Some one Test IT with some 5.x Version?
I really wanted to like Prisma, but I couldn’t get its rust-powered tooling build/migrate on a remote CI/CD pipeline in conjunction with Turborepo. Drizzle is a happy medium and has the big benefit of just being a JavaScript library.
What is your exact Problem (I am also using turborepo in my project)
@@hanserlabber4164 The relative pathing to the prisma binaries would break (ex. @packages/db), which I got around with some build-scripts. But the dagger was npm install would install a binary that was incompatible with the target linux env of my build agent.
It all worked great locally inside a docker dev container. So if you have the ability to deploy as containers I bet it would work better. I didn't have that option unfortunately.
So, I played with both for about 2 weeks. Drizzle is not ready for prod IMO. The combination of lack of docs, the current state of the docs (you will find conflicting instructions because it is evolving so fast, and no 2 articles will even show you the same thing, and even this video is guilty of this), the likelihood of things changing significantly, and their focus on things that do not matter (like, use dbeaver or similar to look at your databases, this is a stable tool with every bell and whistle you could ever want, for free) make me want to wait till 1.2 or later. Its a neat idea and IMO a better approach and syntax, but its not there yet.
With prisma you get 50% of performance... i think it's the same with drizzle. When you have complicate query, orm will fail. I tried prisma and now i use raw sql query.
Prisma provides you with a nice DX but that's where the positives end for me, their weird rust engine is so bad for performance when working with any reasonable amount of data. That and the fact is ships with a big binary is problem. I also much prefer writing my schema in typescript than prismas own schema language, the fact its marginally more verbose is a small price to pay for the flexibility it gives you
While prisma can work with all kinda dbs, seems like drizzle was specifically made for relationsal databases. As it's syntax is pretty similar to the sql. Well, imo until you need more control over your queries whic you won't need that often, prisma is fine. Prisma is good enough to handle everything, easy to use and pretty straight forward.
Btw these js ORMs are not anywhere close to the C#'s EFCore.
Sad that C# is unloved, js is so far behind in terms of framework and libraries
Just imagine how cool is laravel
Really is way ahead of time😊
I think drizzle inspired by Laravel ORM and Prisma inspired by Django ORM. php developer could love drizzle other side Python developer should love prisma
- prisma doesnt work on some serverless environments, like supabase, because the underline engine connects to dbs though a tcp connection and deno in edge function doesnt have a tcp engine.
- to address that, and i assume similar issues, they have created accelerate, which prisma successfully connects to through https, and its like a cache level for you db from what i understand.
- accelerate costs more money, so i dont see it as a selling point, they couldve fixed thr underlying issue -_-
Just use drizzle tbh
Don't mind them
Let's say I have a full-fledged, complex E-commerce Backend and Frontend. With the whole management scenario, this backend allows to manage multiple stores and allows to add new ones. Which ORM would be better for this? If I learn it now, I want to understand if it will benefit me in the 1-2 month project I want to start.
You can flip a coin or make a cost benefit table. Prisma is convinient, hit the ground running and dx is great save for ts types if you need that. Drizzle will give you types But can get in your way for minor times when you have type mismatch or if you are using validations. Either works. Pick your poison. Want to eat noodles with a fork or chopsticks?
Why don't just use sql?
What about typesafety, readability and coding fast
what makes you think using sql makes coding slower? You just saying things just for sake of opposing aren't you..
Sticking to sequelize for sql databases. It’s all I need.
Lesgooo Drizzllleeee!!!
Am I the only Guy here that amazed that a ORM send more than 1 query?.. like why the hell they designed it differently.
When learning ORMs is harder than learning SQL query 🤓
yes it is
the simpler, the better. prisma wins in about 90%+ of cases
Man, if prisma is simpler and better, I dont wanna get near drizzle.
I love TypeORM!
great video ....... but how u can provide a valid comparison without talking about MIGRATIONS
I dont understand why devs of prisma or drizzle dont want to implement DSL in migrations. Native sql in migrations is such kringzh. So, I think that sequelize and typeorm are much better.
I feel the description of the developer experience is biased towards prisma not for technical superiority but for personal design preference. Prisma is more abstracted than drizzle, which is highlighted again an again as being preferable, but this isn't objectively true. I get confused when something is abstracted so much that it works in a completely new way as opposed to something which is longer but simpler to understand or at least closer to the technology which is being abstracted, which I have previously spent the time to undertand. I spend more time thinking and reading (whether it's docs or code) than typing when coding, so is having something which is harder to understand(unless researched thoroughly) but less lines of code always better? Well that's your own opinion and should be represented as such. Not as a fact
Honestly, what is the use of any of these, over just writing queries? Tried Prisma once and it was just super slow and bureaucratic, only delaying the project.
These simplify most of the queries you write, which enable you to work on projects faster without much of performance tradeoffs, for complex and performance requiring functionalities, using SQL queries might be the way to go.
Safety??????
@@jonnyborgesdev safety in what sense?
Bro if you're reading this comment, can you please make a video on how to use state management libraries like Redux and Zustand in Next.js 14? The tutorials I found were based on Next.js 13 and didn't help me understand much. The concept of having a per-request store is really confusing. I don't really understand why you'd need to do such a thing. Also server-side rendering makes it even more difficult to understand.
Jotai has next 14 support. For the others, just keep the usage of them in client components and you should be good. Hopefully he makes a video soon
@@MerkieAEEven if we only try to use them in client components the problem is that you can't create a global store. This means that your stores can only be per-request, meaning per-route. But I don't understand why would we need to do that.
I will still be rooting for Prisma
Do you think it’s still worth to learn to code with Devin coming in?
I answer this exact question in the video coming out later today.
TypeORM ++
There's a really great ORM that sits somewhere between drizzle (query builder) and Prisma (high-level data management) - it's called objection.js. It nails down the ORM part, it deals well with relations, it's bullet proof. The only thing it lacks is the nice Typescript support (many things are just strings).
Creator of Objection.js has left the project. He started Kysely to replace Objection.js.
Drizzma & Prizzle
I like this just waiting for sql server to be implemented then I can drop prisma lol
I’m a visual learner do you know of any VS code extensions that will allow me to visualize program flow of typescript either on desktop or in VR quest three? I work in Angular so typescript.
Why do we need either? Why use another black box that polutes the code, when Node or PHP can connect and talk to any DB? SQL no NOSQL? I don't get it. If datatype safety, null safety and Data modeling are the concern Typescript and Dart can do that already.
But Kyle...
we have Kysely...
Kysely is great for a smaller project if you want to just focus on the queries that get data with a simple type-safe query builder, without much overhead and stuff.
If you have a complicated db with a lot of relationships between entities and need ORM features like easy migrations, better and stronger type-safety - DrizzleORM is definitely the choice
@@DarkzarichV2 In my experience ORM's are great for very simple crud style queries and fail on the more complex joins. This is especially bad if you rely on typed query responses as switching to raw queries requires manually typing the response.
short answer, yes
Does it support MongoDB ?
TypeORM is the best.
Prisma >>>>>
Prisma is more beginner friendly but drizzle is much better in the long run.
we write more code in drizzle to write less code and we write less code in prisma to write more code
Really prisma schema is better?, tell me how can u create functional index, generated columns, index part of column, index hash in prisma. Man prisma is for hobby projects
Next js Drizzle basic project
As of a few days ago, Drizzle no longer works with NextJs...
In summary you just said don't waste your time on drizzle 😅
Not using non standard languages is a HUGE drizzle pluss.
I don’t see any reason to use prisma or drizzle.. both would make work with the database more komplex for no reason.
Prisma has just one big schema file?! Why?!
Imagine building a GraphQL backend and being in need to create a DB schema, a graphql schema and types for that and have to sync all that stuff manually, because your ORM wants to keep everything in a big schema file…
Imagine just using typeORM with type-graphQL and use just one file per model to get all in one place with much smaller code footprint for relations and so on…
I don’t get why ppl go for more complex solutions just because of more complexity.
Frontend devs will do EVERYTHING to not touch squeel
I believe unless you know exactly what you are doing, don’t use an ORM. And if you know what you are doing there is no point in using an ORM.
Are you living in 2010? I think so.
we all need to drizzle 💧
Lucid ORM