A saturated MySQL pool queues callers inside your own application

With five connections busy, the sixth request that needs the database waits for one to be returned to the pool ^[6]. That wait happens on the borrow, inside your process, because the pool is an application-side collection of reusable connections that requests check out and hand back ^[9]. So the failure signature of an undersized pool shows up as your own handler latency; the database itself never reports an error. An app that has just started and reports zero open connections is behaving exactly as documented ^[5].

The walkthrough's own figures give a ratio worth naming. Fifty users online, perhaps five requests actually needing MySQL at a given instant, which is ten users per connection ^[13]. That is a claim about their workload. For it to transfer, your query durations have to be in the same range, roughly the same share of your requests must never touch the database at all, and your users have to spend as much time reading and typing as theirs do ^[3]. Change any one of those and the ratio moves. The number that survives the move is the count of queries in flight at peak, which is the thing MaxOpenConns is actually rationing.

The snippet sets two timers, two minutes of idle time and a thirty-minute lifetime, a fifteenfold spread ^[1][14]. The piece lists the difference between MaxIdleConns and ConnMaxIdleTime among the questions it set out to answer, and the text supplied here breaks off before it gets there ^[10]. That leaves the interesting gap undefended: MaxOpenConns is five while MaxIdleConns is one ^[1]. Connection setup is not free, since it can involve network communication, authentication, server-side resource allocation, session initialisation and extra CPU and memory ^[7]. A pool permitted to grow to five while retaining fewer idle sockets pays some of that setup again on the next burst. Whether it does, and how much, depends on what your driver does with MaxIdleConns, which is the line to read before you copy the four lines.

The multi-tenant trap comes down to arithmetic. The cap is stated per application: five open connections at the same time for that process ^[12]. Run the service in several instances and the server sees the cap once per instance, so the figure to compare against the database's own connection limit is MaxOpenConns multiplied by replica count ^[16]. Scaling out horizontally therefore raises database-side connection pressure without anyone editing the pool config. The distinction between users and queries is exactly what the article says matters for SaaS and multi-tenant systems ^[11], and the corollary is that tenant counts belong nowhere in this calculation.