Coder Legion - Recent posts tagged query-optimization

INNER JOIN vs Correlated Subquery in SQL: What Is Actually Faster?

Mon, 22 Jun 2026 20:57:21 +0000

Most SQL developers hear the same rule early: always prefer INNER JOIN over correlated subqueries, because subqueries create an N+1 performance problem.

That rule is useful, but it is not always true.

I tested this on four engines (MySQL, Oracle, PostgreSQL, SQLite) and got mixed results. In some cases, the correlated subquery was faster than the join query.

If you want to validate the same patterns yourself, you can run these examples in live sandboxes and practice similar SQL tasks on sqltest.online.

What You Will Learn

what INNER JOIN does best;
when a correlated subquery can be competitive;
why execution plans matter more than "golden rules";
how to benchmark both approaches correctly.

What Is INNER JOIN in SQL?

INNER JOIN returns only rows that match in both tables.

Why it matters: it is usually the cleanest set-based way to combine data, and often gives the optimizer strong options.

SELECT
    c.customer_id,
    c.name,
    o.order_id
FROM customers c
INNER JOIN orders o
    ON c.customer_id = o.customer_id;

In many workloads, this is exactly what you want. But performance still depends on table sizes, indexes, and optimizer decisions.

Benchmark Scenario

I used a small outer table and a larger inner table:

customers: 25 rows
orders: 1000 rows
index on orders(customer_id)

Task: return each customer with the number of their orders.

Two Query Patterns

Pattern A: JOIN + GROUP BY

SELECT
    c.customer_id,
    COUNT(o.order_id) AS orders_count
FROM customers c
LEFT JOIN orders o
    ON c.customer_id = o.customer_id
GROUP BY c.customer_id;

Note: I used LEFT JOIN here to keep customers with zero orders. If you only need matched rows, use INNER JOIN.

Pattern B: Correlated Subquery

SELECT
    c.customer_id,
    (
        SELECT COUNT(o.order_id)
        FROM orders o
        WHERE o.customer_id = c.customer_id
    ) AS orders_count
FROM customers c;

The second form looks like classic N+1, but an index can make each lookup very cheap.

How to Inspect the Real Cost

Use execution plans, not assumptions:

MySQL / PostgreSQL: EXPLAIN ANALYZE
SQLite: EXPLAIN QUERY PLAN
Oracle: EXPLAIN PLAN FOR ... + DBMS_XPLAN.DISPLAY

Results Summary Across Engines

MySQL 8 and Oracle 23c

In my tests, the correlated subquery often won.

Why: with a small outer table (25 customers), the optimizer could do very fast indexed lookups on orders(customer_id) per customer. That was cheaper than building larger join/group intermediate work.

PostgreSQL 16

JOIN + GROUP BY won in my test.

Why: PostgreSQL produced an efficient set-based plan and handled the join/aggregate path very well.

SQLite

Practical tie.

Both variants ended with very similar plans and near-identical timing on this dataset.

Why the INNER JOIN Rule Sometimes Fails

The "always use INNER JOIN" advice fails when it ignores three variables:

Database engine optimizer behavior
Data distribution and table size ratio
Index availability and quality

SQL performance is not about syntax preference. It is about the physical plan your engine chooses.

Common Mistakes

assuming INNER JOIN is always faster without checking plans;
forgetting that INNER JOIN removes non-matching rows;
testing once without warm-up runs;
benchmarking without a supporting index;
comparing query text instead of comparing actual execution plans.

Practical Checklist

Before choosing INNER JOIN or correlated subquery:

Add the right index (here: orders(customer_id)).
Run both query variants.
Capture execution plans.
Compare timing over several runs.
Pick the query that is both correct and fast for your engine.

Final Takeaway

INNER JOIN is a strong default and often the right choice, but it is not a universal performance guarantee.

The best query is the one that produces the best execution plan on your actual database, with your actual data.

Oracle AI Vector Search: Querying Vectors and Optimizing with Indexes

Mon, 16 Feb 2026 08:23:55 +0000

