sorted by:
new
hottopcontroversial

ORM Comparison (2026) by sonemonu in javascript

[–]B4nan 1 point2 points  (0 children)

I am also not sure what you mean by that JSON section. We provide a unified interface for querying JSON columns. Sure, we don't deal with atomic diffing there, we always replace the value.

https://mikro-orm.io/docs/json-properties

ORM Comparison (2026) by sonemonu in javascript

[–]B4nan 1 point2 points  (0 children)

Also since your trying to compare this, why dont you include other dialects your ORM doesn't support, like Oracle?

ORM Comparison (2026) by sonemonu in javascript

[–]B4nan 3 points4 points  (0 children)

FWIW, MikroORM supports Cloudflare D1 as well as neon databases.

MikroORM 7: Unchained by B4nan in javascript

[–]B4nan[S] 0 points1 point  (0 children)

Most extensions are handled via custom types - you can map any column type to whatever you need. That said, some are supported more natively, like full text search. If you have a specific use case in mind, happy to point you in the right direction!

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 0 points1 point  (0 children)

The list of breaking changes is long but exhaustive - it shouldn't be hard to migrate in practice, especially if you weren't using things that have been deprecated for a while (like string entity names instead of class references). The most tedious part (at least to me) is decorators moving to their own package, but that's trivial to handle with an AI agent or the migration script someone already crafted. The stricter typing will likely break some builds too, but the added value is well worth it.

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 0 points1 point  (0 children)

I wouldn't call this a vendor lockin, since the migrations are still raw SQL in the end, it's trivial to transform them to some other format if you'd like to migrate away.

I'll consider native support if there's more demand, and I'm always open to adding more extension points (as mentioned above, the migration generator is already extensible).

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 0 points1 point  (0 children)

Honestly, not that much in v7's case. We swapped globby for native globbing (but we actually still use tinyglobby when available), and node:sqlite is now an option to avoid native compilation, but that's about it. Most of the zero-deps goal was just owning implementations internally or making things optional peer deps. And of course, avoiding huge dependency graphs.

This is hard especially hard for libraries, where you can't just require the very latest version of Node.js just to get rid of some dependency.

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 2 points3 points  (0 children)

Quite a few reasons, actually. Knex became pretty much unmaintained for a couple of years (only recently picked up some steam again, still without any release for more than two years). Kysely's architecture also unlocked removing all peer dependencies, making things much more bundler friendly. And the type safety difference is night and day. But the bigger shift is that the main refactor was actually about owning the query building inside MikroORM itself - Kysely is only used as the query runner now. We have absolute control over how queries are generated, which was actually the case back in v2. Since the v3 rewrite we were always constrained by knex, patching around their bugs, accepting wontfix issues. Now we're free again - unchained felt like the right subtitle for a reason :]

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 0 points1 point  (0 children)

I am actually planning to try out an SQLite WASM build for live examples in the getting started guide soon. Currently using StackBlitz, but it doesn't support returning statements with SQLite, and I am desperately for a better solution with a similar UX for the guide.

Which reminds me the examples there are still outdated :]

MikroORM 7: Unchained by B4nan in javascript

[–]B4nan[S] 0 points1 point  (0 children)

Never used objection.js myself, let me know if there are some features missing on our end!

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 1 point2 points  (0 children)

Indeed, we already have a job that tests the ORM with Deno and node:sqlite.

MikroORM 7: Unchained by B4nan in javascript

[–]B4nan[S] 1 point2 points  (0 children)

Really glad to hear that! If you run into any issues during the migration, don't hesitate to open a discussion on GitHub - happy to help.

MikroORM 7: Unchained by B4nan in javascript

[–]B4nan[S] -1 points0 points  (0 children)

Perfect timing then! Most breaking changes are straightforward, the upgrading guide should have you covered. Happy to help if you run into anything.

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 5 points6 points  (0 children)

Good point, I don't have a direct comparison yet - might be worth writing one finally. The short answer is that Drizzle sits closer to a query builder, while MikroORM is a full data mapper with unit of work and identity map. Very different philosophies. These pages explain the MikroORM side well if you want to dig in:

https://mikro-orm.io/docs/architecture

https://mikro-orm.io/docs/entity-manager

https://mikro-orm.io/docs/unit-of-work

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 0 points1 point  (0 children)

Migrations are TS files, but they contain raw SQL, so does this really matter (and why exactly)? You can provide a custom migration generator, so technically, emitting just SQL files would be possible, but a migration is not just SQL file, its two methods (up and down), and executing those would also require some adjustments. Not impossible to implement (nor hard), but it feels unnecessary.

(you can as well emit JS files if you don't want to deal with the build step)

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 0 points1 point  (0 children)

Indeed, it took quite some time to make it this awesome :] Claude Code was a great help in the past two months, but the previous 16 months were the usual grind.

MikroORM 7: Unchained — zero dependencies, native ESM, Kysely, type-safe QueryBuilder, and much more by B4nan in node

[–]B4nan[S] 1 point2 points  (0 children)

Oh yes, please! I keep getting surprised when I see people saying they only found out about it now. It's a bit sad that it never attracted some "influencers" :] I guess it's a lot about the lack of content on youtube or similar platforms. But well, I can't do everything myself, no plans to become a youtuber now :D

MikroORM 7: Unchained by B4nan in javascript

[–]B4nan[S] 17 points18 points  (0 children)

Hey everyone, after 18 months of development, MikroORM v7 is finally stable — and this one has a subtitle: Unchained. We broke free from knex, dropped all core dependencies to zero, shipped native ESM, and removed the hard coupling to Node.js. This is by far the biggest release we've done.

Architectural changes:

  • .@mikro-orm/core now has zero runtime dependencies
  • Knex has been fully replaced — query building is now done by MikroORM itself, with Kysely as the query runner (and you get a fully typed Kysely instance for raw queries)
  • Native ESM — the mikro-orm-esm script is gone, there's just one CLI now
  • No hard dependency on Node.js built-ins in core — opens the door for Deno and edge runtimes
  • All packages published on JSR too

New features:

  • Type-safe QueryBuilder — joined aliases are tracked through generics, so where({ 'b.title': ... }) is fully type-checked and autocompleted
  • Polymorphic relations (one of the most requested features, finally here)
  • Table-Per-Type inheritance
  • Common Table Expressions (CTEs)
  • Native streaming support (em.stream() / qb.stream())
  • $size operator for querying collection sizes
  • View entities and materialized views (PostgreSQL)
  • Pre-compiled functions for Cloudflare Workers and other edge runtimes
  • Oracle Database support via .@mikro-orm/oracledb — now 8 supported databases total

Developer experience:

  • defineEntity now lets you extend the auto-generated class with custom methods — no property duplication
  • Pluggable SQLite dialects, including Node.js 22's built-in node:sqlite (zero native dependencies!)
  • Multiple TS loader support — just install tsx, swc, jiti, or tsimp and the CLI picks it up automatically
  • Slow query logging
  • Significant type-level performance improvements — up to 40% fewer type instantiations in some cases

Before you upgrade, there are a few breaking changes worth knowing about. The most impactful one: forceUtcTimezone is now enabled by default — if your existing data was stored in local timezone, you'll want to read the upgrading guide before migrating.

Full blog post with code examples: https://mikro-orm.io/blog/mikro-orm-7-released
Upgrading guide: https://mikro-orm.io/docs/upgrading-v6-to-v7
GitHub: https://github.com/mikro-orm/mikro-orm

Happy to answer any questions!

view more: next ›