Backend & Node.js · APIs, data and failure
What are the trade-offs of using an ORM?
Short answer
An ORM improves productivity, type safety and migration tooling, but it can hide query cost, encourage N+1 access and make complex SQL awkward. Use it with visibility into the generated SQL and a raw-SQL escape hatch.
An ORM maps tables to objects and gives you a query API, relationships, validation and migrations. That reduces boilerplate for CRUD. The cost is abstraction: it is easy to write code that looks cheap but generates expensive queries or many round trips.
const users = await prisma.user.findMany({
where: { active: true },
select: { id: true, email: true },
take: 50,
});
const rows = await prisma.$queryRawUnsafe(
"SELECT tenant_id, count(*) FROM users GROUP BY tenant_id",
);Where ORMs help and hurt
- Help: CRUD, relationships, migrations, type safety and input mapping
- Help: consistent handling of timestamps, soft deletes and tenant scoping
- Hurt: lazy loading that causes N+1 queries
- Hurt: complex analytics, window functions and bulk operations
- Hurt: generated SQL that changes across versions or ignores an index
- Hurt: an abstraction that leaks when you need locking or isolation control
The mature approach is to use the ORM for ordinary application queries and drop to SQL for hot paths, reporting and bulk work. Log slow queries and generated SQL in development. Measure at the database, not only at the application layer.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1How do you prevent N+1 queries with an ORM?
- 2When should you drop to raw SQL?
- 3How do you inspect the SQL an ORM generates?
- 4Why are destructive migrations risky?
Say it in the interview
I use an ORM for the productive parts: CRUD, relationships, typed queries and migrations. I do not trust it blindly, because lazy loading can hide N+1 queries and complex reporting often needs real SQL. I log generated queries, add query-count tests and keep a raw-SQL escape hatch. The ORM is a tool for the common case, not a substitute for understanding the database.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Backend & Node.js mock interview and get scored feedback on depth, clarity and confidence.