Oracle Database 23ai's AI Vector Search enables powerful semantic search capabilities, but to truly harness its potential, you need to understand how to query vector data efficiently and when to use vector indexes. This guide explores querying vectors and optimizing performance with specialized vector indexes.

Running Basic Queries on Vectors

Combining Vector and Relational Data

One of Oracle AI Vector Search's most powerful features is the ability to combine vector data with traditional relational data in a single query. This unified approach eliminates data fragmentation and allows you to perform semantic searches alongside business logic filters.

Basic Query Pattern:

-- Create table with both relational and vector data
CREATE TABLE products (
    product_id NUMBER PRIMARY KEY,
    product_name VARCHAR2(200),
    description CLOB,
    price NUMBER(10,2),
    category VARCHAR2(100),
    in_stock VARCHAR2(1),
    description_vector VECTOR(384, FLOAT32)
);

-- Insert sample data
INSERT INTO products VALUES (
    1001,
    'Wireless Headphones',
    'Premium noise-cancelling Bluetooth headphones with 30-hour battery life',
    299.99,
    'Electronics',
    'Y',
    VECTOR_EMBEDDING(doc_model USING 
        'Premium noise-cancelling Bluetooth headphones with 30-hour battery life' AS data)
);

-- Query combining vector similarity with relational filters
SELECT 
    product_name,
    price,
    category,
    VECTOR_DISTANCE(
        description_vector,
        VECTOR_EMBEDDING(doc_model USING 'wireless audio device' AS data),
        COSINE
    ) AS similarity_score
FROM products
WHERE price < 500
    AND in_stock = 'Y'
    AND category = 'Electronics'
ORDER BY similarity_score
FETCH FIRST 10 ROWS ONLY;

Selecting Vector Data

You can select vector data using the asterisk (*) keyword just like any other column:

-- Select all columns including vectors
SELECT * FROM products;

-- Select specific columns including the vector
SELECT product_id, product_name, description_vector 
FROM products;

-- Vector dimensions can be extracted
SELECT 
    product_name,
    VECTOR_DIMENSION_COUNT(description_vector) AS dimensions,
    VECTOR_DIMENSION_FORMAT(description_vector) AS format
FROM products;

Important Restriction: No Comparison Operators Between Vectors

Standard comparison operators (such as =, >, <, >=, <=, !=) are not allowed between vectors. You cannot directly compare vectors using these operators.

Invalid Operations:

-- These will cause errors
SELECT * FROM products WHERE description_vector = other_vector;
SELECT * FROM products WHERE description_vector > other_vector;
SELECT * FROM products WHERE description_vector < other_vector;

Valid Operations:

Instead, use specialized vector distance functions:

-- Correct: Use VECTOR_DISTANCE function
SELECT 
    product_name,
    VECTOR_DISTANCE(description_vector, :query_vector, COSINE) AS distance
FROM products
ORDER BY distance
FETCH FIRST 5 ROWS ONLY;

-- Correct: Use shorthand operators
SELECT product_name
FROM products
ORDER BY description_vector <=> :query_vector  -- Cosine distance
FETCH FIRST 5 ROWS ONLY;

Understanding Vector Indexes

Vector indexes are specialized data structures that dramatically improve query performance on vector data. Without indexes, every similarity search performs an exhaustive comparison against all vectors in the table—a process that becomes prohibitively slow as datasets grow.

Why Vector Indexes Matter

The Problem:

Exhaustive Search: Compares query vector against every vector in the table
Time Complexity: O(n) - grows linearly with dataset size
Real Impact: Searches that take seconds can become hours-long operations

The Solution:
Vector indexes use sophisticated techniques to reduce the search space:

Clustering: Groups similar vectors together
Partitioning: Divides the vector space into manageable regions
Neighbor Graphs: Creates efficient navigation paths through vector space

The Result:
Vector indexes greatly reduce search space, making searches appear quick and extremely efficient, often reducing search time from hours to milliseconds.

Types of Vector Indexes

Oracle AI Vector Search supports three types of vector indexes:

1. In-Memory Neighbor Graph (HNSW) Index

HNSW (Hierarchical Navigable Small World) is a graph-based index that provides the fastest query performance.

