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.
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.
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.
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.
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.
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).
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.
Is Drizzle supporting Mongo? Is it supporting CSFLE connection? If not, it‘s for the bin for me 😅. Security and NoSQL are the most important topics for me!
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
Because there are still things only SQL can do like common table expressions, views and stored functions which are super useful for complex queries ua-cam.com/users/shortsjLcbLVaz4ms
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
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.
"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'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!
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
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
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.
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.
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.
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
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.
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
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.
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
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
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
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
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 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
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.
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
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
@@chudchadanstudtell me how can you achieve the following in prisma if you have mysql db how can you do joins ? how can you use JSON functions? how can you do hash index? how can you use geo functions? how can you use flow control functions?????
- 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
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
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.
Prisma has always been weird. Typeorm has been serving us very well for years. Drizzle is just like a slightly lower level typeorm.
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.
Real man write queries 💪
Only thing I like from them is studio.
I use DataGrip
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.
As a front end developer I have never heard of any of this
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.
Hi I have an idea 💡 can you create youtube video downloaded using javascript? I hope hear from you
Drizzle also have query like prisma interface like find in prisma isn't it. On query not insert update and delete.
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?
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.
yes it is
Hey can you help me in my build about prisma getting some errors aint getting what the heck are they.
Not using non standard languages is a HUGE drizzle pluss.
For drizzle my nizzle.
Frontend devs will do EVERYTHING to not touch squeel
I've been doing backend for a long time, never had to deal with Prisma, I think it's absolutely useless
If you don't know SQL, learn that before choosing an ORM.
Once you know SQL, you don't need an ORM. 🤫
drizzle is just like sql wrapped in typescript
Next js Drizzle basic project
dude you have a goated hairline
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
Thank you. i will just keep raw dogging SQL
Zero views gang where you at?
here we are
@@dulranga_2 Welcome brother!
prisma is superior
After this video. Supabase is really the easiest
Prisma for simple query ease + kysely for more complex queries, all with a single source of truth, the beautiful Prisma schema 🎉
NO, NO!!! FOR GOD, NO!!!! Damn, it is SO BAD TO PERFORMANCE! It is like, 36x slower than use kysely + pg
Is Drizzle supporting Mongo? Is it supporting CSFLE connection? If not, it‘s for the bin for me 😅. Security and NoSQL are the most important topics for me!
Unfortunately, Drizzle doesn't support MongoDB.
@@binamralamsal that's a bummer
@@binamralamsal but is there any orm that supports both relational and mongo?
@@shakapaker Prisma :D
@@marc-hess lmao
Compared to prisma drizzle is new
I believe in Sequalize supermacy 🙌🏼
mankind will do everything except write SQL
Why are you shaking your head so much in all of your videos?
I used Sequalize the first time, never decided to change it. Tried using Prisma once, but I hate their own language approach.
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
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 ua-cam.com/users/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
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
Kysely as query builder, and Prisma for studio/schemas/migrations ✅
such an unpopular opinion
When will you stop your mewing streak?
The insert method of Drizzle ORM also accepts arrays, allowing you to insert multiple discounts...
I did not know this… Thanks bro!
Exactly!
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.
"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.
When learning ORMs is harder than learning SQL query 🤓
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!
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.
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
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.
Thank you for your thorough research. I needed the expert's opinion about those two.
Expert is a big word
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.
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.
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.
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 didn't even understand what the contribution is here? Both are garbage... more simple
`select * from ....`
i just learnt prisma , dont give me a other headache
Keep using it. It' fine. Plus I think they are fixing the major concerns developers have with it
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?
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
yeah... but have you used drizzma?
I prefer prizzle
I will still be rooting for Prisma
I use Kysely. It's the best. And prisma for schema and migrations.
If you are the one paying for the server's resources, Prisma is not even an option.
we write more code in drizzle to write less code and we write less code in prisma to write more code
I like drizzle but I can't use it because it is young and not that stable yet
the simpler, the better. prisma wins in about 90%+ of cases
Man, if prisma is simpler and better, I dont wanna get near drizzle.
Got recommended drizzle to me. I had never heard of otr
Looking forward to the drizzle crash course!
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.
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.
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
Django is better than any of this orm
Orchid ORM has entered the chat
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
Plot twist: learn the damn SQL and use it FOR FREEEEEEEEEEE and stop using mumbojumbo ORMs.
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
TypeORM is the best.
Drizzle is nerdy lol
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
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 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
I'd still use Prisma
What about Drizzle Many-to-Many relations? it's a terrible code, Prisma handles it much better
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.
With Drizzle you literally cannot set a name for your migration file, plus these "relation" additional code.. that's really cringe
No it not just experience with prisma, drizzle seems to be documented poorly and it actually harder to set up
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
TypeORM ++
short answer, yes
As of a few days ago, Drizzle no longer works with NextJs...
I like this just waiting for sql server to be implemented then I can drop prisma lol
Prisma >>>>>
Prisma is more beginner friendly but drizzle is much better in the long run.
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?
If u ever worked on a big project with decent traffic u will know prisma is not suitable.
Prisma schema + kysely .🤣😑😑
Yes. Prism only scales horizontally.
@@chudchadanstudtell me how can you achieve the following in prisma if you have mysql db
how can you do joins ?
how can you use JSON functions?
how can you do hash index?
how can you use geo functions?
how can you use flow control functions?????
@@mistart1633 Kysely
@@chudchadanstud bro u can't use 99.9% of db features if u are using prisma. U can't even join lol
Lesgooo Drizzllleeee!!!
Haven't tried it yet because I heard they truncate tables a lot when running migration
- 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
Can't hear. Invest into microphone pls. Tnx
Just imagine how cool is laravel
Really is way ahead of time😊
Jizzle
I like the ease of use and simplicity of Prisma.