Member-only story
How Database Connection Pooling Actually Works
Two weeks ago I told you about the index that turned a 4-second query into 12 milliseconds. Last week, about the bug that hid behind fifty perfectly fast queries: the N+1 problem. This week’s bug didn’t look like either of those. Friend’s link
The database dashboard was calm. CPU usage was low. Every individual query, when I checked, ran in a few milliseconds. And the app was still hanging — requests sitting there for seconds before anything happened, some timing out completely.
I kept looking at the database, because that’s where the last two bugs had lived. This one wasn’t there at all. It was sitting one layer up, in the thing that connects your app to the database in the first place.
The wrong mental model
Most of us assume that if the database itself isn’t struggling — low CPU, fast queries, nothing ugly in the slow query log — then the app talking to it should be fine too. That assumption is exactly what sends you looking in the wrong place.
Your app doesn’t open a fresh connection to the database every time it needs one. Opening a raw connection is expensive — a TCP handshake, authentication, session setup — often tens of milliseconds of pure overhead before a single query even runs. So instead, your app keeps a small, fixed set of…