Characteristics:

In-memory only index that can require a lot of memory for large datasets
Extremely fast query performance (milliseconds)
Uses hierarchical layers for efficient navigation
Best for datasets that fit in available memory

Creating an HNSW Index:

CREATE VECTOR INDEX product_hnsw_idx ON products (description_vector)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95;

Memory Requirements:

To roughly determine the memory size needed to store an HNSW index, use the following formula: 1.3 number of vectors number of dimensions * size of your vector dimension type

Example Calculation:

1 million vectors × 384 dimensions × 4 bytes (FLOAT32) × 1.3 = ~2 GB

2. Neighbor Partition (IVF) Index

IVF (Inverted File Flat) is a storage-based index that balances search quality with reasonable speed.

Characteristics:

Storage-based index not constrained by memory like HNSW
Uses buffer cache and disk storage
Can be used for very large datasets and still provide excellent performance compared to exhaustive similarity search
Supports global and local partitioning

Creating an IVF Index:

CREATE VECTOR INDEX product_ivf_idx ON products (description_vector)
ORGANIZATION NEIGHBOR PARTITIONS
DISTANCE COSINE
WITH TARGET ACCURACY 95;

When to Use IVF:

Dataset is too large to fit in memory
RAM is limited or constrained
Need to support very large (billion-scale) datasets
Working with partitioned tables

3. Hybrid Vector Index

Hybrid indexes combine full-text search with semantic vector search in a single index.

Creating a Hybrid Index:

CREATE VECTOR INDEX product_hybrid_idx ON products (description)
ORGANIZATION HYBRID
PARAMETERS('EMBEDDING MODEL doc_model');

Benefits:

Single index for both keyword and semantic searches
Run textual queries, vector similarity queries, or hybrid queries
Ideal for applications needing both search approaches

Vector Pool Memory Configuration

The Vector Pool is memory allocated in SGA to store Hierarchical Navigable Small World (HNSW) vector indexes and all associated metadata. Proper configuration is essential for HNSW index performance.

Configuring Vector Memory Size

At CDB (Container Database) Level

At the CDB level, VECTOR_MEMORY_SIZE specifies the current size of the Vector Pool:

-- Set vector memory size at CDB level
ALTER SYSTEM SET VECTOR_MEMORY_SIZE = 1G SCOPE=BOTH;

Note: A database restart is required to apply this parameter change.

At PDB (Pluggable Database) Level

The maximum PDB VECTOR_MEMORY_SIZE value is limited to 70% of the PDB sga_target. PDBs inherit settings from the CDB but can specify their own maximum usage.

-- Check current SGA target
SELECT value FROM V$PARAMETER WHERE name='sga_target';

-- PDB inherits from CDB and can set maximum
-- Maximum = 70% of PDB's sga_target

Automatic Vector Pool Growth

Oracle 23ai supports automatic vector pool management:

If VECTOR_MEMORY_SIZE is set to 1 and the sga_target is greater than 0 at CDB initialization, HNSW index creation will automatically grow the vector memory pool to satisfy the new index

-- Enable automatic growth
ALTER SYSTEM SET VECTOR_MEMORY_SIZE = 1 SCOPE=SPFILE;

Memory Considerations

Important Points:

Vector indexes are stored in this pool along with vector metadata
HNSW indexes require significant RAM
RAM constrains the vector index size
IVF indexes use buffer cache and disk, not heavily dependent on Vector Pool
IVF indexes use memory either from the vector pool if defined or the shared pool to speed up index creation and during DML operations

Monitoring Vector Pool:

-- Check vector pool allocation and usage
SELECT 
    pool,
    alloc_bytes,
    used_bytes,
    populate_status
FROM V$VECTOR_MEMORY_POOL;

-- Check individual index memory usage
SELECT 
    owner,
    index_name,
    index_organization,
    allocated_bytes,
    used_bytes,
    num_vectors
FROM V$VECTOR_INDEX;

Choosing the Right Index Type

Decision Matrix

