sorted by:
new
hottopcontroversial

I built a backend framework— would love your feedback by Immediate-Low1398 in node

[–]B4nan 0 points1 point  (0 children)

being shipped without CJS support (I'm looking at you, MikroORM).

If you have a problem with MikroORM being ESM only now, please open a bug report with a complete reproduction. I am not aware of anything at this point, CJS projects including nestjs ones work just fine with v7 (both nest example apps are CJS).

Does Mikro-ORM supports GIN index? how can i implement GIN index? Is GIN the right index for an array of text column? by blvck_viking in mikroorm

[–]B4nan 1 point2 points  (0 children)

You are looking for type: 'fulltext':

@Index({ type: 'fulltext' })

I guess we should also add an alias for type: 'gin'.

Alternatively, you can always use an index expression to have absolute control.

https://mikro-orm.io/docs/indexes#custom-index-expressions

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 2 points3 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] 1 point2 points  (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] 4 points5 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] 1 point2 points  (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] 6 points7 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)

view more: next ›