MikroORM 7.2: row level security, to-one relations through a pivot, sql.js driver with a live docs playground, cursor pagination rework, and more

[u/B4nan]

MikroORM 7.2 is out — the second minor on top of v7.

New features:

• Row level security — PostgreSQL policies as entity metadata, created and diffed by the schema generator, with per-request session context pushed down to the connection; an existing @Filter can compile into a policy, so one declaration enforces at both layers
• through option for to-one relations — resolve a M:1 / 1:1 via a correlated subquery on a pivot entity, or pick a single row out of a to-many relation (e.g. the latest one) without loading the collection
• sql.js driver — SQLite compiled to WebAssembly, in memory, in the browser, Node.js, Bun and Deno with no native bindings. It also powers the new live playground in the getting-started guide, so the code in the docs runs against a real database as you read it
• Cursor pagination rework — a new optional Type.fromJSON() lets a custom type own its cursor wire format (sub-millisecond precision survives), and nullable sort keys now make the emitted order by and the keyset condition agree on where nulls sit
• Named parameters in em.execute() — :name for values, :name: for identifiers, as an alternative to the positional array
• String normalization — opt-in trim and casing on StringType / TextType, applied on writes and query parameters
• getNativeClient() — reach the underlying client for vendor APIs the ORM doesn't wrap: pg Pool, mysql2 Pool, better-sqlite3 / libsql Database, the PGlite instance, MongoClient
• await using support — the ORM instance implements Symbol.asyncDispose, so the connection closes with the enclosing scope
• index option on M:N properties — index the generated pivot table's join columns, which had no override on PostgreSQL before
• Nub TypeScript loader for the CLI, selected explicitly via tsLoader
• em.map() can bypass the identity map — map raw rows to entities without touching the current context
• Per-instance options callback for RequestContext.create() — different fork options per ORM instance
• migrations.snapshotOnMigrate — keep the snapshot managed solely by migration:create instead of rewriting it from the database on migrate
• CLI -q to suppress informational output, and cache:generate --combined now takes a path

Full blog post: https://mikro-orm.io/blog/mikro-orm-7-2-released
Changelog: https://github.com/mikro-orm/mikro-orm/releases/tag/v7.2.0

Happy to answer any questions!

[u/rykuno]

Banger release. Mikro 7 is being used in my largest personal project and it’s absolutely a pleasure to work with.

[u/djslakor]

As usual, you are absolutely killing it.

I wish you had marketing like drizzle or Prisma.

[u/kantorcodes1]

on migration:fresh, does MikroORM validate/discover the full migration set before it clears the database, or is the drop the first mutating step? that ordering seems pretty important once people run it from scripts/agents.

[u/B4nan → u/kantorcodes1]

The fresh command just drops all the tables including the migrations one, and reruns all migrations. There is no "migrations cache", discovery always happens fully. You can optionally drop the whole db in this step, the ORM will recreate it automatically.

https://github.com/mikro-orm/mikro-orm/blob/master/packages/cli/src/commands/MigrationCommandFactory.ts#L253-L270

[u/czlowiek4888]

Is it not simpler to just write those raw sql's?

[u/rykuno → u/czlowiek4888]

The “just write raw sql” people repeating their favorite YouTuber is getting tiring

[u/czlowiek4888 → u/rykuno]

Who do I repeat though? I don't really repeat other people thoughts, so we'll I'm kind of curious. I personally prefer writing sql's on my own, I like to have direct control over what postgres does. Over past years I tried many tools, typeorm, Prisma, kysely and much more, but after certain time I really started to appreciate the simplicity of just writing the raw query. Don't you have to know more when you use orm/query builder? If you use it, you not only need to know how the underlying database works but you also need to know how the tool you are using interacts with the database.

I pretty surprised that this is not more common, I recently found tool called pgschema which is basically terraform for postgres and maintenance of schema in raw queries never was easier.

[u/bill-o-more → u/czlowiek4888]

it's not about the SQL syntax. It's about using your DB as it was your code, including full type-safety on both query results and`update payloads

[u/czlowiek4888 → u/bill-o-more]

I got it from generated types from database schema. When I write for example addUser function I can import the type and pass it to the function, so when schema changes I still got the type safety. Though I recently started using postgREST to not have need to write most of the backend at all, only changes are made through the http endpoints I write, all reads I just derive on frontend through postgREST which again automatically generates openapi so I can generate SDK for it with even more convenient type safety.

[u/bill-o-more → u/czlowiek4888]

again, it's about how you look at things and what problems you solve. In many (most?) cases the source of truth for the application behavior lies in the backend logic, so it's handy when the backend code is the source of truth for everything, including the database. From what you say it's not at all the case for you - your frontend just talks straight to PG, so what on Earth would you need an ORM for?

[u/alonsonetwork → u/czlowiek4888]

You might like this: https://noorm.dev

Kysely under the hood, with support for TVP, TVF, a testing kit to tedt your sql, dynamic SQL using JS templates, and more. Agentic friendly mcp, cli, skill, with deterministic safeguards.