ORM

Object-Relational Mapping

Updated September 29, 20262 min read

In short

An ORM is a library that maps database tables to objects in your programming language, letting you read and write data with code instead of raw SQL.

What is an ORM?

An ORM, short for object-relational mapping, bridges two different worlds: the objects and classes your application code uses, and the tables and rows a relational database uses. With an ORM, a row in a users table becomes a User object, and saving that object writes the change back to the database.

Under the hood, the ORM generates SQL for you. You define models that describe your tables, then call methods like find, create, or update, and the ORM translates those calls into SQL queries, runs them, and converts the results back into objects. Most ORMs also handle schema migrations, relationships between tables, and parameterized queries that protect against SQL injection.

Popular ORMs include Hibernate for Java, Entity Framework for .NET, the Django ORM and SQLAlchemy for Python, Active Record for Ruby on Rails, and Prisma, Drizzle, and TypeORM for TypeScript. Think of an ORM as an interpreter: you speak your programming language, and it translates to SQL for the database.

ORMs save time and reduce repetitive code, but they can hide which queries actually run. A common pitfall is the N+1 query problem, where loading a list and then each item's related records triggers one query per item instead of a single joined query. Many teams use an ORM for everyday operations and write raw SQL or use a lighter query builder for complex or performance-critical queries.

At a glance

You work with objects and the ORM writes the SQL. It is easy to make it write too much, as in the N+1 query problem, so it pays to look at what it sends.

Key takeaways

An ORM maps database tables to classes and rows to objects.
It generates SQL for you, so you work in your programming language.
Most ORMs handle relationships, migrations, and parameterized queries.
Watch for hidden inefficiencies such as the N+1 query problem.

Example

Creating and querying records with an ORM (Prisma)typescript

// Insert a row without writing SQL by hand
const user = await prisma.user.create({
  data: { name: "Ada", email: "ada@example.com" },
});

// Roughly equivalent to:
// SELECT * FROM "User" WHERE email LIKE '%@example.com' ORDER BY name;
const users = await prisma.user.findMany({
  where: { email: { endsWith: "@example.com" } },
  orderBy: { name: "asc" },
});

Readers ask

Should I use an ORM or raw SQL?

An ORM is usually a good default for everyday create, read, update, and delete operations because it is faster to write and safer. Raw SQL is often better for complex reports or performance-critical queries, and many projects use both.

Does an ORM prevent SQL injection?

ORMs use parameterized queries by default, which protects against most SQL injection. You can still be vulnerable if you insert user input into the ORM's raw SQL features without parameters.

What is the N+1 query problem?

It happens when code runs one query to load a list of records and then one extra query for each record's related data. Most ORMs solve it with eager loading, which fetches the related data in one or two queries up front.

ORM