Question

What is an ORM, and when should you not use one?

Vault Verified
Curated Intelligence
Definitive Source
Answer

An ORM — object-relational mapper — translates between the objects in your program and the tables in a relational database, so you write method calls instead of SQL.

What it gives you:

Less boilerplate. No manual mapping of result columns onto object fields, which is tedious and error-prone.

Type safety and autocompletion over your schema, in typed languages.

Parameterised queries by default, which prevents the most common form of SQL injection — a genuine and underrated security benefit.

Migrations, usually bundled, giving versioned schema changes.

Portability across databases, which sounds valuable and is rarely exercised in practice.

The object-relational impedance mismatch. Objects and relations are different models. Objects have identity, inheritance and graph-shaped references; relations have sets, keys and joins. The translation is never clean, and the leaks are where the problems appear.

Where ORMs go wrong:

The N+1 query problem. Fetch a hundred records, then access a related field on each, and the ORM silently issues a hundred additional queries. This is the single most common ORM performance disaster, and it is invisible in the code — the loop looks completely ordinary. Eager loading fixes it once you notice.

Generated SQL you did not intend. Complex queries can produce inefficient joins or fetch far more columns than needed.

Lazy loading surprises, including queries firing outside a transaction or session.

Abstraction that must be pierced anyway. Beyond a certain complexity you need to know SQL to diagnose the ORM's output — so the ORM adds a layer without removing the requirement.

When to reach for something else:

Analytical and reporting queries — aggregations, window functions, CTEs. Write SQL.

Bulk operations. Loading a million rows as objects to update them is enormously wasteful.

Performance-critical paths where you need control over the exact query plan.

A reasonable middle ground: a query builder for composable SQL without full object mapping, or an ORM used for straightforward access with raw SQL where it matters. Always log the generated SQL in development.

Related Questions