Your API Is Slow. Your Database Probably Isn't the Problem.

Step 1: Measure Before You Guess — Isolate Where the Time Is

Before touching anything, instrument the request to find where the time actually goes. The goal is to separate total request time into: time spent waiting for a database connection, time spent executing database queries, time spent in application code between queries, and time spent serialising and sending the response. Most APM tools (Datadog APM, New Relic, Sentry Performance, OpenTelemetry) show distributed traces with database spans.

If you do not have APM, add timing instrumentation manually at the database call boundaries — log the time before and after each query execution, not just the total request duration. The pattern you are looking for: if individual query execution times are under 10ms but total request time is 800ms, the problem is not query performance. It is either the number of queries (N+1), the time waiting for a connection, or application processing between queries.

If one query execution time is 800ms, the problem is in that query — use EXPLAIN ANALYZE and the slow query log.

-- pg_stat_statements: find which queries your slow endpoint is running
-- Run this before and after a slow request to see what fired
SELECT
  calls,
  round(mean_exec_time::numeric, 2) AS avg_ms,
  round(total_exec_time::numeric, 2) AS total_ms,
  substring(query, 1, 100) AS query_short
FROM pg_stat_statements
WHERE query NOT LIKE '%pg_stat%'
ORDER BY calls DESC
LIMIT 20;

-- If you see the same query hundreds of times in one minute: N+1 pattern
-- If one query shows avg_ms > 100: fix the query itself
-- If all queries are fast but count is high: N+1 or unnecessary fetching

Cause 1: N+1 Queries — The Silent Request Killer

The N+1 query pattern occurs when code fetches a list of N records and then issues one additional query per record to load related data. 5ms. 5ms per query = 100ms in database time + 100ms in network round-trip time + 100ms in connection overhead = 300ms from database operations alone.

Add application serialisation and the response reaches 600ms. customer triggers a SELECT query. In Django, this is an un-prefetched ForeignKey.

In Rails, an association without eager loading. In Prisma, a related model access without include. In all cases, the fix is the same: batch the relationship load using a single JOIN or a WHERE IN query.

).

-- Django: bad (N+1)
orders = Order.objects.filter(status='pending')
for order in orders:
    print(order.customer.name)  # triggers 1 query per order

-- Django: good (prefetch_related eliminates N+1)
orders = Order.objects.filter(status='pending').select_related('customer')

-- Prisma: bad (N+1)
const orders = await prisma.order.findMany({ where: { status: 'pending' } });
for (const order of orders) {
  const customer = await prisma.customer.findUnique({ where: { id: order.customerId } });
}

-- Prisma: good (include eliminates N+1)
const orders = await prisma.order.findMany({
  where: { status: 'pending' },
  include: { customer: true }
});

-- SQL: always prefer a single JOIN over N individual lookups
SELECT o.id, o.total, c.name
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'pending';

Related: our deep dive on the N+1 query problem, how to debug slow SQL queries

Cause 2: Connection Pool Exhaustion — Why Queries Appear Slow Without Being Slow

Connection pool exhaustion looks exactly like slow query execution in most monitoring tools. The application waits 300ms before a query runs. The query itself takes 5ms.

The total is 305ms — and 300ms of that is the application waiting for a free connection from the pool, not database execution. This pattern appears in APM traces as a long database span with a very short execution segment inside it. In pg_stat_activity, the connection enters the 'idle' state and then 'active' state after a delay — the delay being the wait for a pool slot.

Connection pool exhaustion happens when all pool connections are busy and new requests queue behind them. Common causes: a slow query holding a connection for hundreds of milliseconds, a transaction that is not committed promptly, or a Kubernetes deployment scale-up that outpaces the pool capacity. The fix is either increasing the pool size (if the database can handle more concurrent backends), adding PgBouncer to multiplex connections, or finding and fixing the slow query or uncommitted transaction that is holding connections too long.

-- Detect pool exhaustion: look for requests queuing in your pool
-- Node.js pg pool example: add event listeners
const pool = new Pool({ max: 20 });
pool.on('acquire', () => { /* connection acquired from pool */ });
pool.on('connect', () => { /* new connection created — pool was empty */ });

// Log pool stats to detect exhaustion
setInterval(() => {
  console.log({
    total: pool.totalCount,
    idle: pool.idleCount,
    waiting: pool.waitingCount  // non-zero = pool exhaustion occurring
  });
}, 5000);

-- PostgreSQL: find long-running transactions holding connections
SELECT
  pid,
  now() - xact_start AS transaction_age,
  state,
  application_name,
  substring(query, 1, 80) AS current_query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
  AND now() - xact_start > INTERVAL '30 seconds'
ORDER BY transaction_age DESC;

Related: fixing PostgreSQL connection exhaustion with PgBouncer

Cause 3: Fetching More Data Than the Endpoint Needs

SELECT * is the most common form of over-fetching, but it is not the only one. A user list endpoint that fetches every column including profile_picture_blob and settings_json — both large fields — transfers megabytes of data for a response that only displays name and email. The database executes the query fast.

The transfer time from database to application is slow. The serialisation of a 2 MB result set is slow. The JSON encoding of 200 full user objects is slow.

