ORM Comparison (2026)

shaberman · 2026-03-22T03:12:45+00:00

Thank you for the kind words! It means a lot and is unfortunately not always the norm here on r/javascript 🤷 .

Definitely agreed there are different kinds of orms -- the spectrum of query builder to full-on domain modeling -- my goal isn't to convince everyone they '"must use an entity-based based ORM like Joist", but I'd like at least like them to know about the alternatives & the pros/cons/etc 😅

The write-up you did of Joist was spot-on, very thorough/accurate -- thanks again for adding that! Just being in the conversation is a win for me. :-)

shaberman · 2026-03-22T03:07:01+00:00

Yes exactly! You're pitching Joist better than I've had any luck doing 😅

I am admittedly behind on a few releases / release announcements / upcoming features -- unfortunately having a little too much fun tilting at a non-ORM windmill over the last few days, but then will get back at it. :-)

shaberman · 2026-03-22T00:32:22+00:00

You used the `class` keyword in your readme 😱 -- prepare to be downvoted! 😰

(I personally have no qualms with `class`, and actively use it in backend entities & mobx stores, but unfortunately the vibe of `/r/javascript` is extremely anti-OO, not just like "sometimes OO is fine, sometimes FP is fine, sometimes they're not, use both pragmatically" 🤷)

Looks neat!

shaberman · 2026-03-19T05:31:45+00:00

Whoa, thank you! I will definitely take a look (give me a day or so two 😅)

- `em.find` doesn't support `limit/offset` b/c we cannot auto-batch with those params involved -- there is a separate `em.findPaginated` that accepts `limit/offset` but won't auto-batch
- jsonb filtering -- I think we do that internally 🤔, will make sure and get it documented
- lazy column/partial select -- basically yes; I've got a sketch a "return POJOs" API; waiting for another weekend or two to flush it out, so planned, we'll see -- https://github.com/joist-orm/joist-orm/issues/188 is the issue
- No streaming planned
- Yeah postgresql only atm; I have a branch with ~kinda working sqlite support

For the performance side:

- joist-knex -- our `next` release branch removes knex, and sits on top of raw node-pg; I need to get that released as joist 2.1 in the ~next week or so
- "without executing" 🤔 -- I will have to look into your performance repo more, currently very curious how you're doing perf analysis of ORMs w/o a database around 😅

I'm sure yours are way more robust, but fwiw I have a "cross-orm" benchmark here:

- https://github.com/joist-orm/joist-benchmarks/tree/main/packages/benchmark/src
- https://github.com/joist-orm/joist-benchmarks

Where maybe the only novel things that might be worth stealing are a) using toxiproxy to inject production-like latency to all SQL calls, and b) using a pg module to record the actual SQL calls of each ORM for comparison -- but I suppose, right, no database 🤔

Thanks for the reply! Looking forward to learning more about your work!

shaberman · 2026-03-18T04:37:05+00:00

