The N+1 Problem Is a Database Problem, Not an ORM Problem
The most common performance problem in ORM-based applications is N+1 queries. And the conventional wisdom is that it’s the ORM’s fault — ORMs are “too abstracted,” developers should “learn SQL,” eager loading should “always be specified.”
This is wrong. N+1 is a database problem.
Why N+1 exists
N+1 happens because SQL databases have no concept of an “object graph.” When your ORM asks for users with their posts, the database sees two unrelated queries:
SELECT * FROM users WHERE active = true;
-- For each user:
SELECT * FROM posts WHERE user_id = ?;The database doesn’t know these queries are related. It doesn’t know you want a graph. It just executes SQL strings and returns flat rows.
The ORM could try to batch these into a JOIN, but JOINs create a different problem: duplicate rows. A user with 10 posts appears 10 times in the result set. The ORM has to deduplicate and reconstruct the object graph from ambiguous flat data.
The workarounds don’t work
Eager loading (Prisma’s include, Django’s prefetch_related) is a developer hint that says “also load this relation.” It helps, but:
- You have to remember to add it everywhere
- Miss one include, and you’re back to N+1
- It often over-fetches data you don’t need
- It doesn’t compose well with dynamic queries
DataLoader/batching (the GraphQL approach) batches N queries into one WHERE IN clause. Better, but:
- Still two round-trips minimum
- Doesn’t work across multiple relation levels
- Requires separate infrastructure (DataLoader, batch functions)
- The database still doesn’t know what you need
Raw SQL works, but you lose the ORM’s type safety, migration support, and abstraction benefits.
The real fix
The real fix is a database that understands graph fetches. When an ORM says “give me users with their posts and comments,” the database should understand that as a single graph operation, optimize it internally, and return structured results.
This is what ormDB does. ormDB is a relational database engine where the native query language is entity/relation/graph-fetch. Unlike traditional ORMs that patch over the problem, ormDB fixes it at the engine level. There is no “N+1” because there is no “1 query per relation.” The database processes the entire graph request as one operation and returns entity blocks and edge blocks that the ORM assembles into objects.
No eager loading hints. No DataLoader. No raw SQL. The ORM declares what it needs, and the database delivers it efficiently. Every time.
N+1 is a database problem. We fixed it in the database. Learn more in our detailed guide to solving N+1 queries, or see how ormDB compares to PostgreSQL and traditional ORMs.
Frequently Asked Questions
What is the N+1 query problem?
The N+1 problem occurs when an ORM loads a list of N items, then issues one additional query per item to load related data. Loading 10 users with their posts requires 1 query for users + 10 queries for posts = 11 queries. This scales linearly and kills performance.
Don't ORMs already solve N+1 with eager loading?
Eager loading is a workaround, not a solution. It requires developers to remember to add include/prefetch hints everywhere. Miss one, and you have N+1. It also often over-fetches data. ormDB solves this at the database level — every query is a graph fetch by default.
How does ormDB eliminate N+1 queries?
ormDB's native query language is graph fetches. When you request an entity with its relations, ormDB compiles that into a single optimized operation internally. The database understands the full request and returns structured entity blocks. There is no concept of 'one query per relation' because the database processes the entire graph.
Can't I just write better SQL?
You can write JOINs manually, but then you lose the ORM's abstraction benefits and deal with ambiguous duplicate rows. ormDB gives you the performance of optimized queries with the developer experience of an ORM, because the database understands both.