DEV Community: Md Imran Hossain

Your API Is Slow. But Is the Database Really the Problem?

Md Imran Hossain — Mon, 19 Oct 2026 09:08:42 +0000

A practical guide to identifying API performance bottlenecks through measurement, investigation, and evidence based debugging.

When an API becomes slow, the database is often the first thing developers suspect.

They start optimizing SQL queries, adding indexes, or changing database configurations. Sometimes these changes help. But in other cases, the real bottleneck lies somewhere else in the request lifecycle.

An API response can be delayed by application logic, an exhausted database connection pool, a slow external service, network latency, or an unexpectedly large response payload.

The key principle is simple: do not optimize the component you suspect. Identify the component that is actually causing the delay.

In this article, we will examine how API latency develops, how to investigate its underlying causes, and how to approach performance debugging with a systematic engineering mindset.

1. Understand What Happens During an API Request

Consider a typical request in a Node.js and Express application.

A client sends a request. The server receives it, executes application logic, queries the database, possibly communicates with an external service, and prepares a response.

The request may pass through several stages before the client receives the final result.

For example, an API endpoint that returns product information might perform authentication, query PostgreSQL, retrieve inventory information from another service, transform the results, and serialize the response.

Each stage consumes time.

If the total response time is three seconds, that does not automatically mean the database query took three seconds. The delay could be distributed across several operations.

This is why understanding the complete request lifecycle is more useful than immediately changing database queries.

2. Measure Before You Optimize

Before investigating a suspected bottleneck, establish how long the request actually takes.

For an initial investigation in Node.js, the built in performance API can help measure elapsed time.

import { performance } from "node:perf_hooks";

const start = performance.now();

const result = await fetchProducts();

const duration = performance.now() - start;

console.log({
  operation: "fetchProducts",
  durationMs: Number(duration.toFixed(2)),
});

This example measures the elapsed time of one operation. It does not explain why the operation took that long, but it gives you a useful starting point.

In a real application, measure important stages separately. Record the time spent executing the database query, waiting for external services, and performing significant application logic.

Use structured logs or metrics to make these measurements easier to compare. Avoid logging sensitive data, and make sure the timing instrumentation itself does not add unnecessary overhead.

You should also examine latency across many requests, not just one.

The median, or p50 latency, describes the experience around the middle of your request distribution. The p95 and p99 percentiles help reveal slower requests that affect a smaller but important portion of users.

An API with a reasonable average response time can still have serious performance problems if a significant number of requests are unusually slow.

3. Investigate the Database

The database deserves attention when measurements show that database operations contribute significantly to request latency.

Several common problems can cause this.

Inefficient queries

A query may scan far more rows than necessary, perform expensive joins, or retrieve data that the application never uses.

For PostgreSQL, EXPLAIN helps you inspect the query execution plan. EXPLAIN ANALYZE actually executes the query and reports its observed execution time and plan details.

EXPLAIN (ANALYZE, BUFFERS)
SELECT id, name, price
FROM products
WHERE category_id = 12;

Inspect the execution plan to understand how PostgreSQL accesses the data, how many rows it processes, and whether the observed execution work matches your expectations.

Be careful with EXPLAIN ANALYZE in production. It executes the query, so a query that modifies data can have real effects. Start with safe, representative queries and use an appropriate environment.

Missing or ineffective indexes

Indexes can improve queries that frequently filter, join, or sort data. However, adding an index to every column is not a good strategy.

Indexes consume storage and add work to data modification operations. The correct index depends on the query pattern, data distribution, and execution plan.

Use evidence from the actual workload to decide whether an index is appropriate.

Retrieving too much data

Returning every column or loading thousands of records when a client needs only a small subset increases database work, memory usage, and response size.

Select the required fields, apply suitable filters, and use pagination where appropriate.

The N plus one query problem

Another common issue occurs when an application retrieves a list of records and then executes an additional query for each record.

For example, retrieving 100 products and then making a separate database query for each product's category can produce 101 queries instead of a smaller number of carefully designed queries.

Depending on the data model, a join, batch query, or ORM feature may reduce this overhead.

The important point is that query count and query execution time both matter. A database investigation should examine the complete query pattern, not just the slowest individual statement.

4. Check Database Connection Pooling

A query can be fast while a request still spends a long time waiting for a database connection.

