DEV Community: Rahul Patel

How to Detect and Fix N+1 Queries in Node.js The Complete Guide

Rahul Patel — Tue, 31 Mar 2026 15:02:56 +0000

N+1 queries silently kill your API performance. Learn what causes them, how to detect them manually, and how to auto-detect them with one line of middleware.

What is the N+1 Query Problem?

The N+1 query problem is one of the most common performance killers in web APIs. It happens when your code executes 1 query to fetch a list of items, then N additional queries to fetch related data for each item.

Example: You want to show 50 orders with their product names.

// ❌ BAD: N+1 — 51 queries total
app.get('/api/orders', async (req, res) => {
  const orders = await db.query('SELECT * FROM orders LIMIT 50');  // 1 query

  for (const order of orders) {
    order.product = await db.query(                                 // 50 queries
      'SELECT name FROM products WHERE id = $1',
      [order.product_id]
    );
  }

  res.json(orders);
});

This makes 51 database queries instead of 2. At 50 orders it's slow. At 500 orders, your API is dead.

Why N+1 Queries Are So Dangerous

The scary part? You won't notice them during development. With 5 test records, 6 queries take 10ms. In production with 500 records, those 501 queries take 5+ seconds.

Records	Queries	Approx Time
5	6	~10ms
50	51	~200ms
500	501	~3-5 seconds
5000	5001	~30+ seconds (timeout)

N+1 queries are the #1 reason APIs slow down as data grows.

How N+1 Happens in Common ORMs

Prisma

// ❌ N+1: Prisma executes separate queries for each user's posts
const users = await prisma.user.findMany();
for (const user of users) {
  user.posts = await prisma.post.findMany({ where: { authorId: user.id } });
}

// ✅ Fixed: Use include (eager loading)
const users = await prisma.user.findMany({
  include: { posts: true }
});

Sequelize

// ❌ N+1: Lazy loading each order's items
const orders = await Order.findAll();
for (const order of orders) {
  order.items = await order.getItems();
}

// ✅ Fixed: Eager loading with include
const orders = await Order.findAll({
  include: [{ model: Item }]
});

Mongoose

// ❌ N+1: Populating one by one
const orders = await Order.find();
for (const order of orders) {
  await order.populate('product');
}

// ✅ Fixed: Populate in the query
const orders = await Order.find().populate('product');

Raw SQL (pg / mysql2)

// ❌ N+1: Loop queries
const orders = await db.query('SELECT * FROM orders');
for (const order of orders) {
  const [product] = await db.query(
    'SELECT * FROM products WHERE id = $1',
    [order.product_id]
  );
  order.product = product;
}

// ✅ Fixed: JOIN or IN clause
const orders = await db.query(`
  SELECT o.*, p.name as product_name
  FROM orders o
  JOIN products p ON p.id = o.product_id
`);

How to Detect N+1 Queries - The Manual Way

Method 1: Count queries with a wrapper

let queryCount = 0;
const originalQuery = db.query.bind(db);
db.query = async (...args) => {
  queryCount++;
  return originalQuery(...args);
};

// After the request
console.log('Total queries:', queryCount);  // If this is 51 for 50 records... N+1!

Problems with this approach:

You have to add/remove this code manually
It doesn't tell you WHICH route has the problem
No per-request isolation (concurrent requests mix counts)
Doesn't work across async boundaries

Method 2: Database query logging

Enable query logging in your ORM:

// Prisma
const prisma = new PrismaClient({ log: ['query'] });

// Sequelize
const sequelize = new Sequelize({ logging: console.log });

// Mongoose
mongoose.set('debug', true);

Problems:

Floods your console with every query
No grouping by request
No automatic "this looks like N+1" detection
You have to manually count repeated patterns

The Better Way: Auto-Detect N+1 with One Line

What if your middleware could automatically track every database query per request, count them, and flag routes with suspiciously high query counts?

That's exactly what auto-api-observe does.

Install

npm install auto-api-observe

Add one line

const express = require('express');
const observe = require('auto-api-observe');

const app = express();
app.use(observe());  // That's it

What happens automatically

The middleware patches your database libraries (pg, mysql2, mongoose, prisma, knex, sequelize, ioredis, better-sqlite3) at the prototype level. For every request, you get:

{
  "method": "GET",
  "route": "/api/orders",
  "status": 200,
  "latency": 1850,
  "dbCalls": {
    "calls": 51,
    "totalTime": 1720,
    "slowestQuery": 80,
    "queries": [
      { "query": "SELECT * FROM orders", "source": "pg", "queryTime": 30 },
      { "query": "SELECT * FROM products WHERE id = ?", "source": "pg", "queryTime": 35 },
      { "query": "SELECT * FROM products WHERE id = ?", "source": "pg", "queryTime": 28 }
    ]
  }
}

