What is an ORM?

What an ORM means

ORM stands for Object-Relational Mapping. It names both a technique and the libraries that implement it. The problem it solves is a mismatch: relational databases store data in flat tables of rows and columns, while application code thinks in terms of objects with fields and relationships. An ORM bridges the two, mapping a database table to a class and each row to an object so you can load, modify, and save records as if they were ordinary in-memory data.

In practice that means writing something like "find the user with this id, then save the user's new email" in your own programming language, and letting the ORM generate the underlying SELECT and UPDATE statements. It handles the translation in both directions — turning your objects into SQL on the way down, and database rows back into objects on the way up.

Where it came from

ORMs rose to prominence in the early 2000s as object-oriented programming and relational databases collided in nearly every application. Tools like Hibernate in the Java world and the Active Record pattern popularized by Ruby on Rails made the mapping a standard part of building software, sparing developers from writing the same repetitive create-read-update-delete SQL for every table.

The pattern carried into every ecosystem. In the JavaScript and TypeScript world that modern web apps are built on, tools such as Prisma and Drizzle bring strong type safety to the mapping, so the shape of your database is reflected directly in your code and mistakes are caught by the compiler before they ever run. The goal throughout has stayed constant: less boilerplate, fewer hand-written queries, and a database layer that feels native to the language.

How it works

You define your data models — classes or schema definitions that mirror your tables and declare how they relate, such as a user having many orders. The ORM uses those definitions to generate SQL for the everyday operations: fetching a record by id, filtering a list, inserting a new row, updating fields, deleting. Many ORMs also manage migrations, generating the SQL that evolves your database schema as your models change so the structure and the code stay in sync.

The main thing to watch is performance, and the classic pitfall is the N+1 query problem: loading a list of records and then lazily fetching a related record for each one, firing one query plus one per row. The remedy is to tell the ORM to load the related data in a single query up front. Good ORMs make this easy and also let you drop to raw SQL for the rare query that needs hand tuning, so abstraction never becomes a cage.

When it matters

An ORM matters most when an application has many tables and a lot of routine data access, which describes almost every business application. It speeds development, reduces the surface area for SQL injection bugs because queries are parameterized by default, and — with a type-safe ORM — catches whole categories of errors at compile time. The trade-off is a layer of abstraction that can hide what the database is actually doing, so the discipline is to stay aware of the generated queries on your busiest paths and to reach for raw SQL when a query genuinely warrants it.

At QUANT LAB

We build in TypeScript on PostgreSQL, and we use a type-safe ORM as the default data layer so the database schema flows straight into the application's types. That means a typo in a column name or a wrong field type is a compile error rather than a production incident, and the editor autocompletes every query against the real shape of the data. Migrations live in version control alongside the code, so the schema evolves through the same reviewed pipeline as everything else.

We treat the ORM as a sharp tool, not a crutch. On the hot paths of an API we watch the generated SQL, eliminate N+1 patterns, and lean on database indexing so the queries the ORM emits stay fast. For the reporting corners of a SaaS platform where a complex aggregate beats anything an ORM would generate, we simply write the SQL by hand. The mapping handles the ninety percent that is routine; we hand-tune the rest.