Skip to main content

Introducing MikroORM, TypeScript data-mapper ORM with Identity Map

· 10 min read
Martin Adámek

This might be the ORM you’ve been looking for…


During my early days at university, I remember how quickly I fell in love with object oriented programming and the concepts of Object-relational mapping and Domain Driven Design. Back then, I was mainly a PHP programmer (while we did a lot of Java/Hibernate at school), so a natural choice for me was to start using Doctrine.

A few years ago, when I switched from PHP to Node.js (and later to TypeScript), I was really confused. How come there is nothing similar to Hibernate or Doctrine in the JavaScript world? About a year ago, I finally came across TypeORM, and when I read this line in the readme I thought I found what I was looking for:

TypeORM is highly influenced by other ORMs, such as Hibernate, Doctrine and Entity Framework.

I started playing with it immediately, but I got disappointed very quickly. No Identity Map that would keep track of all loaded entities. No Unit of Work that would handle transaction isolation. No unified API for references with very strange support for accessing just the identifier without populating the entity, MongoDB driver (which I was aiming to use) was experimental and I had a lot problems setting it up. After a few days of struggle, I went away from it.

By that time, I started to think about writing something myself. And that is how MikroORM started!

MikroORM is TypeScript ORM for Node.js based on Data Mapper, Unit of Work and Identity Map patterns.

Currently it supports MongoDB, MySQL, PostgreSQL and SQLite databases, but more can be supported via custom drivers right now. It has first class TypeScript support, while staying back compatible with Vanilla JavaScript.


First install the module via yarn or npm and do not forget to install the database driver as well. Next you will need to enable support for decorators
in tsconfig.json via experimentalDecorators flag. Then call MikroORM.init as part of bootstrapping your application.

Last step is to provide forked EntityManager for each request, so it will have its own unique Identity Map. To do so, you can use EntityManager.fork() method. Another way, that is more DI friendly, is to create new request context for each request, which will use some dark magic in the background to always pick the right EntityManager for you.

# using yarn
$ yarn add mikro-orm mongodb # for mongo
$ yarn add mikro-orm mysql2 # for mysql
$ yarn add mikro-orm pg # for postgresql
$ yarn add mikro-orm sqlite # for sqlite