When you see "calls": 51 on a GET request - that's your N+1.

Cloud Dashboard Detection

Add your API key to see it in the dashboard:

app.use(observe({ apiKey: process.env.APILENS_KEY }));

The Database page in the APILens dashboard automatically flags routes with high DB calls per request as potential N+1 issues.

The N+1 Query Detector table shows:

Route name
Average DB calls per request
Total queries
Flag for suspicious patterns

No manual counting. No query log parsing. It just works.

How Auto-Detection Works Under the Hood

AsyncLocalStorage creates a per-request context that follows the entire async chain
Prototype monkey-patching intercepts queries from 8 DB libraries at the driver level
Query masking replaces literal values with ? for security
Per-request aggregation counts calls, sums time, tracks the slowest query
~50ns overhead per DB call (vs 1-50ms actual query time)

The key insight: by patching at the driver level (not the ORM level), it works with ANY ORM - Prisma, Sequelize, TypeORM, Drizzle, Knex, or raw queries. You don't need to configure anything per-ORM.

Quick Comparison: N+1 Detection Methods

Method	Setup	Per-Request	Auto-Detect	Cross-ORM
Manual counter	~30 lines	No	No	No
ORM query logging	1 line per ORM	No	No	No
Datadog APM	30+ min	Yes	Partial	Yes
auto-api-observe	1 line	Yes	Yes	Yes

Summary

N+1 queries happen when you fetch N related records with N separate queries instead of 1
They're invisible during development but kill production performance
Every ORM has this problem - Prisma, Sequelize, Mongoose, raw SQL
Fix them with eager loading (include), JOINs, or IN clauses
Detect them automatically with auto-api-observe - one line of middleware, 8 DB libraries, zero config

Try it

npm install auto-api-observe

Dashboard: apilens.rest
GitHub: github.com/rahhuul/auto-api-observe
npm: auto-api-observe

Free during beta. Zero dependencies. 44 tests.

What tools do you use to detect N+1 queries in your Node.js APIs? I'd love to hear your approach.

I built a free Datadog alternative for Node.js here's what the dashboard looks like

Rahul Patel — Tue, 24 Mar 2026 13:51:19 +0000

Last month I shared a 1-line observability middleware for Express and Fastify. It logged requests to your console - method, route, status, latency.

Since then, I've added a lot:

Auto DB profiling (patches pg, mysql2, mongoose, prisma, knex, sequelize, ioredis, better-sqlite3)
A free cloud dashboard at apilens.rest
Per-query execution times with masked SQL
N+1 query detection
Geographic insights + bot detection
Real-time live request tailing

Here's what it looks like.

The Dashboard

Overview - KPIs + charts at a glance

Total requests, error rate, P95 latency, request volume over time, status distribution, method breakdown - all updating in real-time.

Request Log - every request, fully expanded

Click any request to see the full details: trace ID, IP, user agent, and every database query that request made - with masked SQL, source library, and individual execution times.

Database Performance - catch N+1 queries

See which routes make the most DB calls, find your slowest queries, and spot N+1 issues before your users do.

Setup: still 1 line

npm install auto-api-observe

Local only (no account needed)

const express = require('express');
const observe = require('auto-api-observe');

const app = express();
app.use(observe());

Every request logs structured JSON to your console:

{
  "method": "GET",
  "route": "/api/users/:id",
  "status": 200,
  "latency": 85,
  "latencyMs": "85ms",
  "traceId": "a1b2c3d4-...",
  "dbCalls": {
    "calls": 2,
    "totalTime": 45,
    "queries": [
      { "query": "SELECT * FROM users WHERE id = ?", "source": "pg", "queryTime": 30 },
      { "query": "SELECT * FROM profiles WHERE user_id = ?", "source": "pg", "queryTime": 15 }
    ]
  }
}

With cloud dashboard

app.use(observe({
  apiKey: process.env.APILENS_KEY,  // get one free at apilens.rest
}));

That's it. Data appears in your dashboard within seconds.

Auto DB Instrumentation

This is the feature I'm most proud of. The middleware automatically patches your DB libraries at startup - zero code changes needed.

Supported: pg, mysql2, mongoose, @prisma/client, knex, sequelize, ioredis, better-sqlite3.

It uses prototype monkey-patching + AsyncLocalStorage to track every query per request. You get:

Masked SQL strings (values replaced with ?)
Per-query execution time
Source library name
Total time and call count per request

When you see dbCalls.calls: 47 on a single endpoint - you've got an N+1 problem. No guesswork.

How it compares

