We are not using an ORM. I am a pretty strong advocate against ORMs, but that is a topic for a different discussion. We have a set of DAO components that access the DB using Slonik, https://github.com/gajus/slonik (overview explaining the rationale for this library is at https://medium.com/@gajus/bf410349856c ).
Our app doesn't have a huge need for caching, but we use a mix of in-server-memory caching ( https://github.com/isaacs/node-lru-cache ) and Redis when we need a global cache.
I highly recommend you not use node-lru-cache: https://github.com/isaacs/node-lru-cache/issues/63 (as you can see from the last comment on that bug, these truly bizarre performance characteristics were not solved, and I would recommend drop-in replacing the fast-lru library we use).
I've worked worked developers that have a hardline against ORMs. I see lot of their points, especially around the performance of raw SQL. But I cannot get past how much boilerplate code that has be written over and over again. And then you have to test that boilerplate code. I find that most people are far more productive using an ORMs. To me this makes sense because it's less things to type. Less is often more.
We have services that don't ORMs and I have to wonder if it's worth the cost.
While I don't write a ton of "boilerplate", the primary thing for me is writing boilerplate, if necessary, is trivially easy. What's hard is debugging when problems arise, or trying to do some slightly more complicated join that isn't supported out of the box by your ORM tool of choice.
Basically, in my opinion ORMs just make the easy stuff slightly easier, but they make the hard stuff much harder, and when you're stressed out trying to fix some critical production DB query all they do is get in the way.
I'm curious how you handle migrations and schema documentation, which to me are the huge benefit of using something like Django or ActiveRecord. Do you version-control at least your forward-migrations as SQL or SQL-via-Slonik? And do you have processes in place to ensure columns are documented in a central location?
For migrations we actually use knex, but primarily just because it was in place first before I knew about Slonik.
Writing a migration tool is pretty trivially easy - all knex does is let you write an up migration and a down migration, and it keeps track of which migrations have been applied in a DB table. Main thing is that all of our migrations are each in an individual versioned file in our source repo.
We use postgres COMMENT functionality to apply comments to all of our table columns.
Our app doesn't have a huge need for caching, but we use a mix of in-server-memory caching ( https://github.com/isaacs/node-lru-cache ) and Redis when we need a global cache.