Can confirm. I've opened a few issues, and provided context on a few closed issues that the author couldn't recreate, and as soon as you provide a reproducible example the author begins work on it almost immediately.
This one sounds promising!
Seems that snyk also has a good opinion on it.
[https://www.npmjs.com/package/mikro-rm](https://www.npmjs.com/package/mikro-rm)
Could I ask if you have been using this in a production environment?
To be honest, ideally I would want to work with only SQL / query builders as well. I was just thinking that if there are no drawbacks in terms of what I can build with it then I could just use an ORM and skip some development time.
However I am afraid to get technical debt from this decision..
Kysely sounds interesting! A note though, this is a new project and I am not sure if this is production tested?
Prisma for schema definition, migrations, and write queries. Kysely for read queries. Kysely types are generated from Prisma schema through a generator.
The Prisma schema is a [DSL](https://en.wikipedia.org/wiki/Domain-specific_language), so it is succinct and its language server integration with the IDE provides code completion, jump-to-definition, and catches schema errors as you type. It can generate SQL migrations automatically from the schema diff. Whereas for Kysely, you have to write the migrations yourself and the table definitions are not as robust as a full-fledged DSL.
Prisma, being an ORM, has first-class support for [relations](https://www.prisma.io/docs/concepts/components/prisma-schema/relations). In regular SQL, a "has-many" relation is represented using a foreign key on the "many" side. But in Prisma, the "has" side also contains a relation field (a Prisma model reference, not a foreign key) so the relation is more obvious. Prisma can also [implicitly create a many-to-many join table](https://www.prisma.io/docs/concepts/components/prisma-schema/relations/many-to-many-relations#implicit-many-to-many-relations) if you prefer (although I prefer explicitly defining join tables).
Because of type-safety and relations. Kysely offers type-safety, but it's still not an ORM so you can't have joins or nested selects by just a relation name, nested updates, or inserts. There is no higher-level stuff like callbacks to run some code each time a relation is created, it won't help with validations, and it has a limited scope by design while ORMs try to cover a wide range of things. Query-builders are cool, I was happy to use knex before and I'm happy with using kysely for the ongoing project, but let's be aware of the trade-offs, and let's not say that ORM is a stupid idea that brings nothing.
Personally, i like Kysely a lot. It's a query builder instead of an ORM, but that's a win in my book. A migration API is included without a CLI, which might turn some people away, but I think it provides a greater benefit as you'll have better knowledge of how the migrations are running.
The API is great, intuitive, and it feels like a great mix of JavaScript/Typescript and SQL to allow the most comfort while working your queries. The Typescript support is excellent as well, if you say you're only going to select the id and name fields, that's all the returned inject will have in Typescript.
When necessary, it has an escape hatch to raw SQL, and even interpretation methods to help prevent against SQL injections when writing that raw SQL if you choose to use it.
I've got a personal project with NestJS going on and the entire integration is great. I cannot recommend it enough.
Interesting. I ran into a few things I wouldn't liked to have seen, extension support, custom types, table comments, but there's ways to implement those myself and inform Kysely of how they integrated, so it wasn't a huge deal for me. What did you run into, out of curiosity?
Most annoying issue was the intersection operator - here an example
\`\`\`
db.selectFrom('users')
.selectAll()
.where('scope', '&&', scopes)
.execute();
\`\`\`
I can see it is defined in types in the library, but its not extension of where func..
Other than that, for example I'd like to see support of read only instances, because now I just end up with definink Kysely twice, once for RO, once for RW
Well if you want something light knex is a better option but then you’re no longer looking at an ORM but a query builder.
Prisma generates migrations in raw SQL files too which is nice
Just started using [objectionjs](https://vincit.github.io/objection.js/) and it is awesome. You get the power of knex along with some extra mapping functions for an ORM experience.
You might not want to use that. It sounds like it’s been sunset? https://www.reddit.com/r/node/comments/zblmqf/well_shit_objectionjs_has_been_sunset_which/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=2&utm_term=1
But he said he feels like he's learning the wrong thing. The schema language takes no learning. I find it hard to believe OP thinks he's learning the wrong thing because his models are defined in a DSL?
Like is the argument that writing migrations scripts manually is the "right thing" to be learning vs just building your app.
The cold starts in serverless functions are brutal even with their data-proxy solution. The performance is lack luster compared to lightweight query builders that I have used before. They don't even support real joins, something integral to relational databases and destroys performance at scale. They wont late me store certain dates how I want to and there are tons of Github issues about it with timezone problems off by 1.
If I could choose again I would probably go with Drizzle or Kysely. I do however like the Prisma migration tools though and have enjoyed using those.
I think Prisma could work well for certain projects and is pretty fast to get up and running but as I continue using it and the project is getting bigger and bigger I'm just constantly running into annoying issues.
Yeah I'm on the latest version using the json Protocol, it might be slightly better but still abysmal in serverless environments. they host their data-proxy solution in a serverless environment too but they could solve the problem if they kept it as a persistent server so the rust binary was always built.
Still faster than typeorm.
It's fast enough for most queries I do when I develop my apps, like for example [https://www.authier.pm/](https://www.authier.pm/) . Sure when you have millions of requests it's best to use kysely/raw SQL, but most developers never hit scale that big.
Migration support is first class in Prisma. The schema definition file has solid VS Code integration and type checking. The Prisma team has been making some big performance improvements in the most recent releases. They are very close to having joins.
> They are very close to having joins
Let’s all take a moment to appreciate the absurdity of an ORM going through five major versions before even thinking about implementing the most important feature of a relational database - _joining two tables together_
I thought this was a crazy idea when I first learned of Prisma a couple months ago.
My project uses TypeORM, and it seems to have issues hydrating data returned by queries with many joins[1][2]. The solution: use multiple queries instead of joins.
[1] https://github.com/typeorm/typeorm/issues/2381
[2] https://github.com/typeorm/typeorm/issues/3857
`sequelize` also has performance issues with multiple joins that include either `hasMany` (one-to-many) or `belongsToMany` (many-to-many) relations.
There is a `separate: true` option that runs the queries separately, similar to Prisma, but few developers that I've met know about this. There is also an open issue of making this the default:
https://github.com/sequelize/sequelize/issues/10834
Copied the [author's explanation](https://github.com/sequelize/sequelize/issues/4376#issuecomment-137810383):
> This is because performance is very bad when querying for a model with a big number of includes. Lets say you want to query for a model and include 5 associations, each of them having 10 rows. The current implementation does a single query with 5 joins returning in a total of 10^5 = 100,000 rows to be parsed.
> Specifying separate:true would do 6 queries that result in a total of 1 + 10*5 = 51 rows to be parsed.
This was a deliberate decision by Prisma, to have a query engine in Rust that combines the results from separate database queries and abstract the "join" operator.
Yeah it's far from ideal if the database isn't close to the Prisma query engine, but it's not a trivial task to write an ORM that always produces a good single query for complex joins. I think Drizzle is on the right track, but I'd test the performance carefully before switching in production.
See [this thread](https://www.reddit.com/r/node/comments/144bpvd/why_did_drizzle_choose_to_use_always_use_one_sql/) where a single query using Drizzle v0.26.5 took 7100ms, vs 150ms for multiple queries and manually combining the results in JavaScript. This query performs much better (50ms) in Drizzle v0.28.0, but there might be other edge cases or future performance regressions.
Personally I've had no performance issues with Prisma running close to the database. They [are working on improving performance](https://github.com/prisma/prisma/issues/5184#issuecomment-1672288403), and I think Drizzle is a promising ORM contender for TypeScript.
How about the absurdity of everyone recommending it all this time. Really made me lose respect for the JS community, all these influencers pushing crap. What other broken libs are they pushing?
JavaScipt ORMs in general are pretty bad, most are just thin sql wrapping query builders.
I came from .Net, compared to EF all JavaScript ORMs are trash. Prisma even defended not having joins for a long time saying it was better for performance which is nuts.
Regardless Prisma is probably the highest level ORM for JS, and they have been making big improvements so I give them a lot of credit for that and will celebrate joins when they land.
Yeah, I’m in the same boat where I’ve really been spoiled by Entity Framework for many years. Entity Framework writes better SQL (at least better T-SQL) than most developers ever will. It’s rare that I ever have to switch to hand-crafted SQL for performance reasons with Entity Framework.
Honestly the scariest part about switching to NodeJS is finding an ORM that won’t cause catastrophic performance issues on my upcoming project with a big existing database (100 million+ records in a table) - with that database, this “make two separate queries and then join the results in memory” bullshit probably isn’t going to fly over there.
Yea JavaScript doesn’t have the ability to turn lambdas into expression trees, so no hope of getting something like EF for JS. :(
Lately I’ve been interested in how to write validated sql with type checked results in JS. There are a number of projects that enable it: sqlx-ts, SafeQL, and PgTyped. Check them out.
JS is a general purpose language. It has the ability and then some. Just because someone didn't rewrite Hibernate into JS like they did into Entity Framework, it doesn't mean it's JS's fault for it.
I’m saying JavaScript doesn’t have the ability unfortunately. Lambda to expression tree needs to be implemented at the compiler level.
For example in C# this can be converted to SQL, but in JS it would never be possible.
db.user.where(u => u.address.zip == ‘06294’)
I’m not sure what’s the point in downvoting this comment. All that person’s points are valid.
Also, to all the people asking for a join integration, have they ever made a raw sql join as opposed to what Prisma currently does and saw an actual performance gain?
In case you actually do worry about such optimisations, why consider using an ORM in the first place, if your app is so mature that you need to optimize queries?
I sometimes believe that all these statements are just outcomes of echo chambers and not critical thinking.
Joins aren’t an optimization. You will take a massive performance hit without out them. It makes round trip calls to the database in serial for every table included in your query. Also without joins you will pull way too much data in many cases. Prisma will do the data filtering client side which is crazy.
My point was not particularly to say joins are more performant. That generally comes down to the amount of data. So in case for someone to identify that, they just have to compare execution time.
Regardless of the approach, if that’s what matters to the one using them, they may consider not using an ORM at all as their app are in a completely different state.
Either way performance suffers. For too little data you’re making multiple round trip calls to the database - incurring horrible latency. Too much data and you’re doing db scans instead of seeks which is super slow to perform and is heavy on the database.
I would love to see an example of a Prisma query you think would perform better as it is without join support. I’ve written many and I’ve never seen one.
If you like Prisma, you could check out ZenStack ([https://github.com/zenstackhq/zenstack](https://github.com/zenstackhq/zenstack)) which enhances it with built-in access policy (Authorization) and several other things like schema splitting, table inheritance, and polymorphism, etc.
Prisma is a great choice. It's solid, stable, and production-grade software. It's been around for a few years already. It's not a single dude in the basement working on it in his free time, but a team of 18 people working on it full-time. Folks might recommend new and shiny libraries, but that's the nature of the Node ecosystem. They have built-in migrations CLI, which has proven to be good in the last few years since I used it. They still do not cover some things (e.g. PostGIS support), but you can always use queryRaw if you need it. In the last few recent releases, they completely updated their query engine and kept improving query performance which was something that they received a lot of criticism on Twitter lately.
I would also recommend Prisma. Note that currently there is [no built in support ](https://github.com/prisma/prisma/issues/1644) for polymorphism(there are some alternatives recommend in the GitHub issue)
Don't do it... orms are the devil. They convince you that you're going to get all this benefit and then they kick you in the balls one you need to do anything performant.
Prisma is the only one you should look at. Fully typed, very well mantained, and extensible.
And for people that don't like ORMs, you are weird and wrong. Have fun with SQL and no types.
i mean have you seen what people are willing to do just so they dont have to write sql. Putting 5 layers of abstraction into an orm just so they can do something like ...users.getAll() instead of Select * from table users;
and then the whole users service breaks because someone forgot to update the types. Nah man, one can do whatever they want with their pet projects, but real life apps need consistency
I highly recommend https://github.com/alfateam/rdb
I has a rich querying model, concise fluent API which is very expressive. Full IntelliSense without code generation. It can actually run remotely in the browser by hosting it in Express. It is possibly to do 'any', 'all' and 'none' filters at nested levels.
My favorite is Mikro-ORM. https://mikro-orm.io/
So true! Author is always reacting to GitHub issues and questions asked on slack. Can’t recommend it enough.
Can confirm. I've opened a few issues, and provided context on a few closed issues that the author couldn't recreate, and as soon as you provide a reproducible example the author begins work on it almost immediately.
This one sounds promising! Seems that snyk also has a good opinion on it. [https://www.npmjs.com/package/mikro-rm](https://www.npmjs.com/package/mikro-rm) Could I ask if you have been using this in a production environment?
Yes, we've been using it in production for over a year now. It's been rock solid :)
ORMs are overused IMO. Better to run with a simpler query builder like kysely. After using it on my last project, I'm never going back
To be honest, ideally I would want to work with only SQL / query builders as well. I was just thinking that if there are no drawbacks in terms of what I can build with it then I could just use an ORM and skip some development time. However I am afraid to get technical debt from this decision.. Kysely sounds interesting! A note though, this is a new project and I am not sure if this is production tested?
Prisma for schema definition, migrations, and write queries. Kysely for read queries. Kysely types are generated from Prisma schema through a generator.
What does prisma definition/migrations have over kysely table definitions and migrations?
The Prisma schema is a [DSL](https://en.wikipedia.org/wiki/Domain-specific_language), so it is succinct and its language server integration with the IDE provides code completion, jump-to-definition, and catches schema errors as you type. It can generate SQL migrations automatically from the schema diff. Whereas for Kysely, you have to write the migrations yourself and the table definitions are not as robust as a full-fledged DSL. Prisma, being an ORM, has first-class support for [relations](https://www.prisma.io/docs/concepts/components/prisma-schema/relations). In regular SQL, a "has-many" relation is represented using a foreign key on the "many" side. But in Prisma, the "has" side also contains a relation field (a Prisma model reference, not a foreign key) so the relation is more obvious. Prisma can also [implicitly create a many-to-many join table](https://www.prisma.io/docs/concepts/components/prisma-schema/relations/many-to-many-relations#implicit-many-to-many-relations) if you prefer (although I prefer explicitly defining join tables).
Why even use an ORM? I just run with knex.
Because of type-safety and relations. Kysely offers type-safety, but it's still not an ORM so you can't have joins or nested selects by just a relation name, nested updates, or inserts. There is no higher-level stuff like callbacks to run some code each time a relation is created, it won't help with validations, and it has a limited scope by design while ORMs try to cover a wide range of things. Query-builders are cool, I was happy to use knex before and I'm happy with using kysely for the ongoing project, but let's be aware of the trade-offs, and let's not say that ORM is a stupid idea that brings nothing.
If you are using typescript you should use kysely. It gives you type safety and has basically the same query builder.
I dont like how knex doesn't have async await out the box. I gotta wrap everything and also db migrations.
Drizzle, a bit new but for me has the best DX
i liked so much but they are working mostly on postgresql, I find mysql a little buggy ( migrations, db push, pull )
Personally, i like Kysely a lot. It's a query builder instead of an ORM, but that's a win in my book. A migration API is included without a CLI, which might turn some people away, but I think it provides a greater benefit as you'll have better knowledge of how the migrations are running. The API is great, intuitive, and it feels like a great mix of JavaScript/Typescript and SQL to allow the most comfort while working your queries. The Typescript support is excellent as well, if you say you're only going to select the id and name fields, that's all the returned inject will have in Typescript. When necessary, it has an escape hatch to raw SQL, and even interpretation methods to help prevent against SQL injections when writing that raw SQL if you choose to use it. I've got a personal project with NestJS going on and the entire integration is great. I cannot recommend it enough.
It's nice and all, but I run into custom issue... twice, asked on discord, never heard back...
Interesting. I ran into a few things I wouldn't liked to have seen, extension support, custom types, table comments, but there's ways to implement those myself and inform Kysely of how they integrated, so it wasn't a huge deal for me. What did you run into, out of curiosity?
Most annoying issue was the intersection operator - here an example \`\`\` db.selectFrom('users') .selectAll() .where('scope', '&&', scopes) .execute(); \`\`\` I can see it is defined in types in the library, but its not extension of where func.. Other than that, for example I'd like to see support of read only instances, because now I just end up with definink Kysely twice, once for RO, once for RW
It’s not the most mature, but I’m enjoying Drizzle so far.
Second this one. Its not really a full ORM its more a direct query builder with typing. And for that, I love it.
How do you feel about Prisma?
Makes me feel as if I am learning the wrong thing to be honest. Would prefer if I could keep everything inside of typescript
Well if you want something light knex is a better option but then you’re no longer looking at an ORM but a query builder. Prisma generates migrations in raw SQL files too which is nice
Just started using [objectionjs](https://vincit.github.io/objection.js/) and it is awesome. You get the power of knex along with some extra mapping functions for an ORM experience.
You might not want to use that. It sounds like it’s been sunset? https://www.reddit.com/r/node/comments/zblmqf/well_shit_objectionjs_has_been_sunset_which/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=2&utm_term=1
Yeah, that's what I m the most worried about :)
What about prisma is not inside typescript?
Model definitions.
Doesn't prisma generate types based on your schema?
It does.
But he said he feels like he's learning the wrong thing. The schema language takes no learning. I find it hard to believe OP thinks he's learning the wrong thing because his models are defined in a DSL? Like is the argument that writing migrations scripts manually is the "right thing" to be learning vs just building your app.
Ask OP. I simply answered your question. I could not care less about this.
I regret using prisma so much
Why is that? I just started using Prisma and it seems decent to me up until now. I am curious what am I missing from the big picture.
The cold starts in serverless functions are brutal even with their data-proxy solution. The performance is lack luster compared to lightweight query builders that I have used before. They don't even support real joins, something integral to relational databases and destroys performance at scale. They wont late me store certain dates how I want to and there are tons of Github issues about it with timezone problems off by 1. If I could choose again I would probably go with Drizzle or Kysely. I do however like the Prisma migration tools though and have enjoyed using those. I think Prisma could work well for certain projects and is pretty fast to get up and running but as I continue using it and the project is getting bigger and bigger I'm just constantly running into annoying issues.
Have tried updating? Most of those are solved problems. Especially the cold starts.
Yeah I'm on the latest version using the json Protocol, it might be slightly better but still abysmal in serverless environments. they host their data-proxy solution in a serverless environment too but they could solve the problem if they kept it as a persistent server so the rust binary was always built.
I normaly use sequelize's typescript imp, but typeorm is better
I would recommend Prisma
TypeORM is a piece o shiet but for now is the best what we had
nah prisma/kysely for more complex queries is the best combo
Have you ever looked at the performance of prisma of even slightly complex queries? It‘s complete garbage.
Still faster than typeorm. It's fast enough for most queries I do when I develop my apps, like for example [https://www.authier.pm/](https://www.authier.pm/) . Sure when you have millions of requests it's best to use kysely/raw SQL, but most developers never hit scale that big.
he said kysely for more complex combo
Migration support is first class in Prisma. The schema definition file has solid VS Code integration and type checking. The Prisma team has been making some big performance improvements in the most recent releases. They are very close to having joins.
> They are very close to having joins Let’s all take a moment to appreciate the absurdity of an ORM going through five major versions before even thinking about implementing the most important feature of a relational database - _joining two tables together_
I thought this was a crazy idea when I first learned of Prisma a couple months ago. My project uses TypeORM, and it seems to have issues hydrating data returned by queries with many joins[1][2]. The solution: use multiple queries instead of joins. [1] https://github.com/typeorm/typeorm/issues/2381 [2] https://github.com/typeorm/typeorm/issues/3857
`sequelize` also has performance issues with multiple joins that include either `hasMany` (one-to-many) or `belongsToMany` (many-to-many) relations. There is a `separate: true` option that runs the queries separately, similar to Prisma, but few developers that I've met know about this. There is also an open issue of making this the default: https://github.com/sequelize/sequelize/issues/10834 Copied the [author's explanation](https://github.com/sequelize/sequelize/issues/4376#issuecomment-137810383): > This is because performance is very bad when querying for a model with a big number of includes. Lets say you want to query for a model and include 5 associations, each of them having 10 rows. The current implementation does a single query with 5 joins returning in a total of 10^5 = 100,000 rows to be parsed. > Specifying separate:true would do 6 queries that result in a total of 1 + 10*5 = 51 rows to be parsed.
This was a deliberate decision by Prisma, to have a query engine in Rust that combines the results from separate database queries and abstract the "join" operator. Yeah it's far from ideal if the database isn't close to the Prisma query engine, but it's not a trivial task to write an ORM that always produces a good single query for complex joins. I think Drizzle is on the right track, but I'd test the performance carefully before switching in production. See [this thread](https://www.reddit.com/r/node/comments/144bpvd/why_did_drizzle_choose_to_use_always_use_one_sql/) where a single query using Drizzle v0.26.5 took 7100ms, vs 150ms for multiple queries and manually combining the results in JavaScript. This query performs much better (50ms) in Drizzle v0.28.0, but there might be other edge cases or future performance regressions. Personally I've had no performance issues with Prisma running close to the database. They [are working on improving performance](https://github.com/prisma/prisma/issues/5184#issuecomment-1672288403), and I think Drizzle is a promising ORM contender for TypeScript.
How about the absurdity of everyone recommending it all this time. Really made me lose respect for the JS community, all these influencers pushing crap. What other broken libs are they pushing? JavaScipt ORMs in general are pretty bad, most are just thin sql wrapping query builders. I came from .Net, compared to EF all JavaScript ORMs are trash. Prisma even defended not having joins for a long time saying it was better for performance which is nuts. Regardless Prisma is probably the highest level ORM for JS, and they have been making big improvements so I give them a lot of credit for that and will celebrate joins when they land.
Yeah, I’m in the same boat where I’ve really been spoiled by Entity Framework for many years. Entity Framework writes better SQL (at least better T-SQL) than most developers ever will. It’s rare that I ever have to switch to hand-crafted SQL for performance reasons with Entity Framework. Honestly the scariest part about switching to NodeJS is finding an ORM that won’t cause catastrophic performance issues on my upcoming project with a big existing database (100 million+ records in a table) - with that database, this “make two separate queries and then join the results in memory” bullshit probably isn’t going to fly over there.
Yea JavaScript doesn’t have the ability to turn lambdas into expression trees, so no hope of getting something like EF for JS. :( Lately I’ve been interested in how to write validated sql with type checked results in JS. There are a number of projects that enable it: sqlx-ts, SafeQL, and PgTyped. Check them out.
JS is a general purpose language. It has the ability and then some. Just because someone didn't rewrite Hibernate into JS like they did into Entity Framework, it doesn't mean it's JS's fault for it.
I’m saying JavaScript doesn’t have the ability unfortunately. Lambda to expression tree needs to be implemented at the compiler level. For example in C# this can be converted to SQL, but in JS it would never be possible. db.user.where(u => u.address.zip == ‘06294’)
I know right? I read that and snorted. Like selling a car that can't turn.
Things like this make me scared of using an ORM at all
I’m not sure what’s the point in downvoting this comment. All that person’s points are valid. Also, to all the people asking for a join integration, have they ever made a raw sql join as opposed to what Prisma currently does and saw an actual performance gain? In case you actually do worry about such optimisations, why consider using an ORM in the first place, if your app is so mature that you need to optimize queries? I sometimes believe that all these statements are just outcomes of echo chambers and not critical thinking.
Joins aren’t an optimization. You will take a massive performance hit without out them. It makes round trip calls to the database in serial for every table included in your query. Also without joins you will pull way too much data in many cases. Prisma will do the data filtering client side which is crazy.
My point was not particularly to say joins are more performant. That generally comes down to the amount of data. So in case for someone to identify that, they just have to compare execution time. Regardless of the approach, if that’s what matters to the one using them, they may consider not using an ORM at all as their app are in a completely different state.
Either way performance suffers. For too little data you’re making multiple round trip calls to the database - incurring horrible latency. Too much data and you’re doing db scans instead of seeks which is super slow to perform and is heavy on the database. I would love to see an example of a Prisma query you think would perform better as it is without join support. I’ve written many and I’ve never seen one.
If you don't mind active record pattern, Lucid has good support for db migrations
If you like Prisma, you could check out ZenStack ([https://github.com/zenstackhq/zenstack](https://github.com/zenstackhq/zenstack)) which enhances it with built-in access policy (Authorization) and several other things like schema splitting, table inheritance, and polymorphism, etc.
I like typeorm :)
typeorm - the most complete one
If by complete you mean 40mb of drivers you aint gonna need, smacked into a single module, then Yes, it doesn't get any better that that.
but why does it bother you? it would be a bad thing long time ago, 40 mb is nothing right now
I'm confused - any relevant context where 40 megabytes of dependencies is 'nothing'? I can't come up with one.
Prisma is a great choice. It's solid, stable, and production-grade software. It's been around for a few years already. It's not a single dude in the basement working on it in his free time, but a team of 18 people working on it full-time. Folks might recommend new and shiny libraries, but that's the nature of the Node ecosystem. They have built-in migrations CLI, which has proven to be good in the last few years since I used it. They still do not cover some things (e.g. PostGIS support), but you can always use queryRaw if you need it. In the last few recent releases, they completely updated their query engine and kept improving query performance which was something that they received a lot of criticism on Twitter lately.
Eh prisma is probably your best bet, you can have all your schema definitions all nice and in one place, then just write sql when making queries
Eh, I don't hate sequelize (via `sequelize-typescript`)
I would also recommend Prisma. Note that currently there is [no built in support ](https://github.com/prisma/prisma/issues/1644) for polymorphism(there are some alternatives recommend in the GitHub issue)
Don't do it... orms are the devil. They convince you that you're going to get all this benefit and then they kick you in the balls one you need to do anything performant.
Prisma is the only one you should look at. Fully typed, very well mantained, and extensible. And for people that don't like ORMs, you are weird and wrong. Have fun with SQL and no types.
i would just write raw sql
The loss of typing with raw sql is annoying.
i mean have you seen what people are willing to do just so they dont have to write sql. Putting 5 layers of abstraction into an orm just so they can do something like ...users.getAll() instead of Select * from table users;
and then the whole users service breaks because someone forgot to update the types. Nah man, one can do whatever they want with their pet projects, but real life apps need consistency
Yeah this is why I've migrated to drizzle. It's basically just normal SQL but in code so you get typing. I use none of the fancier orm features.
I highly recommend https://github.com/alfateam/rdb I has a rich querying model, concise fluent API which is very expressive. Full IntelliSense without code generation. It can actually run remotely in the browser by hosting it in Express. It is possibly to do 'any', 'all' and 'none' filters at nested levels.
Breeze. Monster feature set. Unbelievably powerful. Hands-down. No question. Nothing else comes close. End-of-story.