Factor	HNSW	IVF	Hybrid
Speed	Fastest (milliseconds)	Fast (seconds)	Medium
Memory	High (in-memory)	Low (disk-based)	Medium
Accuracy	Highest (95-99%+)	High (90-99%)	Variable
Dataset Size	Small to Medium	Large to Huge	Medium
Best For	Speed-critical apps	Memory-constrained environments	Mixed query types

Practical Guidelines

Use HNSW When:

Dataset fits comfortably in available memory
Query speed is critical (real-time applications)
You can allocate sufficient Vector Pool memory
Working with up to millions of vectors

Use IVF When:

Dataset is too large for available memory
Working with billions of vectors
RAM is limited or expensive
Using partitioned tables for very large datasets

Use Hybrid When:

Application needs both keyword and semantic search
Users perform mixed query types
Want to simplify index management

Performance Optimization Tips

1. Index Configuration

Target Accuracy:

-- Higher accuracy = slower but more precise
WITH TARGET ACCURACY 99;  -- Very precise

-- Lower accuracy = faster but less precise  
WITH TARGET ACCURACY 90;  -- Still good for most cases

Balance accuracy with performance needs. TARGET ACCURACY between 90-99% provides excellent results.

2. Memory Allocation

-- Allocate adequate memory for HNSW indexes
-- Use formula: 1.3 × vectors × dimensions × format_size

-- Example for 1M vectors, 384 dimensions, FLOAT32:
-- 1.3 × 1,000,000 × 384 × 4 = ~2 GB
ALTER SYSTEM SET VECTOR_MEMORY_SIZE = 2G SCOPE=BOTH;

3. Query Optimization

-- Use FETCH FIRST for better performance
SELECT product_name, similarity_score
FROM (
    SELECT 
        product_name,
        VECTOR_DISTANCE(description_vector, :query_vec, COSINE) AS similarity_score
    FROM products
    WHERE category = 'Electronics'  -- Apply filters early
)
ORDER BY similarity_score
FETCH FIRST 10 ROWS ONLY;  -- Limit results

4. Approximate vs. Exact Search

-- Approximate search (uses index, faster)
SELECT product_name
FROM products
ORDER BY VECTOR_DISTANCE(description_vector, :query_vec, COSINE)
FETCH FIRST 10 ROWS ONLY;

-- Exact search (no index, 100% accurate, slower)
SELECT product_name
FROM products
ORDER BY VECTOR_DISTANCE(description_vector, :query_vec, COSINE)
FETCH EXACT FIRST 10 ROWS ONLY;

Use approximate search for most queries; reserve exact search for critical accuracy requirements.

Real-World Example: E-commerce Product Search

-- Step 1: Create table
CREATE TABLE products (
    product_id NUMBER PRIMARY KEY,
    name VARCHAR2(500),
    description CLOB,
    price NUMBER(10,2),
    category VARCHAR2(100),
    rating NUMBER(3,2),
    reviews_count NUMBER,
    desc_vector VECTOR(384, FLOAT32)
);

-- Step 2: Configure memory (1M products × 384 dims × 4 bytes × 1.3 = ~2GB)
ALTER SYSTEM SET VECTOR_MEMORY_SIZE = 2G SCOPE=BOTH;

-- Step 3: Create HNSW index
CREATE VECTOR INDEX products_hnsw_idx ON products (desc_vector)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95;

-- Step 4: Query with combined filters
SELECT 
    name,
    price,
    rating,
    VECTOR_DISTANCE(
        desc_vector,
        VECTOR_EMBEDDING(model USING 'comfortable running shoes' AS data),
        COSINE
    ) AS relevance
FROM products
WHERE price BETWEEN 50 AND 200
    AND category = 'Footwear'
    AND rating >= 4.0
    AND reviews_count > 100
ORDER BY relevance
FETCH FIRST 10 ROWS ONLY;

Key Takeaways