Applications commonly use connection pools to reuse database connections rather than opening a new connection for every query.

If all available connections are occupied, additional operations may wait until a connection becomes available.

This can happen when the pool is undersized for the workload, queries hold connections for too long, transactions remain open unnecessarily, or application concurrency increases beyond what the database can handle efficiently.

To investigate, examine connection pool utilization, pending acquisition requests, connection wait duration, and query execution time.

Also check the database server's connection limits and overall resource usage.

Increasing the pool size is not automatically the solution. Too many concurrent database connections can increase contention and reduce performance.

A useful distinction is whether the application is waiting to acquire a connection or waiting for the database to execute a query. Those are different problems and require different solutions.

5. Investigate External Services

Imagine that your API retrieves a user's profile from PostgreSQL and then requests subscription information from an external billing service.

The database query completes in 30 milliseconds, but the billing service takes 2.5 seconds to respond.

In this situation, optimizing the database is unlikely to make a meaningful difference to the overall response time.

External dependencies introduce their own latency, availability problems, and failure modes.

Measure the duration of outbound requests separately. Configure sensible timeouts, handle failures explicitly, and consider retries only when they are safe and appropriately limited.

When multiple independent operations can run concurrently, Promise.all may reduce the total waiting time.

const [profile, subscription] = await Promise.all([
  getUserProfile(userId),
  getSubscription(userId),
]);

This can improve performance when both operations are independent. It will not help if one operation depends on the result of the other, and it does not reduce the execution time of either operation individually.

Caching may also reduce repeated calls to expensive services when the data and freshness requirements make caching appropriate.

6. Examine Application Logic and Network Overhead

Not every bottleneck belongs to the database or an external service.

CPU intensive calculations, inefficient loops, excessive data transformation, and synchronous operations can delay requests inside the Node.js process.

Because JavaScript execution in a typical Node.js event loop runs on the main thread, CPU intensive work can prevent other callbacks from being processed promptly.

Use profiling and event loop monitoring to investigate these situations. For genuinely CPU intensive workloads, consider approaches such as worker threads or moving the work to a separate service when justified by measurement.

Network overhead also matters. Large JSON responses, unnecessary fields, slow connections, and additional network round trips can increase end to end latency.

If the server finishes its work quickly but the client still experiences a delay, investigate the response size, network conditions, and the time spent transferring data.

7. Use Observability to Connect the Evidence

Individual measurements are useful, but production systems benefit from a broader view.

Three observability practices are especially valuable.

Structured logging helps you understand what happened during a request. Include useful context such as the route, operation name, duration, status code, and request identifier without exposing sensitive information.

Metrics reveal patterns over time. Track request rates, error rates, latency percentiles, database pool utilization, and resource usage.

Distributed tracing helps connect operations across application services and external dependencies. A trace can reveal whether a request spent most of its time in application code, waiting for a database connection, executing a query, or calling another service.

Together, these tools help turn a vague report that an API is slow into a specific, testable explanation.

8. A Practical Workflow for Debugging Slow APIs

When investigating a slow endpoint, follow a consistent process.

Step 1: Reproduce the problem. Identify the affected endpoint, the conditions under which it becomes slow, and whether the issue occurs consistently or only under load.

Step 2: Measure end to end latency. Establish a baseline and compare typical requests with slow ones. Use p50, p95, and p99 latency where suitable.

Step 3: Break down the request. Measure application processing, database connection acquisition, query execution, external calls, and response generation.

Step 4: Identify the dominant bottleneck. Use logs, metrics, traces, database execution plans, and profiling data to determine where the time is being spent.

Step 5: Make one targeted change. Choose an optimization that addresses the evidence you found. Avoid changing several components at once, because that makes the results harder to interpret.

Step 6: Measure again. Compare the results against your baseline under comparable conditions. Verify that latency improved without introducing errors, resource pressure, or unexpected side effects.

Step 7: Monitor after deployment. Confirm that the improvement holds under real traffic and that other endpoints or dependencies have not been negatively affected.

This process makes performance optimization more predictable and reduces the risk of spending time on changes that do not solve the actual problem.

9. The Engineering Mindset Behind Performance Debugging

There is an important difference between guessing at a performance problem and investigating it systematically.

