CONCEPT Cited by 2 sources
max_connections ceiling¶
Definition¶
max_connections is MySQL's server-side configuration
variable capping the number of concurrent client connections
the server will accept. Postgres has the same concept under the
same name. The ceiling is not arbitrary — it is derived from
the server's memory budget. Raising it without adding memory
trades buffer-pool /
working-set capacity for
connection slots.
Why it exists¶
A standalone relational database allocates per-connection memory buffers to enforce session isolation. In MySQL, each connection owns (at minimum):
- A thread stack (default 256 KiB).
- Session sort / join / read / read-random buffers, allocated on-demand per query (sort buffer default 256 KiB, can grow to many MiB on large sorts).
- A session-local network buffer.
- Session-level system-variable state (see concepts/session-level-system-setting).
Canonical Liz van Dijk framing (PlanetScale, 2022-11-01):
"A standalone database relies heavily on its ability to compartmentalize memory use to provide the strong isolation guarantees we expect, so it needs to allocate certain memory buffers on a per-connection basis. The more connections we create, the less memory we have available for the overall buffer pool, and so MySQL comes with a
max_connectionsvariable built in that acts as a 'last resort' safety measure." (Source: sources/2026-04-21-planetscale-one-million-connections.)
The ceiling is a hard cap on concurrent connection
acceptance — when the limit is hit, new clients get a
Too many connections error (MySQL error 1040) and the
server refuses them.
Operational framings¶
RDS MySQL's 16,000-connection instance cap¶
Amazon RDS MySQL publishes a hard instance-level cap of 16,000 concurrent connections regardless of instance size (Source: sources/2026-04-21-planetscale-comparing-awss-rds-and-planetscale). Customer applications that breach this ceiling need a middle-tier pooler (pgbouncer for Postgres, ProxySQL for MySQL, VTTablet for Vitess) to convert many client connections into a smaller capped number of upstream connections.
Default values¶
| Database | max_connections default |
|---|---|
| MySQL 8.0 | 151 |
| Postgres 17 | 100 |
| RDS MySQL | formula based on instance-class memory, capped at 16k |
| Aurora MySQL | formula based on instance-class memory |
The max_connections knob is an economic parameter¶
The knob isn't arbitrary — it's a derived quantity:
max_connections ≈ (available_memory − buffer_pool − other_fixed)
────────────────────────────────────────────
estimated per-connection memory
Operators set it by choosing how to split the memory budget between buffer-pool working set and connection slots. Raising it trades cache hit rate for client acceptance capacity.
Why you can't just raise it¶
Raising max_connections beyond the memory envelope
produces memory overcommit:
average utilisation is fine, but a burst where every
connection lands on a memory-heavy query simultaneously can
OOM the database. The max_connections cap is the hard
guarantee that prevents the slow-burn overcommit scenario.
Canonical: "While it may seem harmless to raise this variable at first (you may not be approaching the instance memory limits quite yet), making MySQL live outside its means (i.e. overcommitting memory) opens the door to dangerous crashes and potential downtime, so this is not recommended." (Source: sources/2026-04-21-planetscale-one-million-connections.)
The proxy-tier answer¶
Architectures that need to exceed max_connections put a
proxy tier between application and database that owns the
upstream connection budget centrally. The proxy accepts many
client connections; fans them out to a small pool of upstream
DB connections; enforces the DB-memory budget once rather than
requiring every application pool to respect it independently.
Canonical wiki instances:
- Vitess VTTablet — the centralised pool in front of MySQL. See sources/2026-04-21-planetscale-connection-pooling-in-vitess.
- PlanetScale Global Routing Infrastructure — the CDN-like edge tier that terminates MySQL at the nearest edge and multiplexes to origin. See systems/planetscale-global-network.
- pgbouncer / ProxySQL — the general-purpose-pooler tier for vanilla Postgres / MySQL deployments.
The benchmarked PlanetScale ceiling of 1M concurrent connections (Source: sources/2026-04-21-planetscale-one-million-connections) is achieved by having two such proxy tiers (VTTablet in-cluster + Global Routing Infrastructure at edge) stacked, each enforcing its own budget.
Seen in¶
- sources/2026-04-21-planetscale-one-million-connections
— canonical framing of
max_connectionsas a memory-derived ceiling that is the load-bearing constraint on standalone-DB horizontal scaling; the benchmarked 1M PlanetScale ceiling (62.5× above RDS's 16k) is the empirical anchor for the proxy-tier architectural answer. - sources/2026-04-21-planetscale-comparing-awss-rds-and-planetscale — first wiki citation of the 16k RDS ceiling as the specific number behind the general ceiling framing.
Related¶
- concepts/memory-overcommit-risk — the failure mode of
raising
max_connectionspast the memory budget. - concepts/connection-pool-exhaustion — the downstream
symptom when a pool sized to respect
max_connectionsreaches its own cap. - concepts/innodb-buffer-pool / concepts/working-set-memory
— the memory budget
max_connectionstrades against. - patterns/two-tier-connection-pooling — the architectural pattern that sidesteps the ceiling by putting a proxy in front.
- systems/planetscale-global-network / systems/vitess — canonical proxy-tier implementations on the PlanetScale stack.