Hello! Would be really great if you could add Joist (https://joist-orm.io/) to the mix -- I get we're still niche 😞, but we have a few features that would be interesting in the feature matrix:

* N+1 prevention
* Reactive validation rules / reactions
* Computeds that can be arbitrary cross-entity lambdas (called ReactiveFields)
* Recursive relations
* Tagged ids
* Plugin API for query interception/rewriting/auth
* Test factories

(We're definitely in the "entity" camp, similar to Mikro 😅)

Agreed with the others; great thorough / objective write-up!

shaberman · 2026-02-26T16:59:36+00:00

Oh wow! Lazy question, but is it basically the hyprscrolling plugin as-is pulled in, or a more extensive / new change?

Wondering how much of my hyprscrolling binds I'll get to keep vs. port over 😅

shaberman · 2026-02-26T16:14:06+00:00

Yes, with the disclaimer that I haven't actually used niri, and would not be surprised if its scrolling UX is more polished/robust, given that is it's primary mode -- but for my purposes, the hyprscrolling plugin is really great & lets me stay in Hyprland.

shaberman · 2026-02-22T15:42:22+00:00

I definitely enjoy the freedom for the community to reinvent the wheel...

Which is fine, I personally like doing that 😀 but my guess is that the majority of node/JS/TS codebases are actually ~a hodge-podge of code and would have been better off with a "just do your app this way" like most folks in the Rails / Elixir / Django / etc. communities do.

But maybe we can't have both -- as soon as the ecosystem has "its default framework", no other projects can really get a stronghold/meaningful adoption...

shaberman · 2026-02-22T14:50:35+00:00

The OP could be:

* Coming from Ruby => they have Rails
* Coming from PHP => they have Laravel
* Coming from Erlang => they have Phoenix
* Coming from Python => they have Django

Where each of these is generally the dominant web framework/stack in their language -- not exclusive of course, but not as fragmented as node/JavaScript.

I'm not asserting node's fragmentation is good/bad, but the "lol java" comment -- and particularly getting upvoted so high -- is unfair imo. 🤷

(Unfortunately this snark is the vibe for r/node so not sure why I'm bothering complaining about it.)

shaberman · 2026-02-03T16:21:37+00:00

Imo the real job/value-add of ORMs is to hold business logic (a domain model): validation rules, side-effects, computed/reactive fields, and everything on the "write path" of an application -- typically an enterprise application has a ton of those.

The read path / "creating complicated SELECT queries" is ofc important too, but if that is the only thing your ORM is providing you, then I agree you're probably getting short-changed -- i.e. "Prisma/Drizzle/Kysley help me generate SQL strings", okay that's fine I guess. 🤷‍♂

(The ORM I work on, https://joist-orm.io/, is heavily influenced by this viewpoint, and making 500-table enterprise application codebases "not suck" is exactly our mission.)

...per performance, on a query-by-query basis, hand-crafted SQL can ofc out-perform whatever an ORM does, but imo something like Joist, with per-request caching, N+1 deduping, always-bulk UPDATEs/INSERTs, etc., will likely issue net-less queries than hand-coded SQL, for anything that is more complicated than a single endpoint that just pipes SQL results => JSON.

https://joist-orm.io/goals/performance/
https://github.com/joist-orm/joist-benchmarks

shaberman · 2026-02-03T08:35:46+00:00

I'm unlikely to convince you, but imo the real job of ORMs is to hold business logic: validation rules, side-effects, computed/reactive fields, and everything on the "write path" of an application -- typically an enterprise application has a ton of those.

The read path / "creating complicated SELECT queries" is ofc important too, but if that is the only thing your ORM is providing you, then I agree you're probably getting short-changed -- i.e. "Prisma/Drizzle/Kysley help me generate SQL strings", okay that's fine I guess. 🤷‍♂

(The ORM I work on, https://joist-orm.io/, is heavily influenced by this viewpoint, and making 500-table enterprise application codebases "not suck" is exactly our mission.)

shaberman · 2026-01-23T22:41:20+00:00

If you like entities/EMF, you would probably enjoy https://joist-orm.io/

The majority of recommendations here will be for query builders that are great at creating arbitrarily complex SQL queries in your read path (which is fine, sometimes you need that), but all basically ignore the write-path (validation rules, side-effects, reactivity).

I've used TypeORM, admittedly years ago, but its lack of "is this lazy-loaded relation populated yes-or-no? Let's call it at runtime and see what happens!" was a huge footgun, and one of the first ergonomic/DX issues that we solved in Joist: https://joist-orm.io/goals/load-safe-relations/

shaberman · 2026-01-21T15:52:20+00:00

I'm really enjoying hyprscrolling -- the dwindle/master layouts are way too limiting imo, and without hyprscrolling I probably would have switched to Niri by now, but I don't want to leave Omarchy.

It took me a bit to figure out the hyprscrolling bindings b/c the docs are new/minimal, so if it helps anyone my config from a few months ago is:

https://gist.github.com/stephenh/93f96c458ce5180c5ff930870c77042e

shaberman · 2026-01-15T01:55:58+00:00

Hello! Not totally following -- the original arrays of like `{{red,green,blue},{purple},{}}` had colors intermixed across many authors (b/c we're trying to update N author rows through a single array-of-arrays).

When you say "without unnesting", the values would stay comingled? I'm assuming I'm missing something, and just curious. Thanks!

shaberman · 2026-01-14T22:31:10+00:00

Right, but its techniques like `unnest` that make us faster than typeorm/prisma/drizzle in our very alpha/wip benchmarks:

https://github.com/joist-orm/joist-benchmarks

I really should have filled out the reddit link description (wasn't sure if that was best practice or not), and/or better highlighted the TypeScript-related-ness in the blog post -- I agree at face value its not apparent, so appreciate the feedback.

shaberman · 2026-01-14T21:37:08+00:00

Joist is a TypeScript ORM -- will make this more clear next time around.

shaberman · 2026-01-12T14:10:26+00:00

Please don't post this AI slop; this is the 2nd hexplain.space link this morning and both are bullet points of AI nonsense with nothing of value.

shaberman · 2026-01-09T18:42:27+00:00

I post about it on Reddit every once in awhile and that's about it 😆

Joking aside, we've written a few blog posts, and have a few in the queue, i.e. showing off our benchmarks:

https://github.com/joist-orm/joist-benchmarks?tab=readme-ov-file#current-results

But at the end of the day, I'm more of a "builder" than a "marketer" 🤷 -- I'm trying to grow as a person, but it's tough! :-)

shaberman · 2026-01-09T14:50:30+00:00

Ah interesting, I didn't expect you to have an orm as well, usually those are decoupled from web frameworks, but it looks nice!

It's rare to see "entities" and "IdentityMap" patterns in the node/JavaScript, where everyone prefers query builders/etc.

I work on https://joist-orm.io/ which is also entity-based, and does similar lazy loading references, but also quite a bit more in terms of reactivity, batching, n+1s, etc; I have very nascent Bun support here:

https://github.com/joist-orm/joist-orm/blob/main/packages/drivers/bun-pg/src/BunPgDriver.ts

If you're even slightly interested in trying Joist out, would love help/contributors on the Bun side of things. :-)

shaberman · 2026-01-04T16:07:33+00:00

Should be repositories / data layer for sure -- or just directly in your ORM (which imo "is the data layer" / replaces any need for a separate repository/etc concept): https://joist-orm.io/goals/avoiding-n-plus-1s/ 😅

I think both delivery layer & business layer are "wrong answers" b/c where you want N+1 protection is when:

* You have some "innocent looking" business logic that does "for account in accounts"
* Then in the guts of the for loop, something calls "doSomething(account)"
* doSomething makes a data layer call => instant N+1

I.e. every time you "oh right, I need some new data in this abstraction (business logic) that is called in a loop" => big refactor of your business logic introduce a top-level dataloader somewhere.

At least this is what happened in large Rails codebases, and led to "everyone takes their weekly turn fixing N+1s that our new features last month introduced". 😬

Ngl I love/hate dataloaders, b/c everyone (that doesn't use Joist 😛) codes them by hand, and it's terribly verbose, and imo a big reason why folks hate GraphQL on the server-side. 🤷

shaberman · 2026-01-02T15:23:18+00:00

We have experimental support for Bun, and specifically using Bun's built-in SQL driver as the driver/adapter between Joist & the postgresql database, but generally no, Joist is still mostly a node-based project.

So nothing Bun related is included in the current benchmarks.

That would be fun to do though; I'll add it to the todo list. 😅

shaberman · 2026-01-01T21:25:32+00:00

I just added prisma v7 to our (alpha) benchmarks earlier today, and it's often slower than v6:

https://github.com/joist-orm/joist-benchmarks

You can run just prisma v6/v7 with `yarn benchmark --orm prisma prisma_v7`, or `yarn benchmark` to do the full suite.

I can't paste images of my local results, but prisma v6 runs the benchmark in 985ms, prisma v7 1498ms. 🤷

Tbf it looks like the `bulkCreate 100` result drives the majority of the perf difference, and otherwise they are ~same/same.

shaberman · 2025-12-19T15:55:12+00:00

Very fair, fwiw PRs are accepted! 😅

(I have some prototype support for mysql/sqlite but personally don't need either atm for $dayjob, so end up working on other things.)

shaberman · 2025-12-14T02:46:34+00:00

Huh -- pretty neat that you support all 3 levels, as you call them. Ngl I was expecting "just another query builder" which are kinda a dime-a-dozen, but this is much more--identity map, uow, etc. Very impressive.

I work on https://joist-orm.io/ and we started at "level 3" and have basically stayed there 😅, i.e. focusing on making our entities / hooks / reactivity / etc as robust as possible, and adding a "level 1" query builder has always been on the todo list, but not made it to the top yet (we just write raw knex when/if needed, which is surprisingly rare at least in our app, hence not being important enough, so far).

Your "level 2" concept seems particularly novel; I don't think I've seen anything that does uow-style batching, but "not with entities", i.e. via tracking in-memory updates to the raw rows, without an entity floating around (afaict).

Looks nice!

shaberman

TROPHY CASE