Prisma Query Logging and PostgreSQL: Where the ORM Ends and the Database Begins

I turned on query logging in Prisma, watched queries rolling into the console, and assumed I had full visibility into what was happening in the database. Spoiler: I didn't.

Prisma logs show the query the client sends and how long it took from the ORM's perspective — including serialization, network, and driver overhead. What they don't show is what PostgreSQL actually does with that query on the inside: whether it used an index, whether it did a sequential scan, whether there was a lock wait, whether the planner picked a bad plan. That stuff lives in Postgres, not in the ORM.

My thesis: Prisma query logs are a pattern-debugging tool, not a database diagnostics tool. Confusing the two leads you to look for the problem in the wrong place and make optimization decisions without real evidence.

What the Official Prisma Docs Say — and What They Don't

The .

You need to look at PostgreSQL directly when:

• 
  Client duration is high but the query pattern looks correct: dig into pg_stat_statements to see real execution time in Postgres.


• 
  You suspect a sequential scan: EXPLAIN ANALYZE on the same query tells you if there's an index that isn't being used.


• 
  There are locks or deadlocks: pg_locks and pg_stat_activity are the tools. Prisma can't see any of this.


• 
  The problem shows up under load but not locally: that's likely pool contention or autovacuum triggering at real volume. Neither of those shows up in ORM logs.


• 
  You want to understand the query planner's plan: the plan can change with real data and real table statistics. Only EXPLAIN ANALYZE shows you that.
  

-- Run this directly in PostgreSQL to see the real execution plan

EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)

SELECT u.id, u.email

FROM "User" u

WHERE u.status = 'active'

ORDER BY u."createdAt" DESC

LIMIT 50;



-- BUFFERS shows how many blocks were read from disk vs cache

-- ANALYZE actually executes the query (be careful on tables with heavy writes)

Diagnostic Checklist: Where to Start

Before optimizing anything, answer these questions in order:

1. Does the Prisma log show many queries for a single operation?

   → Yes: check for N+1, eager loading, misconfigured relation loading

   → No: keep going



2. Does the generated SQL make sense? Are we pulling columns we don't use?

   → Problem: add explicit select in Prisma

   → OK: keep going



3. Is the duration in Prisma consistently high or sporadic?

   → Sporadic: investigate pool contention, exhausted connections

   → Consistent: keep going



4. Do you have pg_stat_statements enabled in PostgreSQL?

   → No: enabling it is the next step before you continue diagnosing

   → Yes: find the query by query text and check real mean_exec_time



5. Does the execution plan use an index or a sequential scan?

   → EXPLAIN ANALYZE on the real query with real data

   → If there's a seq scan on a large table with filters, that's your problem

Hard Limits: What You Cannot Conclude from Prisma Logs Alone

This matters and not enough people say it clearly:

• 
  You can't conclude "the query is slow" based only on e.duration without knowing how much of that time is Postgres vs driver overhead vs network.


• 
  You can't detect lock waits or deadlocks from the ORM client. A query waiting on a lock will show up with a high duration, but the reason is invisible from Prisma.


• 
  You can't see if autovacuum is competing with your writes. That background noise shows up as intermittent slowness that doesn't correlate with any pattern in the client log.


• 
  You can't validate that an index is being used without EXPLAIN. Prisma generating a correct WHERE clause doesn't guarantee Postgres will pick the index you expect.


• 
  You can't reproduce behavior under real load with local logs alone. The pool has a max size (configurable with connection_limit in the datasource), and contention only appears with real concurrency.

If the diagnosis requires any of those points, Prisma logs are a starting point, not the answer.

FAQ: Prisma Query Logging and PostgreSQL

How do I enable query logging in Prisma without dumping everything to stdout?

Use emit: 'event' instead of emit: 'stdout' and handle it via prisma.$on('query', handler). That way you can filter, structure, or ship it to your logging system without polluting standard output in production.

Is the duration in Prisma logs the same as execution time in PostgreSQL?

No. Prisma client duration includes serialization, network latency, and driver overhead. Real execution time in Postgres comes from pg_stat_statements or EXPLAIN ANALYZE. They can differ significantly depending on result size and network latency.

How do I enable pg_stat_statements in PostgreSQL?

Add pg_stat_statements to shared_preload_libraries in postgresql.conf, restart the server, and run CREATE EXTENSION IF NOT EXISTS pg_stat_statements; on your database. From there you can query pg_stat_statements to see real execution times per query.

Does it make sense to log queries in production?

Depends on the volume. In production with high traffic, logging every query can generate significant I/O overhead. A more sensible approach is logging only queries that exceed a duration threshold, or using OpenTelemetry with sampling. I covered observability with traces in the context of Spring Boot but the principles are the same — more detail in the

This article was originally published on juanchi.dev