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