A guess driven approach might add an index because the database seems slow. An evidence driven approach measures the request, examines the execution plan, checks connection acquisition time, and traces external dependencies before choosing an optimization.

Neither indexes nor caching nor a larger connection pool is inherently the wrong solution. The problem is applying a solution before establishing the cause.

Good performance engineering is not about collecting optimization techniques and applying them everywhere. It is about understanding system behavior, testing assumptions, and making changes that produce measurable improvements.

Final Thoughts

When an API becomes slow, the database is a reasonable place to investigate, but it should not be the only place.

The delay may originate in query execution, connection pooling, application logic, an external service, or network overhead. Without measurements, it is difficult to distinguish between these possibilities.

Start by understanding the request lifecycle. Measure the important stages, identify the dominant bottleneck, apply a targeted fix, and verify the result.

That is how you move from guessing to evidence based debugging.

Before optimizing a slow API, ask yourself one question: Do I know where the time is being spent, or am I just assuming?

I would be interested to hear how other developers approach this problem. When an API becomes slow in your projects, what is the first thing you measure?

NPM vs Yarn vs pnpm vs Bun Which Package Manager Is Best for Modern Web Development?

Md Imran Hossain — Tue, 11 Aug 2026 03:30:00 +0000

As developers, we use package managers almost every day. Whether we are working with Node.js, React, Next.js, TypeScript, Express, Prisma, or other technologies in the JavaScript ecosystem, choosing the right package manager can have a meaningful impact on our development workflow.

Recently, I spent some time comparing the most popular package managers: npm, Yarn, pnpm, and Bun.

After looking at them from the perspective of performance, dependency management, disk efficiency, ecosystem compatibility, and developer productivity, my current preference is pnpm.

Why pnpm?

For me, pnpm provides one of the best overall balances between speed, disk efficiency, reliability, dependency management, and developer experience.

One of the key differences is how pnpm handles dependencies. It uses a content-addressable store and links packages into projects instead of unnecessarily keeping separate copies of the same packages for every project. This can reduce disk usage and make package installation more efficient, especially when working on multiple JavaScript or TypeScript projects.

Another advantage is pnpm's stricter dependency management. It encourages projects to explicitly declare the packages they actually depend on, which can help prevent accidental reliance on transitive dependencies.

This becomes particularly useful when working on larger applications, monorepos, or team-based projects.

What about Bun?

Bun is extremely interesting because it is much more than a package manager. It provides a JavaScript/TypeScript runtime, package manager, test runner, and bundler.

Its performance is impressive, especially when it comes to package installation and certain development workflows.

However, I don't think raw speed should be the only factor when choosing a technology for production.

Compatibility, ecosystem maturity, team familiarity, tooling support, and long-term maintainability are equally important.

That is why I see Bun as an excellent and promising tool, but I would not automatically choose it for every production Node.js project.

What about npm?

npm remains one of the safest and most widely supported choices in the JavaScript ecosystem.

It has an enormous ecosystem, excellent compatibility, extensive documentation, and a very simple workflow.

For beginners, learning projects, small applications, and situations where maximum compatibility is important, npm is still a great choice.

And Yarn?

Yarn is also a mature and powerful package manager. Its workspace and monorepo capabilities make it useful for many teams, particularly those that already have an established Yarn-based workflow.

So, which one would I personally choose?

My current preference would be:

pnpm -> Best overall balance for modern web development
Bun -> Excellent performance and all-in-one tooling
npm -> Excellent compatibility and simplicity
Yarn -> Mature and powerful alternative

But there is something more important than simply asking which one is the fastest. The fastest tool is not always the best tool.

A package manager primarily affects our development experience, dependency management, installation process, disk usage, and CI/CD workflow. It does not automatically make our production application or API faster.

For me, the better question is:

“Which tool provides the best balance of performance, reliability, maintainability, ecosystem support, and developer productivity?”

For my current Next.js, TypeScript, Node.js, Express, Prisma, and PostgreSQL workflow, pnpm currently gives me the balance I am looking for.

Technology choices are rarely about finding one universally “best” tool. They are about understanding the trade-offs and choosing the tool that fits the problem.

What Do You Use?

I'm curious about your experience. Which package manager are you currently using? npm, Yarn, pnpm, or Bun? And more importantly, what made you choose it?

Share your experience in the comments. I'd love to hear what works best for different projects and teams.