Queries can combine vector and relational data in a single SQL statement, eliminating data fragmentation
Standard comparison operators (=, >, <) cannot be used between vectors - use VECTOR_DISTANCE functions instead
Vector indexes dramatically improve performance by reducing search space through clustering, partitioning, and graphs
HNSW indexes provide fastest queries but require significant memory (Formula: 1.3 × vectors × dimensions × format_size)
IVF indexes work for very large datasets using disk storage, not constrained by RAM
Vector Pool memory must be configured for HNSW indexes at CDB level with VECTOR_MEMORY_SIZE parameter
Database restart required when changing VECTOR_MEMORY_SIZE (unless using automatic growth)
PDB maximum is 70% of sga_target, inheriting from CDB configuration
Choose index type based on dataset size and memory availability - HNSW for speed, IVF for scale

By understanding these concepts and properly configuring vector indexes, you can build high-performance semantic search applications that seamlessly integrate AI capabilities with traditional relational database operations.

We Measured the N+1 Query Problem. The Numbers Are Worse Than You Think.

Thu, 12 Feb 2026 00:58:11 +0000

I kept seeing the same advice in every ORM tutorial: "Watch out for N+1 queries." Every code review, every blog post, every conference talk. Always the same warning, never the actual numbers.

So I decided to measure it.

I built a benchmark suite, seeded a PostgreSQL database, wrote the "bad" code that everyone warns about, wrote the "good" code that everyone recommends, and ran them side by side. Four different scenarios, each one timed and query-counted down to the individual SQL statement.

The short version? On a tiny dataset — just 100 users — the worst pattern was 22x slower and fired 200 unnecessary queries. And that's the conservative estimate, because I ran everything on localhost where network latency is basically zero.

Here's what I found.

What's the N+1 problem, actually?

You probably already know this, but it's worth being precise about it because the devil is in the details.

Say you've got 100 users and you want each user's posts. The naive approach does this:

One query to grab all users
Then, inside a loop, one query per user to get their posts

That's 101 database round-trips. The "1" to get the users, plus "N" (100) to get each user's posts. Hence, N+1.

The thing is, each individual query is fast — sub-millisecond in most cases. But every single one of those queries carries overhead. The app has to send the request to PostgreSQL, PostgreSQL has to parse it, plan it, execute it, serialise the results, and send them back. Do that 101 times and the overhead stacks up fast.

The fix is usually straightforward: tell your ORM to grab the related data upfront. In Prisma, that's the include keyword. Instead of 101 queries, you get 2. Same result, fraction of the time.

But how much of a fraction? That's what I wanted to pin down.

How I set this up

I wanted the benchmarks to be fair and reproducible, so here's what I did.