Feature	auto-api-observe	Datadog	New Relic	Sentry
Setup	1 line	30+ min	30+ min	15+ min
Dependencies	0	50+	40+	30+
Auto DB profiling	8 libraries	Custom setup	Custom setup	No
N+1 detection	Built-in	No	No	No
Price	Free (beta)	$23/host/mo	$0.30/GB	$26/mo

What's in the dashboard

Overview - KPIs, request volume, latency percentiles, status/method distribution, heatmap
All Requests - paginated log with search, filters, expandable DB query details
Routes - per-route breakdown (calls, avg latency, P95, errors)
Errors - 4xx/5xx timeline, top error routes, filterable error log
Slow Requests - latency distribution histogram
Database - N+1 detector, slowest queries, source distribution
Traces - distributed trace waterfall
Live Tail - real-time SSE stream with filters
Geographic - country breakdown, bot detection, rate abuse
Usage - daily quota tracking
Alerts - email/Slack notifications

All free during beta. No credit card.

Try it

npm install auto-api-observe

Dashboard: apilens.rest
npm: npmjs.com/package/auto-api-observe
GitHub: github.com/rahhuul/auto-api-observe

Zero dependencies. TypeScript-first. MIT license. 44 tests.

Would love feedback - what features would you want next?

[Boost]

Rahul Patel — Sat, 07 Mar 2026 20:06:36 +0000

I Built a 1-Line Observability Package for Express & Fastify Zero Dependencies, Full TypeScript - DEV Community

Which routes are slow? How many DB queries is this endpoint firing? What's the error rate on /orders...

dev.to

I Built a 1-Line Observability Package for Express & Fastify Zero Dependencies, Full TypeScript

Rahul Patel — Thu, 05 Mar 2026 19:49:14 +0000

Which routes are slow?
How many DB queries is this endpoint firing?
What's the error rate on /orders vs /users?
Can I trace a request across multiple services?

And every time, the answer was either "set up OpenTelemetry" (a multi-day project) or "write custom middleware again" (a boring wheel re-invention).

So I stopped doing either and built auto-api-observe a zero-dependency, TypeScript-first observability package for Express and Fastify that takes one line to set up.

What You Get - Immediately

Install it:

npm install auto-api-observe

Drop it into Express:

const express = require('express');
const observability = require('auto-api-observe');

const app = express();
app.use(observability()); // ← that's it

app.listen(3000);

Or Fastify:

const Fastify = require('fastify');
const { fastifyObservability } = require('auto-api-observe');

const fastify = Fastify();
await fastify.register(fastifyObservability); // ← that's it

await fastify.listen({ port: 3000 });

From that moment, every single request produces a structured JSON log:

{
  "timestamp": "2026-03-05T12:00:00.000Z",
  "traceId": "a1b2c3d4-...",
  "method": "GET",
  "route": "/users",
  "path": "/users/42",
  "status": 200,
  "latency": 120,
  "latencyMs": "120ms",
  "dbCalls": 0,
  "slow": false,
  "ip": "127.0.0.1"
}

No config. No agents. No external services.

The Feature I'm Most Proud Of: DB Call Tracking via AsyncLocalStorage

Most logging middleware tells you how long a request took. But it doesn't tell you why it was slow.

Was it 400ms because of business logic? Or because your ORM silently fired 12 queries?

I built trackDbCall() to answer exactly that. Call it anywhere in your async chain:

const { trackDbCall } = require('auto-api-observe');

async function getUser(id) {
  trackDbCall(); // no need to pass request context
  return db.query('SELECT * FROM users WHERE id = ?', [id]);
}

It uses AsyncLocalStorage under the hood, so it automatically knows which request it belongs to, no matter how deeply nested in your call stack. The dbCalls count shows up right in the log entry:

{
  "route": "/users",
  "latencyMs": "340ms",
  "dbCalls": 7,
  "status": 200
}

340ms with 7 dbCalls, now you immediately know where to look. No guessing, no profiler needed.

You can also count multiple calls at once: trackDbCall(3).

Distributed Tracing - Across Services, Zero Config

Every request gets an auto-generated UUID traceId. But here's the part that makes it useful in microservices:

If an upstream service passes the x-trace-id header, the same ID is reused. And the same header is set on the response, so downstream services can propagate it too.

→ Service A  (generates traceId: abc-123, sets x-trace-id: abc-123)
→ Service B  (reads x-trace-id: abc-123, logs with same ID)
→ Service C  (same — full trace across all services)

You can also read the trace ID directly in your handlers:

app.get('/items', (req, res) => {
  console.log(req.traceId); // 'abc-123'
  res.json({});
});

This means you can grep your logs by traceId and reconstruct the full journey of any request across your entire system, with no OpenTelemetry collector required.

Built-in Metrics Endpoint

No Prometheus. No Grafana. Just call getMetrics():