The fix is always to select only the columns the endpoint actually returns to the client, and to paginate result sets. select(), Prisma's select, Hibernate's projections. The secondary problem is fetching entire relationship trees when only one field from the related record is needed.

name requires loading the entire Customer record — address, phone, created_at, metadata — to display one field. Projections that fetch only the needed fields from joined tables are the solution. For large blobs and JSON columns, consider lazy loading or separate endpoints — load the lightweight list first, then fetch the heavy fields on demand.

-- Bad: SELECT * fetches all columns including large BLOBs
SELECT * FROM users WHERE status = 'active' LIMIT 100;

-- Good: select only what the API response needs
SELECT id, name, email, created_at
FROM users
WHERE status = 'active'
LIMIT 100;

-- Django: limit to specific fields
users = User.objects.filter(status='active').values('id', 'name', 'email')[:100]

-- Prisma: select specific fields
const users = await prisma.user.findMany({
  where: { status: 'active' },
  select: { id: true, name: true, email: true },
  take: 100
});

-- Always add LIMIT for list endpoints — unbounded queries are a ticking clock
-- A query returning 50 rows today may return 50,000 rows in 18 months

Cause 4: Serial Database Calls That Could Be Parallel

API endpoints frequently make multiple independent database queries in sequence when they could be issued in parallel. A user profile endpoint that fetches the user record, then their recent orders, then their notification preferences — three independent queries — runs them serially: 5ms + 5ms + 5ms = 15ms minimum, plus three round-trips. gather(), completing in approximately 5ms + one round-trip.

The pattern is more subtle with ORMs: accessing multiple relationship properties on a model often triggers serial queries even when the framework could batch them. The fix requires identifying which queries are independent (no data dependency between them) and issuing them concurrently. In GraphQL, the DataLoader pattern solves both N+1 and serial loading by batching multiple field-level data requests into a single query.

all() or async gather calls on independent data fetches is the straightforward solution.

// Node.js: bad — three serial queries, 15ms+
const user = await prisma.user.findUnique({ where: { id } });
const orders = await prisma.order.findMany({ where: { userId: id } });
const prefs = await prisma.preference.findUnique({ where: { userId: id } });

// Node.js: good — three parallel queries, ~5ms
const [user, orders, prefs] = await Promise.all([
  prisma.user.findUnique({ where: { id } }),
  prisma.order.findMany({ where: { userId: id }, take: 10 }),
  prisma.preference.findUnique({ where: { userId: id } })
]);

# Python: bad — serial
user = await db.fetch_one("SELECT * FROM users WHERE id = $1", user_id)
orders = await db.fetch_all("SELECT * FROM orders WHERE user_id = $1", user_id)

# Python: good — parallel
user, orders = await asyncio.gather(
    db.fetch_one("SELECT id, name FROM users WHERE id = $1", user_id),
    db.fetch_all("SELECT id, total FROM orders WHERE user_id = $1 LIMIT 10", user_id)
)

ORM-Specific Patterns That Kill Performance

Each major ORM has idiomatic patterns that appear clean in code but generate catastrophically inefficient SQL. count() in a loop instead of aggregating. where with a block (which fetches all records then filters in Ruby) is common.

In Prisma, the issue is accessing nested relations without include — each nested relation access triggers a separate query. In SQLAlchemy, lazy-loaded relationships and the use of ORM objects instead of query result tuples adds serialisation overhead. The single most impactful change in any ORM codebase is configuring strict N+1 detection in development.

Django has nplusone. Rails has bullet. These libraries detect and log N+1 patterns during test runs and development — making them visible before they reach production.

# Django: enable nplusone to catch N+1 in tests
# pip install nplusone
MIDDLEWARE = ['nplusone.ext.django.NPlusOneMiddleware']
NPLUSONE_RAISE = True  # raise exception in tests, not just log

# Rails: configure bullet in development
# gem 'bullet', group: :development
# config/environments/development.rb
Bullet.enable = true
Bullet.alert = true
Bullet.rails_logger = true
Bullet.add_footer = true  # shows N+1 alerts in page footer

# Node.js/Prisma: log all queries to find N+1 manually
const prisma = new PrismaClient({
  log: ['query'],  // log every query with timing
})

Related: our API performance service

Real Example: p99 from 4.2 Seconds to 180ms

2 seconds. The endpoint loaded a list of transactions with associated merchant details, category labels, and user notes. Adding a read replica had no effect.

2xlarge had no effect. Profiling the request with OpenTelemetry traces revealed: 187 database spans in a single request, each completing in 1–4ms, totalling approximately 400ms of database execution time. The remaining 3,800ms was round-trip latency and connection wait time.

The endpoint was fetching a list of 150 transactions (1 query) and then loading merchant details per transaction (150 queries), category labels per transaction (150 queries), and user notes per transaction (150 queries) — classic N+1 pattern, three times over. The fix was three select_related / include calls to load all relationship data in the initial transaction fetch, collapsing 451 queries into 4. We also switched from SELECT * to selecting only the 8 fields the mobile app actually displayed.

2 seconds to 180ms. The database instance remained unchanged. Total engineering time from profiling to production deploy: one day.