The stack: Prisma 6.3.1, PostgreSQL 17, TypeScript, Node.js 22 — all running locally on the same machine. Running the database locally means there's no network hop between the app and the database. That makes the numbers more conservative than what you'd see in production, where the database is usually on a separate server (or across the internet, if you're using a managed service).

The data: 100 users, each with 3 posts, 2 comments per post, and 2 orders. All generated with Faker so the string content is realistic — not just "test" repeated a thousand times. Serialisation costs are real costs, and I didn't want to cheat there.

The measurement: Every query that Prisma sends to PostgreSQL gets intercepted and counted. Not estimated, not sampled — counted. Each benchmark runs 5 times (after a warmup run) using performance.now(), and I report the mean, median, P95, and P99.

The test cases:

#	What it tests	Relationship
TC1	Users with their posts	One-to-many
TC2	Users → posts → comments	Three-level nesting
TC3	Orders with their user	Many-to-one (reverse)
TC4	Active orders, conditionally load user	Conditional access

Each test case has a "bad" version (the N+1 pattern) and a "good" version (the recommended fix). Both return the exact same data.

Source code for everything: github.com/liangk/empirical-study

TC1: Users with posts — the textbook case

This is the one everyone uses as an example. Grab all users, loop through them, fetch posts for each one.

The bad version fires 101 queries. The good version uses include: { posts: true } and fires 2.

Metric	Bad (N+1)	Good (Eager)	Improvement
Queries	101	2	98.0% fewer
Avg time	39.31 ms	4.28 ms	9.2x faster
Median	38.96 ms	4.21 ms	9.3x faster
P95	41.49 ms	4.53 ms	9.2x faster

Here's what caught my attention: the variance in the good version is tiny. The standard deviation is under 0.25ms. That matters if you're building an API where you care about tail latency — and you should care about tail latency.
The bad version stays surprisingly steady too, with a relatively small variance. It feels fine at this scale. 39ms isn't going to trigger any alarms. But it's doing 50x more work than it needs to, and the cost grows linearly with your user count.

TC2: Nested relationships — where it gets ugly

This one goes deeper. Users → posts → comments. Three levels of entities.

The bad code has two nested loops, each firing queries. With 100 users and 3 posts each, that's 1 query for users + 100 for posts + 300 for comments = 401 queries.

The good version? Nested include directives. 3 queries total. One per entity level, no matter how many records.

Metric	Bad (N+1)	Good (Eager)	Improvement
Queries	401	3	99.3% fewer
Avg time	153.59 ms	10.50 ms	14.6x faster
Median	143.21 ms	10.07 ms	14.2x faster
P95	185.53 ms	11.82 ms	15.7x faster

401 queries versus 3. That's not a percentage I need to calculate to know it's bad.

But the timing tells a more interesting story. The bad version's P95 is 185ms — that's 29% higher than its median. Some of those runs are hitting extra overhead, probably connection pool pressure or plan cache misses from hammering PostgreSQL with 400 queries in rapid succession. The good version's P95 is only 17% above its median. Fewer queries means less contention, which means more predictable performance.

And this is the part that should worry you: 153ms with 100 users. The N+1 cost here isn't linear — it's multiplicative. Each level of nesting multiplies the query count. The general formula looks something like:

Queries = 1 + N + (N × posts_per_user) + (N × posts_per_user × comments_per_post) + ...

With eager loading, it's just the number of entity levels + 1. Always. Doesn't matter if you've got 100 users or 100,000.

If you're thinking "well, my app doesn't have three levels of nesting" — check again. User → projects → tasks. Store → products → reviews. Organization → teams → members. It's more common than you'd expect.

TC3: Orders → User — the biggest speedup

This one flips the relationship. Instead of fetching children for each parent, you're fetching the parent for each child. Classic scenario: you've got an orders list and you want to show the customer name next to each order.

The bad version grabs all orders (200 of them — 2 per user), then calls findUnique for each order's user. That's 201 queries.

The good version adds include: { user: true }. Two queries.

Metric	Bad (N+1)	Good (Eager)	Improvement
Queries	201	2	99.0% fewer
Avg time	82.54 ms	3.72 ms	22.2x faster
Median	86.10 ms	3.66 ms	23.5x faster
P95	88.71 ms	4.02 ms	22.1x faster

22.2x. That's the largest speedup across all four test cases.

Why so much bigger than TC1? Two reasons. First, there are more records involved — 200 orders versus 100 users. More queries means more wasted overhead. Second, many of those findUnique calls are fetching the same user — each user has 2 orders, so each user gets fetched twice. Prisma doesn't deduplicate those calls. It doesn't have an identity map or a request-level cache. So you're not just making too many queries — you're making redundant ones too.

The eager loading version sidesteps all of that. Prisma resolves the relationships from the batch result set in memory.

TC4: Conditional loading — the tricky one

Here's where things get interesting from a design perspective. You've got active orders, but you only need user data for orders where requiresUserData is true. Not all of them.

You can't just slap include: { user: true } on this one — that would over-fetch user data for orders that don't need it. So the fix is different: collect the user IDs you actually need, fetch them all in one batch, build a lookup map, and assign the results.

The bad version loops through active orders and calls findUnique for each one that needs user data. About 70% of them do, which gave us 56 queries.

The good version collects the needed IDs into a Set, does one findMany with WHERE id IN (...), builds a Map, and does the assignment in a second pass. Two queries total.

Metric	Bad (N+1)	Good (Batch)	Improvement
Queries	56	2	96.4% fewer
Avg time	22.75 ms	2.16 ms	10.5x faster
Median	23.05 ms	2.11 ms	10.9x faster
P95	23.49 ms	2.57 ms	9.1x faster

Even though the conditional logic cuts the query count from a potential 200+ down to 56, you're still paying a 10.5x penalty. Partial N+1 is still N+1.

This batch-query pattern is worth keeping in your back pocket. It works everywhere — not just in Prisma, not just in JavaScript. Collect the IDs, batch fetch, build a map, assign. You trade a bit of memory for the Map and an extra loop, but you eliminate dozens (or hundreds or thousands) of database round-trips. That trade-off pays for itself every time.

The full picture

Here's everything in one table:

Test Case	Bad Queries	Good Queries	Reduction	Bad Time	Good Time	Speedup
TC1: One-to-many	101	2	98.0%	39.31 ms	4.28 ms	9.2x
TC2: Nested (3-level)	401	3	99.3%	153.59 ms	10.50 ms	14.6x
TC3: Many-to-one	201	2	99.0%	82.54 ms	3.72 ms	22.2x
TC4: Conditional	56	2	96.4%	22.75 ms	2.16 ms	10.5x

A few things jump out.

The optimised versions never exceed 3 queries. Doesn't matter which pattern, doesn't matter how many records. That's the whole point — you go from O(N) queries to O(1). And the benefit scales with your data. At 1,000 users, the bad TC2 version would fire over 4,000 queries. The good version would still fire 3.

The speedup correlates with query count. TC3 had the most queries (201) and the biggest speedup (22.2x). TC4 had the fewest (56) and the smallest speedup (10.5x). Per-query overhead is roughly constant, so more queries = more waste = more gain from fixing it.

These numbers are the floor, not the ceiling. I ran everything on localhost. In production, add network latency between app and database — maybe 1-5ms per round-trip. Now multiply that by 401 queries. That's where a 150ms endpoint becomes a 2-second one.

What happens at 1,000 users?

I ran the same benchmarks on a 10x larger dataset. 1,000 users, 3,000 posts, 6,000 comments, 2,000 orders.

Here's the medium dataset alongside the small one:

Test Case	100 Users		1,000 Users		Change
TC1: One-to-many	39ms → 4ms	9.2x	364ms → 35ms	10.4x	Slightly worse
TC2: Nested	154ms → 11ms	14.6x	1,271ms → 88ms	14.5x	About the same
TC3: Many-to-one	83ms → 4ms	22.2x	739ms → 28ms	26.5x	Noticeably worse
TC4: Conditional	23ms → 2ms	10.5x	169ms → 8ms	21.9x	Way worse

A few things I didn't expect.

TC2 blew past 1 second. 1,271ms for a single data fetch. With 4,001 queries. On localhost. In production with a network hop, you're looking at multiple seconds — from one API call. That's not a performance issue. That's a broken endpoint.

TC4's speedup doubled. It went from 10.5x to 21.9x. That surprised me. But the reason makes sense once you look at the numbers: the batch query version barely grew (2ms → 8ms, only 3.6x) while the loop-with-findUnique version grew 7.4x. The batch approach has near-constant overhead regardless of how many IDs you're fetching — PostgreSQL is really good at WHERE id IN (...) queries. The loop approach pays full overhead for every single query.

TC3 got worse too. 22.2x → 26.5x. Same story — the good version scales better than the bad version because batch fetching is fundamentally more efficient than doing it one at a time.

The bad code scales roughly linearly. 10x more data, roughly 8-9x more time across the board. Which makes sense — 10x more users means ~10x more queries in the loop, and per-query overhead is approximately constant.

The good code sometimes scales better than linearly. TC4's good version grew only 3.6x for 10x more data. The batch query with deduplication is doing less redundant work at scale.

The bottom line: the N+1 penalty doesn't shrink as you scale. It gets worse. Every test case either maintained or increased its speedup factor at 1,000 users compared to 100. If you've got N+1 patterns in your code and you're thinking "I'll fix it when we scale" — the data says you're already paying for it.

How to spot this in your own code

The pattern is always the same: a database call inside a loop. If you see await prisma.something.findMany() or findUnique() inside a for, map, forEach, or any kind of iteration — that's your red flag.

Three ways to catch it:

Turn on query logging. Set log: [{ emit: "stdout", level: "query" }] in your Prisma client config. If you see the same SELECT statement repeated 50 times in a row, differing only in the WHERE clause value, you've got an N+1.

Use static analysis. Tools like Code Evolution Lab walk your AST (Abstract Syntax Tree) to find database calls nested inside loops. They can catch these before your code even runs — during CI, code review, or in your IDE. They'll also suggest the right fix for your specific ORM.

Watch your APM dashboards. If an endpoint's query count scales linearly with the number of records it returns, something is wrong. A healthy endpoint has a roughly constant query count.

Two fixes that cover almost everything

Across all four test cases, two patterns handled every situation:

Eager loading for cases where you know you'll need the related data. In Prisma, that's include. It works for one-to-many, many-to-one, and nested relationships. You can stack include directives as deep as your schema goes, and Prisma always resolves it in a constant number of queries (one per entity level).

Batch pre-fetching for cases where you need related data conditionally. Collect the IDs, do one findMany with WHERE IN, build a Map for O(1) lookup, and do the assignment in memory. It's a few extra lines of code, but it turns 56 queries into 2.

Both approaches do the same fundamental thing: they take the number of database round-trips from "proportional to your data" down to "constant, no matter how much data." That's the whole game.

What I'd push back on

There's a common belief that N+1 queries are a "scaling problem" — something you can ignore early and fix when your dataset gets big enough to matter.

The data doesn't support that.

At 100 users, we're already seeing 9x-22x slowdowns. At 1,000 users, it's 10x-27x. That's not a rounding error. If your API has a 200ms budget per endpoint (pretty standard), the bad TC2 version is already eating 75% of that with just 100 records and zero network latency. In production, you're probably blown past it.

The other thing I'd push back on: the idea that findUnique is somehow safe because it's a primary key lookup. It's fast per query, sure. But when you call it 200 times in a loop (TC3), the fixed overhead of 200 round-trips completely dominates. A fast query executed 200 times is slower than a slightly heavier query executed once.

What about the honesty section?

A few things that could affect how you read these numbers.

Localhost flatters the good version. With no network latency, the per-query overhead is as small as it can be. In production, the penalty for each extra query would be higher, which means the speedup numbers would be larger than what I measured. So think of these as conservative estimates.

I only tested 100 users. The scaling behaviour at 1K, 10K, and 100K records is something I want to measure next. I expect the gap to widen, not narrow, because connection pool contention and buffer pressure get worse with more queries.

This is Prisma-specific. Sequelize, TypeORM, and other ORMs have different internals. The per-query overhead might be higher or lower. The fix patterns are similar though — eager loading and batching work everywhere.

Warm caches. I did a warmup run before measuring, which means PostgreSQL's query plan cache and shared buffers are warm. Both versions benefit equally from this, so it shouldn't bias the comparison. But cold-start numbers might look different.

Try it yourself

Everything's open source:

git clone https://github.com/liangk/empirical-study.git
cd empirical-study
npm install
npx prisma db push
npm run seed -- small
npm run bench:all

Swap small for medium (1,000 users), large (10,000), or xlarge (100,000) to see how the numbers scale.

What's coming next

This is the first piece in a series I'm working on. The questions I still want to answer:

How do the numbers scale beyond 1K? The 1,000-user results are in (see above) and the penalties got worse, not better. Next up: 10K and 100K, where I expect connection pool contention to make things even uglier.
Can automated tools fix this? I'm going to feed the bad code into Code Evolution Lab and see if the auto-generated solutions perform as well as the hand-written ones.
Is Prisma better or worse than other ORMs? Same benchmarks, Sequelize and TypeORM. The per-query overhead profile might be very different.
What about concurrent load? All my benchmarks are single-threaded. Under real traffic, connection pool contention makes the N+1 penalty even worse.

The bottom line: the N+1 problem isn't a theoretical concern you can defer. It's a measurable, order-of-magnitude performance hit that shows up at 100 records and gets worse at 1,000. The nested pattern crossed 1.2 seconds. The conditional pattern's penalty doubled. And fixing it is rarely more than a one-line change.

The benchmark suite and raw data are on GitHub

This article was originally published on Stack Insight. For the best reading experience and future updates, visit the original post.