What I love about this is the detection method—it's highly reusable because it works before you even know the cause. If per-query cost doesn't scale with payload/result size, it's a round-trip problem. Period.
You can diagnose this with just two numbers:
1. TCP RTT from app to DB (ss -ti, 47 ms here)
2. Server-side time per statement from pg_stat_statements (9.6s total for 4M DEALLOCATE ALL calls—essentially nothing)
A client time of 240 ms vs near-zero server time with a 47 ms RTT implies 4–5 crossings. The call counts in pg_stat_statements (BEGIN, DEALLOCATE ALL, COMMIT all at ~4M) immediately expose what those extra crossings are.
It's worth noting the configuration context. Prisma frames pgbouncer=true as a transaction-mode requirement due to named prepared statement limitations in poolers. Supabase recommends the session-mode string for server-based setups and the port-6543 transaction-mode string for serverless. So the config made sense for a different infrastructure shape.
Also, a good footnote for the writeup: Prisma now explicitly recommends not setting pgbouncer=true if you're on PgBouncer 1.21.0+. Handy alternative escape route if you aren't using Supavisor.
I tried to read this article but something about the writing style made me go cross eyed. That being said, it sounded like something I had heard before and lo and behold...
I'm not sure the real intention of this blogpost, but my takeaway is "someone who has no idea what is going on finds a problem <LLM OF CHOICE> left for them, like a little code land mine".
First of all, you still have the images problem (among others). Loading your home site takes around 60MB of downloads, including the autoloading 40MB MP4 file. Reduce resolution and compress. You don't need a phone to reproduce that, you just need to open your web browser development tools and reload the site to see how heavy is it. Also, the memory use calculation is off, but that's not important because probably an LLM did it.
Second, your API in karibukit.com is down
Don't rely that much in the LLM. Check things with your own eyes.
13 comments
[ 3.0 ms ] story [ 32.5 ms ] threadThe horror.
I'd rather read a "badly written" and to the point story, than a clone of the last 20 postmortem-ish/incredible discovery stories I've seen this week.
It sounds like there could be something extremely interesting in this article, but the writing style is really off-putting.
> "on staging first and then on production at 23:40"
Why does the reader need to know the exact minute-to-minute timeline?
Literally raised 4 years ago: https://github.com/prisma/orm/discussions/15164
I'm not sure the real intention of this blogpost, but my takeaway is "someone who has no idea what is going on finds a problem <LLM OF CHOICE> left for them, like a little code land mine".
And that's not slop, it's the real smoking load bearing foot gun.
First of all, you still have the images problem (among others). Loading your home site takes around 60MB of downloads, including the autoloading 40MB MP4 file. Reduce resolution and compress. You don't need a phone to reproduce that, you just need to open your web browser development tools and reload the site to see how heavy is it. Also, the memory use calculation is off, but that's not important because probably an LLM did it.
Second, your API in karibukit.com is down
Don't rely that much in the LLM. Check things with your own eyes.