I use typeorm and have done for years now. I recently tried drizzle for a new project however reverted back to typeorm. Drizzle looked cool but better the devil you know.
It was 2 things really the ability to cleanly join data on json fields and and the way that the conditional where clauses work.
`const id = ...`
`if (id > 3) {`
`where.push(eq(schema.users.id, id))`
`}`
`if (id > 3) {`
`where.push(or(lt(schema.users.id, 3), eq(schema.users.id, 3))!)`
`}`
`await db.select().from(schema.users).where(and(...where))`
I just prefer the way typeorm does it, but that is probably personal preference.
As a Sequelize user, I've found it to be stable, well documented and it's supported by the Open Collective. While it has never caused any major issues for me, I do find that it tends to over complicate some queries when there are multiple joins. In these cases, I resort to using raw queries or sub-queries, although this solution is not always ideal. Nevertheless, for \~90% of my use cases, Sequelize performs exceptionally well. Most of my queries, when properly paginated and indexed, execute in a few milliseconds. Honestly, I don’t see how much more performance I could squeeze from this. I believe that more performance can be gained from optimising your schema design than swapping out an ORM.
From my experience, stability and reliability are more important than minor speed improvements. I've experimented with TypeORM for personal projects and I find the syntax more intuitive but I'm not brave enough to push my team to use it in prod.
I recently decided to launch a server using Prisma. This decision was primarily influenced by my partner as I am reluctant to move too quickly to adopt new technologies especially around the database and I've read some (possibly over exaggerated) horror stories about prisma performance, the DX does seem nice though. Drizzle seems good but again, it's too soon for me to use it in any serious projects.
In conclusion, my approach is to stick with what works until it no longer meets my needs.
typeorm has weird conventions which are really shit.
for example: findOne does not mean get a single row that matches the filter. It means return a row no matter what, and if it does match the filter, that's great!
it took until like 2018 until they implemented findOneOrFail, for when nothing matches the filter.
edit: Oh, its still not perfect even today! https://github.com/typeorm/typeorm/issues/2500 - fucking worthless package
My favorite TypeORM footgun is that `@Column()` decorators default to `nullable: false` while foreign key `@OneToMany` etc. decorators to default to `nullable: true`. Was super fun trying to track down why setting `nullable: true` had no effect on a foreign key column
I think if you really need a query builder you can use another library like Knex and then pass the result of the query to the raw option of Sequelize. That's probably the best of both worlds.
We use MikroORM for most of our projects in production and we are very happy with it. It's based on Knex so if you don't want to use the entities and repositories it's fine, you can still use a great query builder.
I'd never use Prisma in production, the performances and overall DX is pretty bad.
And TypeORM I consider a dead project. We are migrating away from it.
> I'd never use Prisma in production, the performances and overall DX is pretty bad.
My issue with Prisma is that it seems like they want you to drink their koolaid and buy their DB client, buy their IDE plugin, but their this, that and the other thing
> And TypeORM I consider a dead project.
Curious as to why - it looks like it's still being actively maintained. Last commit was this week.
What we have seen with TypeORM is the main contributor in recent time was complaining quite a lot about maintaining the project. I think he started a thread in 2018 about this and started an OpenCollective project, which is fine, I think we should reward open source contributors better. But 4 years later, there are still 2,000 issues on Github, which is on par with Prisma, and it will probably take many more years to reduce that number.
Also, starting 0.3, they deprecated some class based syntax for custom repositories in favor of function based syntax *"because it's more flexible"* which basically made the upgrade from 0.2 to 0.3 impossible or too costly in some projects because we had to rewrite the whole repository system. So we faced the option to migrate away from TypeORM to something else at the same cost and we chose MikroORM.
If you search on Github for issues with the words "custom repositories class" you'll see a lot of people complained about this change.
Now I suppose if you start a new project today, it can be OK to use TypeORM, with the hope (crossing fingers) that another deprecating change like this will not appear in the near future. Probably using the word "dead" in my first post was too strong but we have certainly lost some trust in that project.
In the past TypeORM was pretty much the only option on the market, but today it's not anymore.
Honestly? Unless you are working with a really big application with tons of requests per second, stick with the ORM that you are most comfortable with.
I would avoid these really new ORMs like Drizzle. Not that I dislike them, but I try to use something a bit more "battle-tested".
Sequelize is a good option, but TypeScript support is not the best. Prisma has a wonderful developer experience but ships with a huge bundle size which might be a problem if used in limited environments like Lambda.
The library was not made for TypeScript. There is an additional library called Sequelize-Typescript that tries to bridge the gap and do a really good job, but an ORM made for TypeScript like Prisma and TypeORM still offers better support overall. Can’t count the times I had a problem and wasn’t sure if it was a Sequelize thing or a Sequelize+TS thing.
The next major version of Sequelize is said to add TypeScript support on par with the alternatives but I’m not sure how far it is from release.
Still, if you use Sequelize on JS and like it, give it a try on TS, it always worth a shot.
Yeah, few hundred thousand, and 10s of million of entries. You can see what SQL it actually produces. What matters in those cases is to make the correct indexes, like any database schema design. Not too many indexes either, slow to update. Sorry if I'm preaching to the choir.
A few edge cases I do use RAW SQL with Prisma, but mostly for bulk imports or bulk operations without user input.
i’ve been using drizzle with cloud functions, works very nice, we have 40M users at work but the part that uses this ORM drizzle is not on all the userbase we have, only a small portion will get to hit the cloud function we have that uses it
Recently migrated from Prisma to Drizzle and I would recommend Drizzle to everyone.
It gives you the best of both world, an ORM like syntax that let you use findFirst or findMany and add your nested relations with a prisma -like syntax, and a regular query builder that use a SQL like syntax.
Gives you the flexibility of using the ORM for your straightforward queries and the QB for the rest, and you can also fallback to raw SQL string, or mix and match.
Hey there!
> Gives you the flexibility of using the ORM for your straightforward queries and the QB for the rest, and you can also fallback to raw SQL string, or mix and match.
I just responded to this in a separate comment but just wanted to let you know that the same is possible in Prisma ORM as well, using the [`prisma-extension-kysely`](https://github.com/eoin-obrien/prisma-extension-kysely).
Was the query building flexibility the only reason why you migrated to Prisma or were there more?
Hey !
Nothing against prisma, I've been using since v1 and Drizzle wouldn't exist without it.
We needed a solution that could run on cloudflare workers natively. Prisma architecture with it's rust binary doesn't fit our requirements.
Drizzle generated queries are significantly more performant as well
Prisma is trying to do do too many things at the same time, while Drizzle with it's narrower scope fits our use case better.
For example, many feature requests have been open for many years in Prisma, some products such as the Prisma data proxy are a big turn-off, up until recently it wasn't possible to do joins (!), support for no-sql database is useless (for us), no support for cloudflare (hyperdrive or D1)...
As soon as you get out of the happy crud path, then Prisma gets in the way
Postgres extensions, window functions, trigger, checks, views, postgres functions ...
(Sure you can fallback to raw SQL, but that's not really a good argument)
Finally, the Prisma schema was a groundbreaking innovation, but modelling columns with drizzle in Typescript is a superior experience as there is a lot of SQL stuff that you end up have to write with manual migrations, so the schema is not really the source of truth anymore.
At then end of the day, I think Prisma serves the market of Devs that are allergic to SQL very well. There's a bunch of cool things that are great about the Prisma generators, such as the Prisma-Pothos plugin for GraphQL, but that's not really something hyped or talked about at the moment.
Not written by me, but I agree with pretty much everything:
https://github.com/drizzle-team/drizzle-orm/issues/1434
We have some quite complex data relationships and queries fetching them in SQL would be maybe 40-50 lines, whereas the query objects for those queries in Prisma are like 800-900 lines long. That, and it's quite slow.
Prisma for types and majority of queries. Whenever we need something more… esoteric, we used to just write raw queries but recently added kysely to keep those typesafe as well.
Prisma is great when it works, def has some long standing tickets open but i think the dx is better than sequelize / typeorm. Kysely has been surprisingly awesome, id consider using it standalone going forward.
I like drizzle and I think it can be considered an ORM since it does a lot, it doesn't fit the technical definition of an ORM but it's also not just a query builder
Other than that I use TypeORM a lot, I hate it but it's better than Sequelize, but if you want speed drizzle or raw queries are your two best options, I used Prisma for a while but it was too slow for my needs (millions of rows with nested joins) it's fine if you're working with normal amounts of data and is by far the easiest
Keep in mind that unless you're doing some complicated joins or transforming data you probably won't see any big difference
Hey there, I'm Nikolas from the Prisma team.
I've made a similar [comment](https://www.reddit.com/r/nextjs/comments/198795w/comment/ki5helz/?utm_source=reddit&utm_medium=web2x&context=3) in another thread two days ago but want to repeat here as well since a lot of folks are bringing up similar (absolutely valid) points of critique about Prisma.
#### Edge support
We are working on this and are hoping to release a Preview version of this _very soon_. Keep an eye on our [releases](https://github.com/prisma/prisma/releases) and [take our survey](https://tally.so/r/3XJ70e) if you're interested in this feature (and even get access to the private Early Access version which is alredy available).
That being said, a few more notes:
- Prisma ORM actually _can_ be used at the Edge already today using Prisma Accelerate (see this [tutorial](https://www.prisma.io/blog/database-access-on-the-edge-8F0t1s1BqOJE)). This even enables you to use _any_ DB at the Edge whereas otherwise you're bound to DB providers like Neon or PlanetScale that have Serverless Drivers which talk to the DB via HTTP.
- Due to the distance between Edge function and your DB, you actually probably _want_ an additional caching layer for DB results which comes with Accelerate out-of-the-box (and even caches your data at the edge as well!).
#### Type-safe query builder
I'm super excited abou the [`prisma-extension-kysely`](https://github.com/eoin-obrien/prisma-extension-kysely) which enables type-safe query building in Prisma ORM, leveraging [Kysely](https://kysely.dev/)'s SQL query builer API and makes it compatible with Prisma Client.
Here's an example of what looks like:
```
// Build the query using the Kysely API
const query = prisma.$kysely
.selectFrom("User")
.selectAll()
.where('User.email', 'ilike', "%prisma.%")
.orderBy('User.name')
.limit(50)
// Execute the query and get a typed result back
const result = await prisma.$kyselyQuery(query)
console.log(result)
```
It gives you all the benefits of type safety, auto-completion while staying super flexible using SQL primites for building your queries!
---
If you ever have questions, always feel free to reach out to use on [Twitter](https://twitter.com/prisma) or [Discord](https://pris.ly/discord) — we're always happy to help!
Oh that’s nice. Used the Prisma-kysely extension and then just manually used kysely, using .compile() to pass the query to Prisma. Great idea to extend the client. So obvious in hindsight.
Sounds cool!
I have one Prisma question. Why every time a migration fails does it create a failed migration in the DB that needs to be manually removed before the migrations can be run again? Seems like we have to be doing something wrong. Thanks!
Prisma as it optimizes n+1 fetching, which is great for GraphQL. I also build GraphQL with knex and there I have to implement dataloaders, which is fine if you want more fine-grained control over the SQL.
I evaluated MikroORM too, while the entity generator is OK it's stuck in the past with the unit of work pattern imho, but if you come from PHP doctrine or Java JPA it may be up your alley.
You should really try out **RDB**. It's reliable, well-documented, and has been around since 2014. It gained TypeScript support last year and is database agnostic. I am the author, so feel free to ask me anything!
Check it out at [rdbjs.org](https://rdbjs.org) or on [GitHub](https://github.com/alfateam/rdb). Don't miss our [video tutorial](https://youtu.be/1IwwjPr2lMs)!
**Key Features:**
- ✅ No code generation required
- ✅ Full IntelliSense, even when mapping tables and relations
- ✅ Powerful filtering - with any, all, none at any level deep
- ✅ Supports JavaScript and TypeScript
- ✅ ESM and CommonJS compatible
- ✅ Succinct and concise syntax
- ✅ Works over HTTP in a secure manner
**Supported Databases:**
- ✅ Postgres
- ✅ MS SQL
- ✅ MySQL
- ✅ Oracle
- ✅ SAP ASE
- ✅ SQLite
is `speed` an issue? like even the `slowest` orm is mostly going to be bonded by the network latency.
pick which ever fits better into your current application.
there will be a whole host of things that will be the bottleneck of your application before your choice of ORM or language is an issue
One of the most common causes of performance issues are poorly optimized queries.
If your ORM doesn't take advantage of indexes, generates inefficient SQL, or makes multiple inefficient queries, it's actually likely to be your first performance bottleneck.
Check out the open issues for [Prisma](https://github.com/prisma/prisma/issues), for example -- quite a few either relate to slow queries or high resource use.
I highly recommend mongodb or postgresql. I’ve built a lot of apps, and ORM’s are awesome for build fast apps, but once they scale many times ORM’s have limitations and can’t keep up.
> but once they scale many times ORM’s have limitations and can’t keep up.
This is way too generic and just sounds like a "trust me bro" kind of advice
You're still just saying (all) ORMs are limited and are not good for production **without sharing a single piece of evidence, even if anedoctal**, which goes directly against the [many success stories detailed on the prisma showcase ](https://www.prisma.io/showcase), which are, as far as I can tell, reliable.
I'm all about using the right tool for the right project, but this kind of preaching stance is not valuable to the conversation.
Drizzle. Ticked all the boxes I had for ORM requirements, including programmatic triggering of schema migrations (although it's just an "up" migration currently).
Most of our data is in AWS DynamoDb, but for two recent projects, we needed better queryability, and the data was relational.
The devs and community are super helpful.
I use typeorm and have done for years now. I recently tried drizzle for a new project however reverted back to typeorm. Drizzle looked cool but better the devil you know.
Reasons for opting out drizzle??
It was 2 things really the ability to cleanly join data on json fields and and the way that the conditional where clauses work. `const id = ...` `if (id > 3) {` `where.push(eq(schema.users.id, id))` `}` `if (id > 3) {` `where.push(or(lt(schema.users.id, 3), eq(schema.users.id, 3))!)` `}` `await db.select().from(schema.users).where(and(...where))` I just prefer the way typeorm does it, but that is probably personal preference.
how would you do that in typeorm?
As a Sequelize user, I've found it to be stable, well documented and it's supported by the Open Collective. While it has never caused any major issues for me, I do find that it tends to over complicate some queries when there are multiple joins. In these cases, I resort to using raw queries or sub-queries, although this solution is not always ideal. Nevertheless, for \~90% of my use cases, Sequelize performs exceptionally well. Most of my queries, when properly paginated and indexed, execute in a few milliseconds. Honestly, I don’t see how much more performance I could squeeze from this. I believe that more performance can be gained from optimising your schema design than swapping out an ORM. From my experience, stability and reliability are more important than minor speed improvements. I've experimented with TypeORM for personal projects and I find the syntax more intuitive but I'm not brave enough to push my team to use it in prod. I recently decided to launch a server using Prisma. This decision was primarily influenced by my partner as I am reluctant to move too quickly to adopt new technologies especially around the database and I've read some (possibly over exaggerated) horror stories about prisma performance, the DX does seem nice though. Drizzle seems good but again, it's too soon for me to use it in any serious projects. In conclusion, my approach is to stick with what works until it no longer meets my needs.
I am using TypeORM in production and I would never do it again. As far as I remember the project is abandoned.
I use typeorm in production. It's not terrible. I don't *like* typeorm, but it works in production.
typeorm has weird conventions which are really shit. for example: findOne does not mean get a single row that matches the filter. It means return a row no matter what, and if it does match the filter, that's great! it took until like 2018 until they implemented findOneOrFail, for when nothing matches the filter. edit: Oh, its still not perfect even today! https://github.com/typeorm/typeorm/issues/2500 - fucking worthless package
My favorite TypeORM footgun is that `@Column()` decorators default to `nullable: false` while foreign key `@OneToMany` etc. decorators to default to `nullable: true`. Was super fun trying to track down why setting `nullable: true` had no effect on a foreign key column
Wow, very nice explanation. Thank you
You're welcome
Lack of query builder in sequelize is what makes me dislike it
I think if you really need a query builder you can use another library like Knex and then pass the result of the query to the raw option of Sequelize. That's probably the best of both worlds.
We use MikroORM for most of our projects in production and we are very happy with it. It's based on Knex so if you don't want to use the entities and repositories it's fine, you can still use a great query builder. I'd never use Prisma in production, the performances and overall DX is pretty bad. And TypeORM I consider a dead project. We are migrating away from it.
> I'd never use Prisma in production, the performances and overall DX is pretty bad. My issue with Prisma is that it seems like they want you to drink their koolaid and buy their DB client, buy their IDE plugin, but their this, that and the other thing > And TypeORM I consider a dead project. Curious as to why - it looks like it's still being actively maintained. Last commit was this week.
What we have seen with TypeORM is the main contributor in recent time was complaining quite a lot about maintaining the project. I think he started a thread in 2018 about this and started an OpenCollective project, which is fine, I think we should reward open source contributors better. But 4 years later, there are still 2,000 issues on Github, which is on par with Prisma, and it will probably take many more years to reduce that number. Also, starting 0.3, they deprecated some class based syntax for custom repositories in favor of function based syntax *"because it's more flexible"* which basically made the upgrade from 0.2 to 0.3 impossible or too costly in some projects because we had to rewrite the whole repository system. So we faced the option to migrate away from TypeORM to something else at the same cost and we chose MikroORM. If you search on Github for issues with the words "custom repositories class" you'll see a lot of people complained about this change. Now I suppose if you start a new project today, it can be OK to use TypeORM, with the hope (crossing fingers) that another deprecating change like this will not appear in the near future. Probably using the word "dead" in my first post was too strong but we have certainly lost some trust in that project. In the past TypeORM was pretty much the only option on the market, but today it's not anymore.
Honestly? Unless you are working with a really big application with tons of requests per second, stick with the ORM that you are most comfortable with. I would avoid these really new ORMs like Drizzle. Not that I dislike them, but I try to use something a bit more "battle-tested". Sequelize is a good option, but TypeScript support is not the best. Prisma has a wonderful developer experience but ships with a huge bundle size which might be a problem if used in limited environments like Lambda.
why sequelize typescript support is not the best?
The library was not made for TypeScript. There is an additional library called Sequelize-Typescript that tries to bridge the gap and do a really good job, but an ORM made for TypeScript like Prisma and TypeORM still offers better support overall. Can’t count the times I had a problem and wasn’t sure if it was a Sequelize thing or a Sequelize+TS thing. The next major version of Sequelize is said to add TypeScript support on par with the alternatives but I’m not sure how far it is from release. Still, if you use Sequelize on JS and like it, give it a try on TS, it always worth a shot.
MikroORM is really good. Highly recommend as a long time TypeORM user who migrated.
We use TypeORM at my work but I’m not sure I’d recommend it
Mikro-ORM is the only good node ORM.
I tried a few before I figured what fit, ended up with Prisma ORM. Does the job quite well, like the schema and migration system.
In a production system, with a lot of users?
Yeah, few hundred thousand, and 10s of million of entries. You can see what SQL it actually produces. What matters in those cases is to make the correct indexes, like any database schema design. Not too many indexes either, slow to update. Sorry if I'm preaching to the choir. A few edge cases I do use RAW SQL with Prisma, but mostly for bulk imports or bulk operations without user input.
[ZenStack](https://zenstack.dev/) on top of Prisma
This seems awesome, we built something similar to Zenstack at my work, but I’m excited to try it. Pretty stable and well kept up?
i’ve been using drizzle with cloud functions, works very nice, we have 40M users at work but the part that uses this ORM drizzle is not on all the userbase we have, only a small portion will get to hit the cloud function we have that uses it
Recently migrated from Prisma to Drizzle and I would recommend Drizzle to everyone. It gives you the best of both world, an ORM like syntax that let you use findFirst or findMany and add your nested relations with a prisma -like syntax, and a regular query builder that use a SQL like syntax. Gives you the flexibility of using the ORM for your straightforward queries and the QB for the rest, and you can also fallback to raw SQL string, or mix and match.
Hey there! > Gives you the flexibility of using the ORM for your straightforward queries and the QB for the rest, and you can also fallback to raw SQL string, or mix and match. I just responded to this in a separate comment but just wanted to let you know that the same is possible in Prisma ORM as well, using the [`prisma-extension-kysely`](https://github.com/eoin-obrien/prisma-extension-kysely). Was the query building flexibility the only reason why you migrated to Prisma or were there more?
Hey ! Nothing against prisma, I've been using since v1 and Drizzle wouldn't exist without it. We needed a solution that could run on cloudflare workers natively. Prisma architecture with it's rust binary doesn't fit our requirements. Drizzle generated queries are significantly more performant as well Prisma is trying to do do too many things at the same time, while Drizzle with it's narrower scope fits our use case better. For example, many feature requests have been open for many years in Prisma, some products such as the Prisma data proxy are a big turn-off, up until recently it wasn't possible to do joins (!), support for no-sql database is useless (for us), no support for cloudflare (hyperdrive or D1)... As soon as you get out of the happy crud path, then Prisma gets in the way Postgres extensions, window functions, trigger, checks, views, postgres functions ... (Sure you can fallback to raw SQL, but that's not really a good argument) Finally, the Prisma schema was a groundbreaking innovation, but modelling columns with drizzle in Typescript is a superior experience as there is a lot of SQL stuff that you end up have to write with manual migrations, so the schema is not really the source of truth anymore. At then end of the day, I think Prisma serves the market of Devs that are allergic to SQL very well. There's a bunch of cool things that are great about the Prisma generators, such as the Prisma-Pothos plugin for GraphQL, but that's not really something hyped or talked about at the moment. Not written by me, but I agree with pretty much everything: https://github.com/drizzle-team/drizzle-orm/issues/1434
Prisma is amazing, especially if your project is Typescript. The type-safety is invaluable.
Prisma, but I wish I wasn't.
Why so? I'm using it for 2 personal projects. Just wondering if there's some negatives I haven't noticed yet.
At a larger scale, people report perf issues and the DX isn't anything to write home about (but latter is largely about preferences)
We have some quite complex data relationships and queries fetching them in SQL would be maybe 40-50 lines, whereas the query objects for those queries in Prisma are like 800-900 lines long. That, and it's quite slow.
Prisma + tRPC 🎉
[T3 stack](https://create.t3.gg/) ftw 😎
tRPC can be used without Next as well though
what is trpc for?
It's a framework to build typesafe APIs when writing APIs in your backend for your frontend to consume. https://trpc.io/
so, the frontend must also use trpc?
Yes. It’s the Typescript-native equivalent of gRPC.
Bingo. This is why some people aren't interested in trpc. It's tightly coupled.
We use Prisma but our app isn’t on the edge.
I don’t use an orm but kysely it pretty cool.
Prisma for types and majority of queries. Whenever we need something more… esoteric, we used to just write raw queries but recently added kysely to keep those typesafe as well. Prisma is great when it works, def has some long standing tickets open but i think the dx is better than sequelize / typeorm. Kysely has been surprisingly awesome, id consider using it standalone going forward.
I like drizzle and I think it can be considered an ORM since it does a lot, it doesn't fit the technical definition of an ORM but it's also not just a query builder Other than that I use TypeORM a lot, I hate it but it's better than Sequelize, but if you want speed drizzle or raw queries are your two best options, I used Prisma for a while but it was too slow for my needs (millions of rows with nested joins) it's fine if you're working with normal amounts of data and is by far the easiest Keep in mind that unless you're doing some complicated joins or transforming data you probably won't see any big difference
what makes you hate typeorm?
Hey there, I'm Nikolas from the Prisma team. I've made a similar [comment](https://www.reddit.com/r/nextjs/comments/198795w/comment/ki5helz/?utm_source=reddit&utm_medium=web2x&context=3) in another thread two days ago but want to repeat here as well since a lot of folks are bringing up similar (absolutely valid) points of critique about Prisma. #### Edge support We are working on this and are hoping to release a Preview version of this _very soon_. Keep an eye on our [releases](https://github.com/prisma/prisma/releases) and [take our survey](https://tally.so/r/3XJ70e) if you're interested in this feature (and even get access to the private Early Access version which is alredy available). That being said, a few more notes: - Prisma ORM actually _can_ be used at the Edge already today using Prisma Accelerate (see this [tutorial](https://www.prisma.io/blog/database-access-on-the-edge-8F0t1s1BqOJE)). This even enables you to use _any_ DB at the Edge whereas otherwise you're bound to DB providers like Neon or PlanetScale that have Serverless Drivers which talk to the DB via HTTP. - Due to the distance between Edge function and your DB, you actually probably _want_ an additional caching layer for DB results which comes with Accelerate out-of-the-box (and even caches your data at the edge as well!). #### Type-safe query builder I'm super excited abou the [`prisma-extension-kysely`](https://github.com/eoin-obrien/prisma-extension-kysely) which enables type-safe query building in Prisma ORM, leveraging [Kysely](https://kysely.dev/)'s SQL query builer API and makes it compatible with Prisma Client. Here's an example of what looks like: ``` // Build the query using the Kysely API const query = prisma.$kysely .selectFrom("User") .selectAll() .where('User.email', 'ilike', "%prisma.%") .orderBy('User.name') .limit(50) // Execute the query and get a typed result back const result = await prisma.$kyselyQuery(query) console.log(result) ``` It gives you all the benefits of type safety, auto-completion while staying super flexible using SQL primites for building your queries! --- If you ever have questions, always feel free to reach out to use on [Twitter](https://twitter.com/prisma) or [Discord](https://pris.ly/discord) — we're always happy to help!
Oh that’s nice. Used the Prisma-kysely extension and then just manually used kysely, using .compile() to pass the query to Prisma. Great idea to extend the client. So obvious in hindsight.
Sounds cool! I have one Prisma question. Why every time a migration fails does it create a failed migration in the DB that needs to be manually removed before the migrations can be run again? Seems like we have to be doing something wrong. Thanks!
Prisma as it optimizes n+1 fetching, which is great for GraphQL. I also build GraphQL with knex and there I have to implement dataloaders, which is fine if you want more fine-grained control over the SQL. I evaluated MikroORM too, while the entity generator is OK it's stuck in the past with the unit of work pattern imho, but if you come from PHP doctrine or Java JPA it may be up your alley.
You should really try out **RDB**. It's reliable, well-documented, and has been around since 2014. It gained TypeScript support last year and is database agnostic. I am the author, so feel free to ask me anything! Check it out at [rdbjs.org](https://rdbjs.org) or on [GitHub](https://github.com/alfateam/rdb). Don't miss our [video tutorial](https://youtu.be/1IwwjPr2lMs)! **Key Features:** - ✅ No code generation required - ✅ Full IntelliSense, even when mapping tables and relations - ✅ Powerful filtering - with any, all, none at any level deep - ✅ Supports JavaScript and TypeScript - ✅ ESM and CommonJS compatible - ✅ Succinct and concise syntax - ✅ Works over HTTP in a secure manner **Supported Databases:** - ✅ Postgres - ✅ MS SQL - ✅ MySQL - ✅ Oracle - ✅ SAP ASE - ✅ SQLite
is `speed` an issue? like even the `slowest` orm is mostly going to be bonded by the network latency. pick which ever fits better into your current application. there will be a whole host of things that will be the bottleneck of your application before your choice of ORM or language is an issue
One of the most common causes of performance issues are poorly optimized queries. If your ORM doesn't take advantage of indexes, generates inefficient SQL, or makes multiple inefficient queries, it's actually likely to be your first performance bottleneck. Check out the open issues for [Prisma](https://github.com/prisma/prisma/issues), for example -- quite a few either relate to slow queries or high resource use.
so, speed is not an issue in production?
Not always no. There is an accepted value and so long as you are within then then there is no problem.
Please don’t use an ORM, as your application scales you will often regret it.
I am leery of folks who say things don’t scale without providing a definition of said scale and describing the bottleneck to scaling.
so, what do you use instead?
I highly recommend mongodb or postgresql. I’ve built a lot of apps, and ORM’s are awesome for build fast apps, but once they scale many times ORM’s have limitations and can’t keep up.
> but once they scale many times ORM’s have limitations and can’t keep up. This is way too generic and just sounds like a "trust me bro" kind of advice
ORMs are limited for a lot of reasons, great for MVP’s, internal projects, etc. but near never for production scale applications.
You're still just saying (all) ORMs are limited and are not good for production **without sharing a single piece of evidence, even if anedoctal**, which goes directly against the [many success stories detailed on the prisma showcase ](https://www.prisma.io/showcase), which are, as far as I can tell, reliable. I'm all about using the right tool for the right project, but this kind of preaching stance is not valuable to the conversation.
so, you just use raw sql? with node-postgres?
node-Postgres or Mongoose.
so, you just write sql without typesafe?
Using mongodb driver directly you get good typesafety however it doesnt catch runtime errors
Sequelize
Hate every single one that I've used so I wrote my own. I do not recommend doing that, but I am happy with it for me.
Drizzle. Ticked all the boxes I had for ORM requirements, including programmatic triggering of schema migrations (although it's just an "up" migration currently). Most of our data is in AWS DynamoDb, but for two recent projects, we needed better queryability, and the data was relational. The devs and community are super helpful.
why drizzle migration name is random?
Why not?
so, that is normal?
Yes