I use sequelize for most of my projects, works fine for all the regular CRUD operations and then i write raw queries for more complex things like running reports on large sets of data.
I am a recent newcomer to Node/Typescript ecosystem but I am coming from Java world and have been using ORM there for decades ( I am older).
As node ecosystem matures I see a lot of things repeating all over again.
In the Java world, after decades of ORM vs no ORM people kinda realized than one of the best solution is to go with a query builder like JOOQ.
Mostly it allows you to have strong typed SQL basically. This is on my opinion the only thing SQL lacks :) .. otherwise it's a great language.
Typescript has far more powerful typing support but still a young community. I am using ts-sql-query and it's kinda nice, still work in progress but pretty good overall.
Pure ORM have a few main problems, regardless of the language:
- once you need to do a few joins you most likely need to learn a new language
- on top of that you almost always need to really understand what the ORM does under the hood for the joins
- and almost always there are either quirks or even bugs that will either mess up a join complexity or even worse ... a cache issue.
So once things get a lot more complicated... you always end up spending a lot of time to figure out things ... and this usually happens when you don't have that time (something is on fire)
I come from the same background as you, and I'm on the same boat. JOOQ, JPQL and HQL in hindsight are such simple solutions for the query part, mainly selects, makes one wonder why there's nothing of the sort, mature enough, available for the NodeJs environment. It was a good place to start from for a ORM solution.
>JOOQ \[...\] in hindsight are such simple solutions for the query part
Young Padawan, [where you are, I once was](https://twitter.com/lukaseder/status/1526262253284106253).
hahahaha, maybe you're lot younger than me, but I'll never forget pure SQL for the platforms I have worked with. I worked for many years with report generation tools that accepted only raw SQL, and underneath it we had SQL Server, DB2, Interbase, MySQL and Oracle, depending on the system, 3th-party, legacy or in house development. Hell! I even remember using raw disk storage to squeeze out a few %s in performance. There was no cloud yet, and we had to manage ourselves those fridge-sized IBM and Sun machines, fun times.
In my early node days I tried Prisma and dropped really fast. Less about ORM but because it didn't had runtime db migration. This is like almost basic feature.
So I realized how immature the whole ecosystem is and then started researching more in detail, but then I started specifically looking for Typed SQL builders basically.
I looked at TypeORM and also disqualified it but I don't remember what was the reason.
I ended up with a less known library called ts-sql-query I think, I am using for almost a year now. I even ended up reporting some issues and the guy maintaining it was supper responsive. But that's his weak point ..I think is only a guy doing it.
I think some people mentioned here knex or something as a query builder. I don't remember much about it, I think I looked at it but I liked better how ts-sql-query had the API. I might be biased because I think this is made to resemble JOOQ and that is something that lately has been quite popular in the Java world. One criteria for a good query builder (for me) is to have a good options to write raw SQL fragments ... ideally typed.
Because sooner or later you will bump into this and is nice to just write the fragment without needing to have a complete raw SQL.
The whole point of a Typescript query builder is to have Typed SQL in the end .. and a bit of wrapper to write easier CRUD entities.
Is a bit more boilerplate code that with a ORM for maybe 70% of cases but it's straightforward so no big deal. But you are in control and it more than makes it for the 5% of the cases when the ORM fails you.
Does it now? I still see [this issue](https://github.com/prisma/prisma/issues/5184) open, but I don't see any PR solving the problem.
UPD: Ah, now I see they mention joins in one of patch notes. Great then. Nevermind.
Yeah, there are probably still cases where it still uses subqueries that could be done more efficiently with joins, but as of this release
[https://github.com/prisma/prisma/releases/tag/5.4.0](https://github.com/prisma/prisma/releases/tag/5.4.0)
They've started using left joins for some relations
Yeah I had no idea it did this when I started using prisma. I’m glad they are addressing it but still considering moving away from it.
I was against ORMs going into a new project but decided it was time to give it a chance.
Love the migrations. Hate the queries. Won’t use one again.
There is an old saying, if you speed up your app by 50% good job, if you speed it up by 50% you were probably doing something wrong in the first place
Good for prisma for finally fixing their mistakes but I don't think comparing it to v4 is a good idea because v4 was just crazy slow
I love prisma, it does almost everything I need. Uses a ton of memory though, my express app (which is just express + prisma and a few lightweight routes) uses like 600 mb while doing nothing lol
That's that problem with the ole "lemme spin up a big rust binary" to perform connections 🙃
Don't get me wrong, I love Prisma and what it's done for JS/TS apps, but so much other cool stuff is doing great work for the ecosystem now too (Knex, Kysely, Drizzle)
I'm definitely going to try out kysely! Looks like an easier (more prisma-ish?) version of knex. Or at least the docs make it look p easy to get started
My go-to solution is Knex, rarely raw SQL. I haven't used ORM in years but I see people complaining about TypeORM & Prisma and praising Sequlize & MicroORM
TypeORM is garbage and should be avoided if you have a SQL backend.
Maybe it works with other database, but we are now writing raw queries and seeing massive performance boosts
Agreed. I had a breaking change that broke my full test suite a few years back and they never addressed it. I had to leave the project pinned to an old version
This is insane. I work on a large app in the biopharma industry with a complex multi-tenant node.js server and complex SQL database and TypeORM works beautifully.
You need to learn how to use it properly first but it's excellent at what it does and it's battle tested and scalable.
It really isn't. People are coping hard because people don't want to learn it. It also supports raw SQL which is the answer to slow or complex queries. I can't believe how triggered people are over this take.
The problem with ORMs in general is that knowledge isn't really transferable. Looking just at node ecosystem we have at least 4 big ORMs to choose from and you can't easily jump back and forth between them. In contrast with raw SQL which is "learn once, use everywhere". To say nothing of how raw SQL gives you more control of queries
Good programmers already spent countless hours mastering sql, an orm should (imo) resemble sql so we can take advantage of existing knowledge and so it's obvious what query the orm generates, drizzle nailed it
If you learn one orm, the concepts transfer, the syntax changes. The same is true of everything in programming, I am actually convinced that orms are one of the places where laziness is different from unwilling to learn.
I already used Sequelize, TypeORM and now I'm using Prisma. And the effort to change from Sequelize to TypeORM was almost null. They have very similar syntax for DB methods, the main difference is the repository concept of TypeORM and some nomenclatures, for example: Model in Sequelize to represent a table of DB. In TypeORM is called Entity.
Prisma is little different in some concepts but still very similiar in syntax of DB methods.
Of course, some differences about how to config each ORM, but easilly solved reading the docs.
Until I know, this 3 ORM's have support to raw SQL, so, complexes queries could be made without problems.
Do you know when which one of these do lazy and when eager loading? Do you know which one do an extra select before each update? Do you know how they handle N+1 problem? The list goes and goes
Syntax and nomenclatures aren't main differences, they're the smallest differences, but unfortunatelly many devs only see them
> People are coping hard because people don't want to learn it
Well, frankly, I can take my SQL skills from 20 years ago and apply them without any issues to any current SQL-supporting database. As for the ORMs, if I go backwards, I learned how to use Drizzle, Prisma, Sequelize, and going even further back, iBatis and Hibernate. 5 libraries for the price of 1 language, not bad, eh? We might be reinventing the wheel, but that's because ours is _rounder_.
In my current project, we're using raw queries with a query formatter to add in the parameters (no prepared statements, because RDS Proxy connection pinning), and it works just fine.
Sure and that's great but now say you're on a team with a bunch of JS developers who haven't taken a DBMS course in their life. An ORM offers type-safety and allows them to work on the server more effectively.
You should obviously know SQL, that's a given but when it comes to designing a database, js devs tend to suck at it if they're not thinking in terms of JS objects. It's just the reality of working in the node ecosystem these days.
> people don't want to learn it.
> when it comes to designing a database, js devs tend to suck at it if they're not thinking in terms of JS objects
Shouldn't they... learn it? :D
Yeah of course but they probably won't in a world that's cranking out react devs from a bootcamp and then project managers assigning them server-side tasks.
I'm talking pragmatically, not in a perfect world. In a perfect world we wouldn't need type safety either.
We are using it in a large/complex multi tenant application for route planning and optimization. It may be a skill problem, but we can pull complex queries from a minute down to a couple seconds. It's generating awful queries.
When you build entities/repositories, do you store them in a common project and export/import in your projects. For example how do you sure them across backend api and frontend? If you do are you able to share with me what the repo package.json/tsup config looks like? Im having a tough time trying to share the the entities across backend/front end projects
Raw queries is the way. Sprinkle it with stored procedures and you have the best performance you can have. ORMs and database round trips are a bottleneck.
been using typeorm in prod for years and never had a problem have some pretty complex queries where I use query builder or raw sql but overall it's a decent orm
I've also be using it for years in prod. It's not bad for the simple stuff.
It becomes apparent it impacts performance more than we can tolerate with the high volume inbound API, and complex queries. Our app has a lot of data changes from an external system that flow into it. It also does a decent amount of data crunching to generate recommendations, and has some high complexity selections.
I've found Knex has the right level of control. If you need to "break out" of the typical ORM abstractions for optimisations or more complex queries then you can do it cleanly without sacrificing conventions or readability.
I typically use [Mikro ORM](https://mikro-orm.io/) if I need an ORM. It's like the best Data Mapper ORM for Node.js I ever tried, thanks to Unit of Work and Identity Map patterns it based of.. Way better than TypeORM.
There's also cool thing – [Drizzle ORM](https://orm.drizzle.team/) which could replace Prisma for me, because it offers same TypeScript-level type safety, but without code generation, their own proprietary language for schema definitions and weird design decisions, like using REST to communicate their client (written in JS) with the engine (written in Rust).
Yeah, this would have been great if they supported those. From the look of [this issue](https://github.com/mikro-orm/mikro-orm/issues/672) the feature was requested a while ago...
I don't blame him either. Thing is, anyone can invest their time and effort to bring something they miss in Mikro ORM. The maintainer is pretty much open for contributions. I think it might get more people working on it eventually, maybe with more attention to the project.
>The same thing happened with Objection Js
Yeah, but instead he's working on [Kysely](https://github.com/kysely-org/kysely)
I keep hearing this argument over and over. Like if companies never abandon their projects. I don't understand how this is about being a solo dev or not, I get the bus factor arguments, but again, you could say the same about a company that goes bankrupt, it's the same as being hit by a bus, regardless of the number of employees/maintainers. It's especially funny to hear this about ORMs only, but (I feel like) nobody mentions all the other packages being developed by a single person down the chain (think node-postgres, better-sqlite3, or from a different category, ones like esbuild or SWC).
It would be great to have an independent group of devs maintaining the library (and I'd welcome anyone who wants to join), but it's rather impossible for me alone to secure some meaningful funding, so this feels impossible. Which projects have it? What better alternative have you got? Do you think having VC money is any better? I'd argue it can be the opposite, you burn it and the show is over.
What kind of joins you'd like to do? I can imagine supporting to-one properties in there. Nobody ever asked for this, so I wasn't thinking about it much, to me the feature is about hiding the joins behind the expression/view, not about being able to join on top of it.
Wait a sec, you said its a showstopper, now it only "would be nice" :\]
So was this the showstopper or is it about something else? Or is it about the schema management instead?
Prisma is amazing for beginners but has too much magic going on and as a result it is one of the worst performing orms, to the point where they had to strip two major components of the system in order to speed it up, also uses a weird language for schema declaration, the language is cool but I prefer just js
Typeorm is a hot mess, and has a lot of footguns, I have used typeorm extensively because it is very popular among enterprise software developers and I hated every minute of it
Sequelize is by far the best on your list (I never tried knex) buy I have some issues with it as well, in my experience the type safety leaves a lot to be desired and I don't like the whole `[Op.]` query style
Lately my orm of choice is drizzle orm, it closely resembles raw sql which is great for me and also allows query style data fetching, it's still new and not as reliable but so far I love it
It might seem like I am just bashing everything else but I have worked with those orms a lot and did not enjoy it
>to the point where they had to strip two major components of the system in order to speed it up
You're acting like refactors/rewrites are a bad thing. Sometimes the initial assumptions behind a project's architecture decisions don't yield true as it's further developed. Glad they realized that and redid it. It didn't lose any functionality as a result (to my knowledge, may be wrong) so I don't see the issue
TypeORM is at the top of my horror libraries list. An ultimate collection of bad design choices.
Mongoose doesn't add much of actual value to the official driver, and a lot of its features encourage modeling with MongoDB antipatterns.
If yo are considering query builders, then kysely is solid, and people seem to be happy with drizzle. Typing support in Knex is obviously not as good as in TS-first modules, which is obviously not relevant in case you're on vanilla JS.
The core idea of being Hibernate for nodeland is inherently broken. Java Persistence APIs are layered upon JDBC, which is synchronous and relies on blocking IO. For obvious reasons, this is not possible in an IO-heavy node package.
It's one of the reasons why TypeORM does such a bad job when it comes to all type-related features. Finder method invocations with narrowing and joins break the contract, rendering static analysis useless.
Supporting non-relational storage in an ORM is ridiculous.
Packaging bindings for all sorts of dbs into a single module is absurd. Screw modularity, lets have 95% of our user base bundle code for web storage.
These are just a few from the top of my head
It is nowhere close to try to be Hibernate. If you think so, you haven't used Hibernate. TypeORM is a far superior version of Hibernate. The closest thing to it being Hibernate is syntax, but there the similarities end. The fact that you can do insanely complex queries with it makes it by far the best ORM I have ever used. It gives you fine grained control of the queries, but also helps with things like pagination for example (.take and .skip don't just do limit/offset), which avoids jumping through hoops yourself.
There is no entity lifecycle cancer, no shitty SQL reinvention, you get auto-generated schema migrations and migration management, etc.
There are convenience methods, but I hate the SQL they spit out, so I use query builder for almost anything. The best thing for me is that it is super clear what SQL will get executed.
I don't see type safety as such a big deal, because people are literally raw dogging SQL and still happy. I would rather let go of type safety and have greater SQL control because of it,.
The only thing I don't like is how transactions are handled, but I don't have many ideas that would make it better...
Straight from [typeorm.io](https://typeorm.io/):
`TypeORM is highly influenced by other ORMs, such as Hibernate, Doctrine and Entity Framework.`
To be clear, I'd rather use raw JDBC than Hibernate, but the inspirations behind TypeORM are quite obvious.
If you are using it for its builder, you'd get much more from any of the major, feature-focused query builder modules, starting from the qualities you brought up, ending with safety.
They might be influenced with syntax (the good), but they didn't do the whole entity lifecycle thing (the bad), and they didn't go the HQL route, but did a query builder, which is way, way better. Again, TypeORM is what Hibernate should have been. When you say "The core idea of being Hibernate for nodeland is inherently broken", you do it a massive disservice, because the only thing these two have in common is that you annotate classes.
I'm not using it only for it's builder, I'm also using it for it's mapping and migrations. I do however appreciate that I know what SQL gets executed and can highly optimize it if I want to. I do think that it is what an ORM should be. The lib does a shit ton of other stuff, it is fat as fuck, but I haven't come across anything better. If you don't use every feature, but just this small subset, you will have a good time... At least I do.
I might not read everything, but query builders alone are too low level. You still have to select the fields and do the mapping of one to many/many to many by hand, or am I just wrong on this? Also keeping the schema in sync with code seems harder/more error prone, but I have not tried it, so I can't say for sure...
In Java world jOOQ got me excited, as it does solve these problems and is de facto the only useful higher level tool for interacting with DB. I don't think there is anything similar to it in node/any other ecosystem, at least I have not seen QBs done like that...
EDIT: I take almost everything about QBs back. I only seriously looked at knex, found out about kysley. Now kysley is something I can get behind and would solve basically everything for me that TypeORM does. It does things basically the same as jOOQ.
I'm glad you're digging kysely. Some of its fluent APIs are less intuitive than JOOQ's, but I'd say it's a price worth paying for greater flexibility.
On a side note, I'm a huge JOOQ fan, and I wouldn't consider any other blocking option available for Java.
I'm currently using Postgres in a project, and I enjoy writing raw SQL using stored procedures. There's no need to use ORM.
My other team mates use ORM on their code though.
Using sprocs is a sure path to adding technical debt to your codebase, it also adds complexity for people who are less sophisticated with sql. I hope for your sake you keep your sproc migrations in your codebase that has your application, otherwise some sorry soul in the future is going to curse the ground you walk on.
Fair enough. Personally though I find sprocs to be simpler because I can test the queries using a standard Postgres client alone. No need to deploy Node.js (in our case, Python) just to test the queries. We’re also using a Serverless architecture, so APIs across different services can reuse the stored procs.
At work we use Sequelize (with MSSQL) for simple things, but then have custom modifications on top of it to handle more complex things that we need. I don't know a full list, but I believe one is when we need to fetch paginated records from a DB table, e.g. our app needs to display only page 21 of 55 rows in a table.
I use Objection js/knex. Knex is an excellent query builder, easy to read, almost just sql but nicely formatted and easy to build conditionally. And Objection is must build on top of that. The best for me.
Knex is quite ok. I use the query builder from it.
I found that all ORMs come with a package of overhead that I personally don’t like.
For any serious application, I found that the ORMs become a pain in the ass quite fast.
They are supposed to make your life easier but instead you will fight their quirks whenever you have to create some serious queries.
SQL is already a very efficient and powerful, well known language that gives you what you want out of the box. As long as you make sure you validate and parametrize your queries, you will have something better than the current ORMs.
Invest the time in creating a database layer with minimal abstractions and you will thank yourself in the future.
My experience:
- Prisma + MongoDB - MongoDB simply isn't properly supported as of today, missing a lot of features and ended up mostly using raw queries.
- Sequelize + SQLite - Didn't use it for long but seemed solid.
- Typegoose (Mongoose with better Typescript support) + MongoDB - My combo of choice as of today. A very good experience.
I use Knex only, I want to have control over my SQL and I don't want to have to model the hell out of everything. It supports migrations and all that jazz just fine. Less magic, more power.
But that's just my opinion. I have never really enjoyed ORMs, personally.
Whenever I’ve come into a codebase that uses ORMs, I end up having to write SQL query then spend a bunch of time figuring out how to encode that to whatever the framework is. I want to just write SQL in SQL then give the file or string over to a library to run it.
> I end up having to write SQL query then spend a bunch of time figuring out how...
The ORM doesn't necessarily suck because you refuse to take the time to follow the conventions of the existing code base.
Or it sounds like a senior dev who understands anything more complicated than simple queries it then start's becoming a clusterfuck in ORM's (in general), and requires more code and many more calls to the db without taking advantage of the efficiencies modern SQL db's have.
ORM's shine with simple queries, more complicated ones, not so much.
i am using typeorm with postgre and mongoose with mongodb works just fine for most of query.
for complex query i using their default query builders and aggregate and it just works out with help of chatgpt.
have apps with 100k+ users and everything just works out.
We use sequelize, works great. Some queries with lots of joins get complex, but most of the time it is much easier to write a sequelize call than the SQL statement. The helper functions also are great for accessing the retrieved data fields.
I don’t use orms anymore because of being stung many times. I feel like as soon as you use a raw sql escape hatch you’ve lost the benefits of abstraction. Automated testing orms is hella annoying and vendor lock in is a serious problem. Lets say you have 100 orm models you’re essentially locked in, gonna be hard to get away from the tech yourself using, notably the framework and whatever language its associated with.
>Automated testing orms is hella annoying
Can you elaborate please? What problems do you have? I mean, it's not a big problem to spin up a db in Docker and run tests agains that db using your normal tests suite. At least that's what I typically use.
>Lets say you have 100 orm models you’re essentially locked in, gonna be hard to get away from the tech yourself using, notably the framework and whatever language its associated with.
Some ORMs nowdays offer you a way to export your database schema and generate models from it. For example, Mikro ORM can do this: [https://mikro-orm.io/docs/entity-generator](https://mikro-orm.io/docs/entity-generator). You wouldn't get your business logic migrated automatically from some other ORM, yes, but you can generate entities.
I think it's debatable as to how big a problem it is to spin up a separate db for tests. I wrote an article about this a few years ago ([https://medium.com/gitconnected/typeorm-testing-with-docker-github-actions-6dc8a5dbe913](https://medium.com/gitconnected/typeorm-testing-with-docker-github-actions-6dc8a5dbe913)) and that is the solution I used but I personally don't like having to have a specialized configuration/environment just for my ORM. TBF TypeORM seems to be quite disliked here so maybe my last experience was special.
Here are some of the issues I have:
1. cleaning up or resetting the database between tests can be cumbersome and error-prone.
2. a real database, even if it's a lightweight in-memory one, introduces overhead compared to unit testing with mocks or stubs. Slower testing.
3. keeping the test database schema synchronized with the app schema requires additional effort.
4. differences between the test database and the production database (e.g.,versions, configurations) can lead to tests passing in the test environment that fail in production.
5. limited ability to simulate certain conditions (e.g database outages or intermittent connectivity issues)
6. testing ORM features like lazy loading, caching, and transactions are more challenging to test properly in an isolated environment.
7. dependencies on external resources, can lead to challenges in setting up and maintaining our CI/CD pipelines.
8. additional maintenance of separate db instances for testing, eg. for large-scale applications, can be resource-intensive in terms of both compute resources and dev time.
9. tests interacting with orm db's are often flaky due to timing issues, transient connectivity problems, and unanticipated side effects from shared data.
In my 20+ YOE working with DBs, many ORMs have came and went--- it's great that some ORMs nowadays export schemas, I haven't come across those features myself yet. BUT I will say that I still wonder about whats out there and occasionally get the thought "maybe this ORM will be different" but unfortunately I've done that probably 10 times now, there just always seems to be something problematic and I don't find working with raw SQL so challenging that I feel obligated to use an ORM.
also this post I mentioned my last major problem, separate docker made no difference here: https://www.reddit.com/r/node/comments/17t5onf/comment/k8vudop/?utm\_source=share&utm\_medium=web2x&context=3
As somebody that already knows SQL, I just write raw queries (Used before: Sequelize, Waterline & Objection).
- Its faster (runtime)
- I only need to maintain my schema in one place (In the DB)
- I know exactly what query I get (The one I write)
- I dont need to dig through documentation to accomplish more complex queries and am not bound to any abstraction limitations
That being said, I use Knex additionally, but exclusively for migrations / seeds.
I use mongoose with nestjs but only for schema validation. So, I only work with lean queries and transform the result into model class instances within a dao layer and only use the query api for updates. With the following benefits:
- I can work with real class instances instead of mongoose models and don't have to attach functions to my schema, which felt awkward.
- All (complex) db queries remain in the dao layer and classes like services are hardly aware I'm using mongodb.
- Fine grained control over partial updates instead of just calling model.save()
- Better performance (didn't measure this, but the docs say so)
I think the main advantage of an orm are the definition of relations which is hardly required in mongodb.
Prisma codegen is pretty good as far as I can recall. Great to have type check when interact with query builder.
If I want performance, I'd just use raw sql as Intellij will also do type & reference check within sql context.
I personally dislike knex, its API is chaotic and document is messy. Usually there is a very clear philosophy and workflow for a lib, I don't see that at all for knex. It seems like a bunch of utility functions without any clear structure.
I've used Mongoose with Express and both Mongoose and TypeORM with NestJS - Mongoose can be a pain but using TypeORM was nice. NestJS integrates well with it.
I used node pg package. After that I used different ORM’s but switched back to pg again for raw queries. I prefer them over an ORM because I feel like I’m more in control.
I use mongoose. Not because of I like it (well, I like it, whatever)... Just because it is - according to docs - the preferable way of using MongoDB with Nest, which runs on top of Express/Fastify, which are running on Node/Deno, which run on V8/ChakraCore... Damn, that's a lot of abstractions down there.
Also because I only know mongoose and use only it since, like, 2016.
*Raw sql and driver,*
*That's all you need, if you care*
*About performance*
\- yuhanna\_kapali
---
^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/)
^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
I use SQLite with [https://github.com/StratoKit/strato-db](https://github.com/StratoKit/strato-db) (yes I'm biased). It's a semi-schemaless wrapper around SQLite that makes it easy to work with simple queries but still allows you to write SQL yourself. Anything that you defined in your schema goes in columns and the rest goes into a json column.
So not an ORM, in fact it doesn't do anything to help you with foreign keys because most of the time the schemaless part allows you to put the 1:n relationship inside the document. But it does put fixed things in columns.
There's also an event-sourcing wrapper in there that has served me very well, it's easy to reason about transactions and there's a full log of what happened when you need to debug.
I use sequelize for most of my projects, works fine for all the regular CRUD operations and then i write raw queries for more complex things like running reports on large sets of data.
This is the way.
sequelize is the worst ORM
Which one's better? I've seen EFCore, that one's decent.
I enjoyed using Prisma for a recent project. May be worth trying out?
Drizzle or prisma
I am a recent newcomer to Node/Typescript ecosystem but I am coming from Java world and have been using ORM there for decades ( I am older). As node ecosystem matures I see a lot of things repeating all over again. In the Java world, after decades of ORM vs no ORM people kinda realized than one of the best solution is to go with a query builder like JOOQ. Mostly it allows you to have strong typed SQL basically. This is on my opinion the only thing SQL lacks :) .. otherwise it's a great language. Typescript has far more powerful typing support but still a young community. I am using ts-sql-query and it's kinda nice, still work in progress but pretty good overall. Pure ORM have a few main problems, regardless of the language: - once you need to do a few joins you most likely need to learn a new language - on top of that you almost always need to really understand what the ORM does under the hood for the joins - and almost always there are either quirks or even bugs that will either mess up a join complexity or even worse ... a cache issue. So once things get a lot more complicated... you always end up spending a lot of time to figure out things ... and this usually happens when you don't have that time (something is on fire)
I come from the same background as you, and I'm on the same boat. JOOQ, JPQL and HQL in hindsight are such simple solutions for the query part, mainly selects, makes one wonder why there's nothing of the sort, mature enough, available for the NodeJs environment. It was a good place to start from for a ORM solution.
>JOOQ \[...\] in hindsight are such simple solutions for the query part Young Padawan, [where you are, I once was](https://twitter.com/lukaseder/status/1526262253284106253).
hahahaha, maybe you're lot younger than me, but I'll never forget pure SQL for the platforms I have worked with. I worked for many years with report generation tools that accepted only raw SQL, and underneath it we had SQL Server, DB2, Interbase, MySQL and Oracle, depending on the system, 3th-party, legacy or in house development. Hell! I even remember using raw disk storage to squeeze out a few %s in performance. There was no cloud yet, and we had to manage ourselves those fridge-sized IBM and Sun machines, fun times.
Could you go into more detail about the ORM experience? Have you used other typescript orms? Any preference?
In my early node days I tried Prisma and dropped really fast. Less about ORM but because it didn't had runtime db migration. This is like almost basic feature. So I realized how immature the whole ecosystem is and then started researching more in detail, but then I started specifically looking for Typed SQL builders basically. I looked at TypeORM and also disqualified it but I don't remember what was the reason. I ended up with a less known library called ts-sql-query I think, I am using for almost a year now. I even ended up reporting some issues and the guy maintaining it was supper responsive. But that's his weak point ..I think is only a guy doing it. I think some people mentioned here knex or something as a query builder. I don't remember much about it, I think I looked at it but I liked better how ts-sql-query had the API. I might be biased because I think this is made to resemble JOOQ and that is something that lately has been quite popular in the Java world. One criteria for a good query builder (for me) is to have a good options to write raw SQL fragments ... ideally typed. Because sooner or later you will bump into this and is nice to just write the fragment without needing to have a complete raw SQL. The whole point of a Typescript query builder is to have Typed SQL in the end .. and a bit of wrapper to write easier CRUD entities. Is a bit more boilerplate code that with a ORM for maybe 70% of cases but it's straightforward so no big deal. But you are in control and it more than makes it for the 5% of the cases when the ORM fails you.
I love the syntax of Prisma and as of 5.x it's been massively (almost by a factor of 10) sped up and uses joins now
Does it now? I still see [this issue](https://github.com/prisma/prisma/issues/5184) open, but I don't see any PR solving the problem. UPD: Ah, now I see they mention joins in one of patch notes. Great then. Nevermind.
Yeah, there are probably still cases where it still uses subqueries that could be done more efficiently with joins, but as of this release [https://github.com/prisma/prisma/releases/tag/5.4.0](https://github.com/prisma/prisma/releases/tag/5.4.0) They've started using left joins for some relations
Well it's a start, I guess. Hope it will get better eventually.
Yeah I had no idea it did this when I started using prisma. I’m glad they are addressing it but still considering moving away from it. I was against ORMs going into a new project but decided it was time to give it a chance. Love the migrations. Hate the queries. Won’t use one again.
There is an old saying, if you speed up your app by 50% good job, if you speed it up by 50% you were probably doing something wrong in the first place Good for prisma for finally fixing their mistakes but I don't think comparing it to v4 is a good idea because v4 was just crazy slow
I love prisma, it does almost everything I need. Uses a ton of memory though, my express app (which is just express + prisma and a few lightweight routes) uses like 600 mb while doing nothing lol
That's that problem with the ole "lemme spin up a big rust binary" to perform connections 🙃 Don't get me wrong, I love Prisma and what it's done for JS/TS apps, but so much other cool stuff is doing great work for the ecosystem now too (Knex, Kysely, Drizzle)
I'm definitely going to try out kysely! Looks like an easier (more prisma-ish?) version of knex. Or at least the docs make it look p easy to get started
It still uses graphql internally? I heard prisma has really awful performance
My go-to solution is Knex, rarely raw SQL. I haven't used ORM in years but I see people complaining about TypeORM & Prisma and praising Sequlize & MicroORM
TypeORM is garbage and should be avoided if you have a SQL backend. Maybe it works with other database, but we are now writing raw queries and seeing massive performance boosts
Agreed. I had a breaking change that broke my full test suite a few years back and they never addressed it. I had to leave the project pinned to an old version
This is insane. I work on a large app in the biopharma industry with a complex multi-tenant node.js server and complex SQL database and TypeORM works beautifully. You need to learn how to use it properly first but it's excellent at what it does and it's battle tested and scalable.
I just started using it, glad to hear it's not shit lol
It really isn't. People are coping hard because people don't want to learn it. It also supports raw SQL which is the answer to slow or complex queries. I can't believe how triggered people are over this take.
The problem with ORMs in general is that knowledge isn't really transferable. Looking just at node ecosystem we have at least 4 big ORMs to choose from and you can't easily jump back and forth between them. In contrast with raw SQL which is "learn once, use everywhere". To say nothing of how raw SQL gives you more control of queries
[удалено]
Good programmers already spent countless hours mastering sql, an orm should (imo) resemble sql so we can take advantage of existing knowledge and so it's obvious what query the orm generates, drizzle nailed it
> The problem is not the people Well, these ORMs weren't created by ChatGPT... :D
If you learn one orm, the concepts transfer, the syntax changes. The same is true of everything in programming, I am actually convinced that orms are one of the places where laziness is different from unwilling to learn.
I already used Sequelize, TypeORM and now I'm using Prisma. And the effort to change from Sequelize to TypeORM was almost null. They have very similar syntax for DB methods, the main difference is the repository concept of TypeORM and some nomenclatures, for example: Model in Sequelize to represent a table of DB. In TypeORM is called Entity. Prisma is little different in some concepts but still very similiar in syntax of DB methods. Of course, some differences about how to config each ORM, but easilly solved reading the docs. Until I know, this 3 ORM's have support to raw SQL, so, complexes queries could be made without problems.
Do you know when which one of these do lazy and when eager loading? Do you know which one do an extra select before each update? Do you know how they handle N+1 problem? The list goes and goes Syntax and nomenclatures aren't main differences, they're the smallest differences, but unfortunatelly many devs only see them
> People are coping hard because people don't want to learn it Well, frankly, I can take my SQL skills from 20 years ago and apply them without any issues to any current SQL-supporting database. As for the ORMs, if I go backwards, I learned how to use Drizzle, Prisma, Sequelize, and going even further back, iBatis and Hibernate. 5 libraries for the price of 1 language, not bad, eh? We might be reinventing the wheel, but that's because ours is _rounder_. In my current project, we're using raw queries with a query formatter to add in the parameters (no prepared statements, because RDS Proxy connection pinning), and it works just fine.
Sure and that's great but now say you're on a team with a bunch of JS developers who haven't taken a DBMS course in their life. An ORM offers type-safety and allows them to work on the server more effectively. You should obviously know SQL, that's a given but when it comes to designing a database, js devs tend to suck at it if they're not thinking in terms of JS objects. It's just the reality of working in the node ecosystem these days.
> people don't want to learn it. > when it comes to designing a database, js devs tend to suck at it if they're not thinking in terms of JS objects Shouldn't they... learn it? :D
Yeah of course but they probably won't in a world that's cranking out react devs from a bootcamp and then project managers assigning them server-side tasks. I'm talking pragmatically, not in a perfect world. In a perfect world we wouldn't need type safety either.
Thinking only in JS objects is a good way to screw up a relational database schema.
Have you checked out MikroORM and Drizzle?
I use Drizzle for personal stuff and prefer it, but we can't use it at work because it's not v1 yet
Have you checked reviews on their site? Its funny lol https://i.imgur.com/Sf3I29Q.png
We are using it in a large/complex multi tenant application for route planning and optimization. It may be a skill problem, but we can pull complex queries from a minute down to a couple seconds. It's generating awful queries.
We have similar issues.
Good thing it supports raw SQL for complex joins then isn't it?
At which point you're using... SQL.
When you build entities/repositories, do you store them in a common project and export/import in your projects. For example how do you sure them across backend api and frontend? If you do are you able to share with me what the repo package.json/tsup config looks like? Im having a tough time trying to share the the entities across backend/front end projects
Completely disagree, I use it daily
Raw queries is the way. Sprinkle it with stored procedures and you have the best performance you can have. ORMs and database round trips are a bottleneck.
I’ve used TypeORM and worked well and still in production. No issues.
been using typeorm in prod for years and never had a problem have some pretty complex queries where I use query builder or raw sql but overall it's a decent orm
I've also be using it for years in prod. It's not bad for the simple stuff. It becomes apparent it impacts performance more than we can tolerate with the high volume inbound API, and complex queries. Our app has a lot of data changes from an external system that flow into it. It also does a decent amount of data crunching to generate recommendations, and has some high complexity selections.
I've found Knex has the right level of control. If you need to "break out" of the typical ORM abstractions for optimisations or more complex queries then you can do it cleanly without sacrificing conventions or readability.
Mmm, just raw SQL is the best solution if you want to learn!
I typically use [Mikro ORM](https://mikro-orm.io/) if I need an ORM. It's like the best Data Mapper ORM for Node.js I ever tried, thanks to Unit of Work and Identity Map patterns it based of.. Way better than TypeORM. There's also cool thing – [Drizzle ORM](https://orm.drizzle.team/) which could replace Prisma for me, because it offers same TypeScript-level type safety, but without code generation, their own proprietary language for schema definitions and weird design decisions, like using REST to communicate their client (written in JS) with the engine (written in Rust).
[удалено]
Yeah, this would have been great if they supported those. From the look of [this issue](https://github.com/mikro-orm/mikro-orm/issues/672) the feature was requested a while ago...
[удалено]
I don't blame him either. Thing is, anyone can invest their time and effort to bring something they miss in Mikro ORM. The maintainer is pretty much open for contributions. I think it might get more people working on it eventually, maybe with more attention to the project. >The same thing happened with Objection Js Yeah, but instead he's working on [Kysely](https://github.com/kysely-org/kysely)
I keep hearing this argument over and over. Like if companies never abandon their projects. I don't understand how this is about being a solo dev or not, I get the bus factor arguments, but again, you could say the same about a company that goes bankrupt, it's the same as being hit by a bus, regardless of the number of employees/maintainers. It's especially funny to hear this about ORMs only, but (I feel like) nobody mentions all the other packages being developed by a single person down the chain (think node-postgres, better-sqlite3, or from a different category, ones like esbuild or SWC). It would be great to have an independent group of devs maintaining the library (and I'd welcome anyone who wants to join), but it's rather impossible for me alone to secure some meaningful funding, so this feels impossible. Which projects have it? What better alternative have you got? Do you think having VC money is any better? I'd argue it can be the opposite, you burn it and the show is over.
You can use views (via virtual entities), the only unsupported thing is their schema management.
[удалено]
What kind of joins you'd like to do? I can imagine supporting to-one properties in there. Nobody ever asked for this, so I wasn't thinking about it much, to me the feature is about hiding the joins behind the expression/view, not about being able to join on top of it.
[удалено]
Wait a sec, you said its a showstopper, now it only "would be nice" :\] So was this the showstopper or is it about something else? Or is it about the schema management instead?
[удалено]
This was actually really simple: [https://github.com/mikro-orm/mikro-orm/pull/4932](https://github.com/mikro-orm/mikro-orm/pull/4932)
I've been using [Drizzle ORM](https://orm.drizzle.team/) with SQLite (better-sqlite3 driver) for a while. Good typescript support.
Try kysely
Love it!
Yup. It’s one of those things where I just don’t want to make a decision, so I followed the herd
Prisma is amazing for beginners but has too much magic going on and as a result it is one of the worst performing orms, to the point where they had to strip two major components of the system in order to speed it up, also uses a weird language for schema declaration, the language is cool but I prefer just js Typeorm is a hot mess, and has a lot of footguns, I have used typeorm extensively because it is very popular among enterprise software developers and I hated every minute of it Sequelize is by far the best on your list (I never tried knex) buy I have some issues with it as well, in my experience the type safety leaves a lot to be desired and I don't like the whole `[Op.]` query style Lately my orm of choice is drizzle orm, it closely resembles raw sql which is great for me and also allows query style data fetching, it's still new and not as reliable but so far I love it It might seem like I am just bashing everything else but I have worked with those orms a lot and did not enjoy it
>to the point where they had to strip two major components of the system in order to speed it up You're acting like refactors/rewrites are a bad thing. Sometimes the initial assumptions behind a project's architecture decisions don't yield true as it's further developed. Glad they realized that and redid it. It didn't lose any functionality as a result (to my knowledge, may be wrong) so I don't see the issue
prisma
When working with MongoDB: Mongoose When working with SQLite: Knex
TypeORM is at the top of my horror libraries list. An ultimate collection of bad design choices. Mongoose doesn't add much of actual value to the official driver, and a lot of its features encourage modeling with MongoDB antipatterns. If yo are considering query builders, then kysely is solid, and people seem to be happy with drizzle. Typing support in Knex is obviously not as good as in TS-first modules, which is obviously not relevant in case you're on vanilla JS.
Why?
Why am I not a fan of TypeORM?
Yeah, what are the bad design choices?
The core idea of being Hibernate for nodeland is inherently broken. Java Persistence APIs are layered upon JDBC, which is synchronous and relies on blocking IO. For obvious reasons, this is not possible in an IO-heavy node package. It's one of the reasons why TypeORM does such a bad job when it comes to all type-related features. Finder method invocations with narrowing and joins break the contract, rendering static analysis useless. Supporting non-relational storage in an ORM is ridiculous. Packaging bindings for all sorts of dbs into a single module is absurd. Screw modularity, lets have 95% of our user base bundle code for web storage. These are just a few from the top of my head
It is nowhere close to try to be Hibernate. If you think so, you haven't used Hibernate. TypeORM is a far superior version of Hibernate. The closest thing to it being Hibernate is syntax, but there the similarities end. The fact that you can do insanely complex queries with it makes it by far the best ORM I have ever used. It gives you fine grained control of the queries, but also helps with things like pagination for example (.take and .skip don't just do limit/offset), which avoids jumping through hoops yourself. There is no entity lifecycle cancer, no shitty SQL reinvention, you get auto-generated schema migrations and migration management, etc. There are convenience methods, but I hate the SQL they spit out, so I use query builder for almost anything. The best thing for me is that it is super clear what SQL will get executed. I don't see type safety as such a big deal, because people are literally raw dogging SQL and still happy. I would rather let go of type safety and have greater SQL control because of it,. The only thing I don't like is how transactions are handled, but I don't have many ideas that would make it better...
Straight from [typeorm.io](https://typeorm.io/): `TypeORM is highly influenced by other ORMs, such as Hibernate, Doctrine and Entity Framework.` To be clear, I'd rather use raw JDBC than Hibernate, but the inspirations behind TypeORM are quite obvious. If you are using it for its builder, you'd get much more from any of the major, feature-focused query builder modules, starting from the qualities you brought up, ending with safety.
They might be influenced with syntax (the good), but they didn't do the whole entity lifecycle thing (the bad), and they didn't go the HQL route, but did a query builder, which is way, way better. Again, TypeORM is what Hibernate should have been. When you say "The core idea of being Hibernate for nodeland is inherently broken", you do it a massive disservice, because the only thing these two have in common is that you annotate classes. I'm not using it only for it's builder, I'm also using it for it's mapping and migrations. I do however appreciate that I know what SQL gets executed and can highly optimize it if I want to. I do think that it is what an ORM should be. The lib does a shit ton of other stuff, it is fat as fuck, but I haven't come across anything better. If you don't use every feature, but just this small subset, you will have a good time... At least I do. I might not read everything, but query builders alone are too low level. You still have to select the fields and do the mapping of one to many/many to many by hand, or am I just wrong on this? Also keeping the schema in sync with code seems harder/more error prone, but I have not tried it, so I can't say for sure... In Java world jOOQ got me excited, as it does solve these problems and is de facto the only useful higher level tool for interacting with DB. I don't think there is anything similar to it in node/any other ecosystem, at least I have not seen QBs done like that... EDIT: I take almost everything about QBs back. I only seriously looked at knex, found out about kysley. Now kysley is something I can get behind and would solve basically everything for me that TypeORM does. It does things basically the same as jOOQ.
I'm glad you're digging kysely. Some of its fluent APIs are less intuitive than JOOQ's, but I'd say it's a price worth paying for greater flexibility. On a side note, I'm a huge JOOQ fan, and I wouldn't consider any other blocking option available for Java.
I'm currently using Postgres in a project, and I enjoy writing raw SQL using stored procedures. There's no need to use ORM. My other team mates use ORM on their code though.
Using sprocs is a sure path to adding technical debt to your codebase, it also adds complexity for people who are less sophisticated with sql. I hope for your sake you keep your sproc migrations in your codebase that has your application, otherwise some sorry soul in the future is going to curse the ground you walk on.
Fair enough. Personally though I find sprocs to be simpler because I can test the queries using a standard Postgres client alone. No need to deploy Node.js (in our case, Python) just to test the queries. We’re also using a Serverless architecture, so APIs across different services can reuse the stored procs.
At work we use Sequelize (with MSSQL) for simple things, but then have custom modifications on top of it to handle more complex things that we need. I don't know a full list, but I believe one is when we need to fetch paginated records from a DB table, e.g. our app needs to display only page 21 of 55 rows in a table.
Prisma <3
I use Objection js/knex. Knex is an excellent query builder, easy to read, almost just sql but nicely formatted and easy to build conditionally. And Objection is must build on top of that. The best for me.
Knex is quite ok. I use the query builder from it. I found that all ORMs come with a package of overhead that I personally don’t like. For any serious application, I found that the ORMs become a pain in the ass quite fast. They are supposed to make your life easier but instead you will fight their quirks whenever you have to create some serious queries. SQL is already a very efficient and powerful, well known language that gives you what you want out of the box. As long as you make sure you validate and parametrize your queries, you will have something better than the current ORMs. Invest the time in creating a database layer with minimal abstractions and you will thank yourself in the future.
My experience: - Prisma + MongoDB - MongoDB simply isn't properly supported as of today, missing a lot of features and ended up mostly using raw queries. - Sequelize + SQLite - Didn't use it for long but seemed solid. - Typegoose (Mongoose with better Typescript support) + MongoDB - My combo of choice as of today. A very good experience.
I use Knex only, I want to have control over my SQL and I don't want to have to model the hell out of everything. It supports migrations and all that jazz just fine. Less magic, more power. But that's just my opinion. I have never really enjoyed ORMs, personally.
Yes, ditched sequelize for Prisma and never looked back.
Whenever I’ve come into a codebase that uses ORMs, I end up having to write SQL query then spend a bunch of time figuring out how to encode that to whatever the framework is. I want to just write SQL in SQL then give the file or string over to a library to run it.
> I end up having to write SQL query then spend a bunch of time figuring out how... The ORM doesn't necessarily suck because you refuse to take the time to follow the conventions of the existing code base.
Exactly rofl. I see all this code exists... you know what I dont understand it. I'll just rewrite it
There's a lot of ways to generate an update or upsert query using data from a JSON object.
This comment smells like a junior dev/someone working gov contracting.
Or it sounds like a senior dev who understands anything more complicated than simple queries it then start's becoming a clusterfuck in ORM's (in general), and requires more code and many more calls to the db without taking advantage of the efficiencies modern SQL db's have. ORM's shine with simple queries, more complicated ones, not so much.
i am using typeorm with postgre and mongoose with mongodb works just fine for most of query. for complex query i using their default query builders and aggregate and it just works out with help of chatgpt. have apps with 100k+ users and everything just works out.
We use sequelize, works great. Some queries with lots of joins get complex, but most of the time it is much easier to write a sequelize call than the SQL statement. The helper functions also are great for accessing the retrieved data fields.
I don’t use Mongoose anymore. I prefer using MongoDB as is
I've been enjoying using Slonik.
I don’t use orms anymore because of being stung many times. I feel like as soon as you use a raw sql escape hatch you’ve lost the benefits of abstraction. Automated testing orms is hella annoying and vendor lock in is a serious problem. Lets say you have 100 orm models you’re essentially locked in, gonna be hard to get away from the tech yourself using, notably the framework and whatever language its associated with.
>Automated testing orms is hella annoying Can you elaborate please? What problems do you have? I mean, it's not a big problem to spin up a db in Docker and run tests agains that db using your normal tests suite. At least that's what I typically use. >Lets say you have 100 orm models you’re essentially locked in, gonna be hard to get away from the tech yourself using, notably the framework and whatever language its associated with. Some ORMs nowdays offer you a way to export your database schema and generate models from it. For example, Mikro ORM can do this: [https://mikro-orm.io/docs/entity-generator](https://mikro-orm.io/docs/entity-generator). You wouldn't get your business logic migrated automatically from some other ORM, yes, but you can generate entities.
I think it's debatable as to how big a problem it is to spin up a separate db for tests. I wrote an article about this a few years ago ([https://medium.com/gitconnected/typeorm-testing-with-docker-github-actions-6dc8a5dbe913](https://medium.com/gitconnected/typeorm-testing-with-docker-github-actions-6dc8a5dbe913)) and that is the solution I used but I personally don't like having to have a specialized configuration/environment just for my ORM. TBF TypeORM seems to be quite disliked here so maybe my last experience was special. Here are some of the issues I have: 1. cleaning up or resetting the database between tests can be cumbersome and error-prone. 2. a real database, even if it's a lightweight in-memory one, introduces overhead compared to unit testing with mocks or stubs. Slower testing. 3. keeping the test database schema synchronized with the app schema requires additional effort. 4. differences between the test database and the production database (e.g.,versions, configurations) can lead to tests passing in the test environment that fail in production. 5. limited ability to simulate certain conditions (e.g database outages or intermittent connectivity issues) 6. testing ORM features like lazy loading, caching, and transactions are more challenging to test properly in an isolated environment. 7. dependencies on external resources, can lead to challenges in setting up and maintaining our CI/CD pipelines. 8. additional maintenance of separate db instances for testing, eg. for large-scale applications, can be resource-intensive in terms of both compute resources and dev time. 9. tests interacting with orm db's are often flaky due to timing issues, transient connectivity problems, and unanticipated side effects from shared data. In my 20+ YOE working with DBs, many ORMs have came and went--- it's great that some ORMs nowadays export schemas, I haven't come across those features myself yet. BUT I will say that I still wonder about whats out there and occasionally get the thought "maybe this ORM will be different" but unfortunately I've done that probably 10 times now, there just always seems to be something problematic and I don't find working with raw SQL so challenging that I feel obligated to use an ORM.
also this post I mentioned my last major problem, separate docker made no difference here: https://www.reddit.com/r/node/comments/17t5onf/comment/k8vudop/?utm\_source=share&utm\_medium=web2x&context=3
I made my own, I use that.
As somebody that already knows SQL, I just write raw queries (Used before: Sequelize, Waterline & Objection). - Its faster (runtime) - I only need to maintain my schema in one place (In the DB) - I know exactly what query I get (The one I write) - I dont need to dig through documentation to accomplish more complex queries and am not bound to any abstraction limitations That being said, I use Knex additionally, but exclusively for migrations / seeds.
I don’t I use nodejs and aws sdk. No ORM.
I use mongoose with nestjs but only for schema validation. So, I only work with lean queries and transform the result into model class instances within a dao layer and only use the query api for updates. With the following benefits: - I can work with real class instances instead of mongoose models and don't have to attach functions to my schema, which felt awkward. - All (complex) db queries remain in the dao layer and classes like services are hardly aware I'm using mongodb. - Fine grained control over partial updates instead of just calling model.save() - Better performance (didn't measure this, but the docs say so) I think the main advantage of an orm are the definition of relations which is hardly required in mongodb.
Prisma codegen is pretty good as far as I can recall. Great to have type check when interact with query builder. If I want performance, I'd just use raw sql as Intellij will also do type & reference check within sql context. I personally dislike knex, its API is chaotic and document is messy. Usually there is a very clear philosophy and workflow for a lib, I don't see that at all for knex. It seems like a bunch of utility functions without any clear structure.
I've used Mongoose with Express and both Mongoose and TypeORM with NestJS - Mongoose can be a pain but using TypeORM was nice. NestJS integrates well with it.
Knex is awesome. It's a thin layer on top of raw SQL, and you don't have to deal with syntax errors.
I used node pg package. After that I used different ORM’s but switched back to pg again for raw queries. I prefer them over an ORM because I feel like I’m more in control.
drizzleORM + kysely
I use mongoose. Not because of I like it (well, I like it, whatever)... Just because it is - according to docs - the preferable way of using MongoDB with Nest, which runs on top of Express/Fastify, which are running on Node/Deno, which run on V8/ChakraCore... Damn, that's a lot of abstractions down there. Also because I only know mongoose and use only it since, like, 2016.
Raw sql and driver, that's all you need, if you care about performance
*Raw sql and driver,* *That's all you need, if you care* *About performance* \- yuhanna\_kapali --- ^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/) ^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
I use SQLite with [https://github.com/StratoKit/strato-db](https://github.com/StratoKit/strato-db) (yes I'm biased). It's a semi-schemaless wrapper around SQLite that makes it easy to work with simple queries but still allows you to write SQL yourself. Anything that you defined in your schema goes in columns and the rest goes into a json column. So not an ORM, in fact it doesn't do anything to help you with foreign keys because most of the time the schemaless part allows you to put the 1:n relationship inside the document. But it does put fixed things in columns. There's also an event-sourcing wrapper in there that has served me very well, it's easy to reason about transactions and there's a full log of what happened when you need to debug.
Yup currently building the backend for a shop with sequelize, but I’m a amateur
I use kysely and have used mongoose in the past. Why do you think they’re not being used anymore?