const { getMetrics } = require('auto-api-observe');

app.get('/metrics', (req, res) => {
  res.json(getMetrics());
});

You get per-route breakdowns with avg/min/max latency, error counts, slow request counts, and status code distributions:

{
  "totalRequests": 142,
  "successRequests": 135,
  "clientErrorRequests": 3,
  "errorRequests": 4,
  "slowRequests": 2,
  "uptime": 3600,
  "routes": {
    "GET /users": {
      "count": 80,
      "avgLatency": 95,
      "minLatency": 12,
      "maxLatency": 1400,
      "errors": 0,
      "slowCount": 1,
      "statusCodes": { "200": 80 }
    }
  }
}

For internal dashboards, health checks, or a quick production sanity check, this is everything you need without spinning up an external metrics service.

Custom Fields - Attach Anything to Any Log Entry

Need to log the current user ID, a tenant, a feature flag? addField() merges any data into the current request's log entry:

const { addField } = require('auto-api-observe');

app.get('/orders', async (req, res) => {
  const orders = await getOrders(req.user.id);
  addField('userId', req.user.id);
  addField('orderCount', orders.length);
  res.json(orders);
});

Like trackDbCall(), it uses AsyncLocalStorage, so you can call it from anywhere, even deep inside a service layer, and it'll attach to the right request.

Plug Into Your Existing Log Stack

If you're already using Winston, Pino, or a cloud logging service, you don't have to give that up. Just pass a custom logger:

app.use(observability({
  logger: (entry) => {
    winston.info('api', entry);        // Winston
    pino.info(entry);                  // Pino
    datadogLogs.logger.info('', entry); // Datadog
  },
}));

Or silence console output entirely while keeping metrics collection:

app.use(observability({ logger: false, enableMetrics: true }));

Other options worth knowing:

app.use(observability({
  slowThreshold: 500,           // flag anything over 500ms as slow
  skipRoutes: ['/health', /^\/internal/], // skip health checks from logs
  onResponse: (entry) => {
    if (entry.slow) alertTeam(entry); // custom alerting hook
  },
}));

TypeScript - First Class

Full types ship out of the box:

import observability, {
  ObservabilityOptions,
  LogEntry,
  Metrics,
} from 'auto-api-observe';

const options: ObservabilityOptions = {
  slowThreshold: 500,
  onResponse: (entry: LogEntry) => {
    if (entry.slow) alertTeam(entry);
  },
};

app.use(observability(options));

The LogEntry type is fully typed including your custom fields via the index signature [key: string]: unknown.

Zero Runtime Dependencies

The entire package runs on pure Node.js. No lodash, no uuid package, no express peer dependency required unless you use it. The AsyncLocalStorage-based context tracking is built on Node's native async_hooks module.

Why Not OpenTelemetry?

OTel is the right choice for large-scale distributed systems with dedicated DevOps. It's powerful.

But most Node.js developers need structured logs and per-route metrics today, not after configuring a collector pipeline, an exporter, and a dashboard.

auto-api-observe is for that situation. Start in five minutes, get real observability in production, and migrate to a full OTel stack later when you actually need it. Both can even coexist, use onResponse to forward entries to an OTel-compatible exporter.

Install & Links

npm install auto-api-observe

📦 npm: npmjs.com/package/auto-api-observe
⭐ GitHub: github.com/rahhuul/auto-api-observe

What's Coming Next

[ ] Configurable slow threshold per-route
[ ] Winston / Pino transport presets
[ ] OpenTelemetry export compatibility layer
[ ] Request body/response body sampling (opt-in)

If there's something you'd want, open an issue, I read everything.

If this saves you even 20 minutes of setup time, a ⭐ on GitHub goes a long way for an open source project. And drop a comment if you run into anything, happy to help.

Mastering DSA with JavaScript: A Roadmap for Developers in 2025 - Part 1

Rahul Patel — Tue, 03 Jun 2025 19:52:51 +0000

📢 JavaScript Warriors & DSA Dreamers!
Just dropped of my DSA with JavaScript series and trust me, Don't miss it!

From Arrays to Linked Lists and now Queues — we’re building the foundations one step at a time 🧱

👉 Read it here:

🧠 For devs, interviewees & JS lovers who want to level up fast.

JavaScript #DSA #CodingInterview #FrontendDev #100DaysOfCode

📢 JavaScript Warriors & DSA Dreamers! Just dropped DSA with JavaScript series, and trust me, Don't miss it! 👉 Read it here: [Read here](https://medium.com/@rahhuul3110/mastering-dsa-with-javascript-a-roadmap-for-developers-in-2025-part-1-e8597d3083e8)

Rahul Patel — Tue, 03 Jun 2025 19:44:15 +0000