On November 11, 2026, Cloudflare raised two limits on Hyperdrive, the service that keeps a connection pool (a set of reused connections) and a query cache between Workers and PostgreSQL or MySQL databases hosted outside Cloudflare. On the Workers Paid plan, each account can now have up to 100 configurations, up from 25, and each configuration can open up to 1,500 connections to the origin database, up from 100.
What changed on Workers Paid
A Hyperdrive configuration points to one database and sets, among other things, how many connections the pool may keep open to it. Those connections are shared across all Worker invocations, and each invocation holds one for the length of its transaction. With a ceiling of 100, an application with many concurrent transactions hit Hyperdrive's limit before it hit the database's.
Each configuration's value is still chosen by the team, up to that maximum, in the dashboard, with Wrangler (wrangler hyperdrive update <ID> --origin-connection-limit=<N>) or through the REST API. The announcement does not change anything on the Free plan.
Who should look at this
The change matters to anyone running applications on Workers with a relational database outside Cloudflare, such as managed Postgres or MySQL at another provider. Two profiles gain the most.
The first is the high-traffic application with long transactions, which queued requests waiting for a free connection or had to split load across several configurations pointing at the same database to get around the ceiling. With the new ceiling, that split may no longer be needed.
The second is the team that uses many separate databases: one per customer, per environment or per test branch. With 25 configurations per account, giving each preview its own database used up the quota quickly. With 100, isolating the test database becomes feasible in more cases, which bears on the decision discussed in A safe preview must isolate its connected resources.
What to do now
The announcement mentions no automatic adjustment of existing configurations and no deadline. Before raising the number, check how many connections the database accepts. Cloudflare's documentation recommends keeping Hyperdrive's limit below the database's max_connections for two reasons:
- the limit is soft: during network failures Hyperdrive may open connections beyond the configured value to keep the application available, and it needs headroom for that;
- when several configurations point at the same database, all of their connections count against the same ceiling.
Open connections also use memory on the database server. In PostgreSQL, the max_connections default is typically 100, and a managed provider may set a different value depending on the plan, so check the instance's actual number. In practice, the limit that now matters is the database's and that of the plan you pay its provider for. If the application already suffered from connection queuing, the safe path is to raise the value gradually and watch connection usage and latency on the database, as the documentation itself suggests.
What is still unclear
Hyperdrive's limits page still showed the old values (25 configurations and about 100 connections on Paid) when this was written, so the changelog is the reference for now. Neither the announcement nor the pool tuning guide states the default connection value for new configurations; the guide says to check it on the settings page or in the API response.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
