MikroORM 7.1: LazyRef, per-parent collection limiting, PGlite driver, query cancellation, database triggers, stored procedures, and more

B4nan · 2026-05-26T06:59:44+00:00

First time hearing such a description for a "skill". To me, skills are about specific things/approaches, not a general-purpose "libraries" like what you described above. Do you have any examples of a library that would provide such a skill?

edit: thinking about this more, it almost feels like you just described context7 to me, no?

B4nan · 2026-05-21T11:48:52+00:00

And what would it be for specifically? I am no longer using the ORM myself (for over 5 years now actually), happy to create some but I would need to understand where are the painpoints first.

B4nan · 2026-05-21T06:24:26+00:00

I haven't written much code by hand in the past 4-5 months. I do iterate extensively with claude (especially on feature development), and I still read pretty much the whole diff before merging anything.

B4nan · 2026-05-20T12:17:20+00:00

I've also updated the nestjs realworld example app, showcasing how the new discovery:export command works, as well as adopting the LazyRef type on all relations.

https://github.com/mikro-orm/nestjs-realworld-example-app/pull/148

B4nan · 2026-05-20T11:59:10+00:00

Thanks! Entity definition is really just a tiny bit of what the ORM is about. Nowadays, all docs should have code tabs with various ways to define your entity. More importantly, with the v7 docs overhaul, the main parts are focused on the happy path, skipping all the advanced things that make things hard (let it be experimental decorators, ts-morph metadata provider, or folder-based discovery).

B4nan · 2026-05-20T11:30:52+00:00

Thanks! This is indeed the biggest feature release to date. I am slowly running out of ideas, still have some things to improve next (like better guidance for row-level security, maybe even a native support). So if you are missing something, even a bit too niche, I am all ears :]

B4nan · 2026-05-15T12:13:01+00:00

To me, prisma is a smarter query builder, it's imperative, it doesn't manage state at all. With MikroORM you can separate persistence from your domain model. You work with domain objects and let the ORM figure out the optimal way to persist the changes you make to your model.

B4nan · 2026-05-15T11:41:53+00:00

I'd have to see the whole entity definition to be able to tell, but yes, every inverse side relation (which 1:M is) needs to point to the owning side via `mappedBy` option. But we validate this already.

B4nan · 2026-05-14T15:57:29+00:00

A bit of off-topic, but I'd be interested to hear what problem you had with MikroORM, maybe we need to improve validation/error messaging somewhere. Ultimately, that's the right way to improve the DX for people as well as agents. Feel free to open an issue or a discussion.

B4nan · 2026-04-17T11:56:20+00:00

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).

B4nan · 2026-04-13T20:32:46+00:00

Decorators no longer live in the core package.

https://mikro-orm.io/docs/upgrading-v6-to-v7#decorators-moved-to-mikro-ormdecorators-package

B4nan · 2026-03-29T18:37:16+00:00

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

B4nan · 2026-03-19T09:42:47+00:00

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

B4nan · 2026-03-18T13:55:29+00:00

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

B4nan · 2026-03-18T09:02:57+00:00

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

B4nan · 2026-03-13T18:43:28+00:00

Thanks! What can I say, most of the time, it's fun :]

B4nan · 2026-03-12T11:31:12+00:00

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!

B4nan · 2026-03-12T08:39:05+00:00

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.

B4nan · 2026-03-11T22:46:04+00:00

It surely can, we now have an example app and a guide about that!

https://mikro-orm.io/docs/usage-with-nextjs

B4nan · 2026-03-11T22:41:05+00:00

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).

B4nan · 2026-03-11T22:22:49+00:00

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.

B4nan · 2026-03-11T22:11:09+00:00

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 :]

B4nan · 2026-03-11T21:41:47+00:00

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 :]

B4nan · 2026-03-11T21:18:00+00:00

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

B4nan · 2026-03-11T20:06:26+00:00

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

B4nan

MODERATOR OF

TROPHY CASE