# or npm
$ npm i -s mikro-orm mongodb # for mongo
$ npm i -s mikro-orm mysql2 # for mysql
$ npm i -s mikro-orm pg # for postgresql
$ npm i -s mikro-orm sqlite # for sqlite
"compilerOptions": {
"module": "commonjs",
"target": "es2017",
"moduleResolution": "node",
"declaration": true,
"strict": true,
"strictPropertyInitialization": false,
"experimentalDecorators": true
const orm = await MikroORM.init({
entities: [Author, Book, BookTag],
dbName: 'my-db-name',
clientUrl: '...', // defaults to 'mongodb://' for mongodb driver
type: 'mongo', // one of 'mysql', 'postgresql', 'sqlite', defaults to 'mongo'
autoFlush: false, // read more here:

console.log(orm.em); // access EntityManager via `em` property
const app = express();

app.use((req, res, next) => {
req.em = orm.em.fork(); // save the fork to `req` object

app.get('/books', async (req, res) => {
const books = await req.em.find(Book); // use the fork via `req.em`
const app = express();

// by providing request context, creating forked EntityManager will be handled automatically
app.use((req, res, next) => {
RequestContext.create(orm.em, next);

Defining entities

To define an entity, simply create a class and decorate it. Here is an example of Book entity defined for MongoDB driver:

import { ObjectID } from 'mongodb';
import { Collection, Entity, IEntity, ManyToMany, ManyToOne, PrimaryKey, Property } from 'mikro-orm';
import { Author, BookTag, Publisher } from '.';

export class Book {

_id: ObjectID;

createdAt = new Date();

@Property({ onUpdate: () => new Date() })
updatedAt = new Date();

title: string;

author: Author;

publisher: Publisher;

@ManyToMany({ entity: () => BookTag, inversedBy: 'books' })
tags = new Collection<BookTag>(this);

constructor(title: string, author: Author) {
this.title = title; = author;


export interface Book extends IEntity<string> { }

As you can see, it’s pretty simple and straightforward. Entities are simple JavaScript objects (so called POJO), decorated with @Entity decorator (for TypeScript), or accompanied with schema definition object (for vanilla JavaScript). No real restrictions are made, you do not have to extend any base class, you are more than welcome to use entity constructors for specifying required parameters to always keep the entity in valid state. The only requirement is to define the primary key property.

You might be curious about the last line with Book as an interface. This is called interface merging and it is there to let TypeScript know the entity will have some extra API methods (like init() or isInitialized()) available as it will be monkey-patched during discovery process. More about this can be found in the docs.

Persisting entities with EntityManager

To save entity state to database, you need to persist it. Persist determines whether to use insert or update and computes appropriate change-set. As a result, only changed fields will be updated in database.

MikroORM comes with support for cascading persist and remove operations. Cascade persist is enabled by default, which means that by persisting an entity, all referenced entities will be automatically persisted too.

const author = new Author('Jon Snow', '');
author.born = new Date();

const publisher = new Publisher('7K publisher');

const book1 = new Book('My Life on The Wall, part 1', author);
book1.publisher = publisher;
const book2 = new Book('My Life on The Wall, part 2', author);
book2.publisher = publisher;
const book3 = new Book('My Life on The Wall, part 3', author);
book3.publisher = publisher;

// just persist books, author and publisher will be automatically cascade persisted
await orm.em.persistAndFlush([book1, book2, book3]);

// or one by one
await orm.em.flush(); // flush everything to database at once

Fetching entities

To fetch entities from database you can use find() and findOne() methods of EntityManager:

// find all authors with name matching 'Jon', and populate all of their books
const authors = await orm.em.find(Author, { name: /Jon/ }, ['books']);

for (const author of authors) {
console.log(; // Jon Snow

for (const book of author.books) {
console.log(book.title); // initialized
console.log(; // true
console.log(; // Jon Snow
console.log(book.publisher); // just reference
console.log(book.publisher.isInitialized()); // false
console.log(; // undefined

More convenient way of fetching entities from database is by using EntityRepository, that carries the entity name so you do not have to pass it to every find and findOne calls:

import { QueryOrder } from 'mikro-orm';

const booksRepository = orm.em.getRepository(Book);

// with sorting, limit and offset parameters, populating author references
const books = await booksRepository.find({ author: '...' }, ['author'], { title: QueryOrder.DESC }, 2, 1);

// or with options object
const books = await booksRepository.find({ author: '...' }, {
populate: ['author'],
limit: 1,
offset: 2,
sort: { title: QueryOrder.DESC },

console.log(books); // Book[]

Working with references

Entity associations are mapped to entity references. Reference is an entity that has at least the identifier (primary key). This reference is stored in the Identity Map so you will get the same object reference when fetching the same document from database.

Thanks to this concept, MikroORM offers unified API for accessing entity references, regardless of whether the entity is initialized or not. Even if you do not populate an association, there will be its reference with primary key set. You can call await entity.init() to initialize the entity. This will trigger database call and populate itself, keeping the same reference to entity object in identity map.

const book = orm.em.findOne(Book, '...');
console.log(; // reference with ID only, instance of Author entity

// this will get the same reference as we already have in ``
const author = orm.em.getReference(Author,;
console.log(; // accessing the id will not trigger any db call
console.log(author.isInitialized()); // false
console.log(; // undefined
console.log(author ===; // true

// this will trigger db call, we could also use `orm.em.findOne(Author,` to do the same
await author.init();
console.log(author.isInitialized()); // true
console.log(; // defined

Identity Map and Unit of Work

MikroORM uses the Identity Map in background to track objects. This means that whenever you fetch entity via EntityManager, MikroORM will keep a reference to it inside its UnitOfWork, and will always return the same instance of it, even if you query one entity via different properties. This also means you can compare entities via strict equality operators (=== and !==):

const authorRepository = orm.em.getRepository(Author);
const jon = await authorRepository.findOne({ name: 'Jon Snow' }, ['books']);
const jon2 = await authorRepository.findOne({ email: '' });
const authors = await authorRepository.findAll(['books']);

// identity map in action
console.log(jon === authors[0]); // true
console.log(jon === jon2); // true

// as we always have one instance, books will be populated also here

Another benefit of Identity Map is that this allows us to skip some database calls. When you try to load an already managed entity by its identifier, the one from Identity Map will be returned, without querying the database.

The power of Unit of Work is in running all queries inside a batch and wrapped inside a transaction (if supported by given driver). This approach is usually more performant as opposed to firing queries from various places.


OneToMany and ManyToMany collections are stored in a Collection wrapper. It implements iterator so you can use for of loop to iterate through it.

Another way to access collection items is to use bracket syntax like when you access array items. Keep in mind that this approach will not check if the collection is initialized, while using get method will throw error in this case.

// find author and populate his books collection
const author = orm.em.findOne(Author, '...', ['books']);

for (const book of author.books) {
console.log(book); // instance of Book

console.log(author.books.contains(book)); // true
console.log(author.books.contains(book)); // false
console.log(author.books.count()); // 1
console.log(author.books.getItems()); // Book[]
console.log(author.books.getIdentifiers()); // array of primary keys of all items

More information about collections can be found in the docs.

What’s next?

So you read through the whole article, got here and still not satisfied? There are more articles to come (beginning with integration manual for popular frameworks like Express or NestJS), but you can take a look at some advanced features covered in docs right now:

To start playing with MikroORM, go through quick start and read the docs. You can also take a look at example integrations with some popular frameworks.

Like MikroORM? ⭐️ Star it on GitHub and share this article with your friends.

This article was originally published on Medium: