Hyperdrive’s higher paid limits: 100 configs and 1,500 origin connections

Which two limits changed?

Cloudflare’s official November 11, 2026 changelog says customers on a Workers Paid plan can now create up to 100 Hyperdrive configurations, up from 25, and set up to 1,500 origin database connections per configuration, up from 100. Configuration count is an account limit; origin connection count is a limit for each configuration.

At our November 12 check, the current limits page still listed 25 configurations for a paid account and approximately 100 origin connections per configuration, with a displayed update date of June 9. This guide reports the new figures as the November 11 announcement while retaining that documentation discrepancy. The announcement is not acceptance evidence that every account already displays the new values.

The announcement gives no account-by-account rollout schedule, regional list, or pricing change, and does not announce higher Free-plan limits. Keep the paid-plan qualification attached to the claim.

1,500 origin connections does not mean 1,500 requests

Hyperdrive maintains a connection pool between Workers and the origin database. An origin connection runs from Hyperdrive to the database; it is not a browser connection or a website request. Different Worker invocations can reuse pooled connections, which are generally checked out and returned at transaction boundaries.

The tuning documentation separates client connections from Workers to Hyperdrive from origin connections to the database. It says Hyperdrive does not limit the number of concurrent connections in the former group. That does not remove limits imposed by your application, database, plan, or other services.

The announced 1,500 figure is the higher configurable paid ceiling, not a recommendation or a universal default. The current tuning documentation specifies a minimum origin connection setting of 5 and says the maximum depends on the Workers plan. Check the actual value on each existing configuration.

Leave headroom across the whole database

Cloudflare recommends keeping the Hyperdrive origin connection limit below the database’s own connection limit. Include other Hyperdrive configurations, background jobs, administration tools, and applications that connect directly to the database. Looking at one configuration alone is insufficient.

For a hypothetical arithmetic example only, suppose the database allows 200 connections, 40 are reserved for other clients, and two Hyperdrive configurations are each budgeted for 60. The planned total is 160, leaving 40 on paper. This is not a recommended production configuration or a guarantee that actual usage stays at or below 160.

Hyperdrive’s origin connection limit is a soft limit. Cloudflare explains that its distributed pools may establish extra connections to preserve availability during conditions such as network failures. Leave headroom based on the database provider’s limits, connection monitoring, and query workload; a 1,500 ceiling is not evidence that the database can safely use all of it.

Check one configuration before changing it

The documented dashboard path is Storage & databases → Hyperdrive. Select the configuration, open Settings, then change Maximum connections under Origin connection limit and save. First confirm the account plan, target configuration, and database budget. If the interface still shows the older limit, retain the specific configuration and message and ask Cloudflare to confirm its available ceiling.

The documentation also provides this Wrangler command: npx wrangler hyperdrive update <HYPERDRIVE_ID> --origin-connection-limit=<MAX_CONNECTIONS>. Replace the placeholders with a configuration you are authorized to manage and a budgeted connection count. This command changes configuration; it was not executed for this guide.

The REST API uses PATCH https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/hyperdrive/configs/<HYPERDRIVE_ID> with the field origin_connection_limit. An API call requires authorization appropriate to that account. Copying a path or command does not establish that a change completed: verify the saved configuration and database monitoring.

Investigate waits and database conditions before enlarging the pool

For Failed to acquire a connection from the pool., the limits documentation lists long-running queries or transactions as a common cause: connections remain occupied and subsequent requests cannot acquire one. Check transaction duration, query time, and connection usage before deciding that the pool needs to grow.

Server connection attempt failed: connection_refused means the origin rejected a connection attempt. Database-provider connection limits or firewall conditions may be involved. The message alone does not identify the cause or prove that a higher Hyperdrive limit will fix it.

After an adjustment, observe actual origin connection usage, waits, error rates, and query performance, keeping the previous configuration value for comparison. Avoid enlarging several configurations at once or adding unbounded retries, which can pass extra connection pressure straight to the database.

How should you handle the announcement and table discrepancy?

When describing the update, you can accurately say that Cloudflare announced higher Workers Paid limits on November 11. When making a configuration change, also check the value the current account actually accepts. Retain both observations: the older table and the newer announcement do not establish a universal rollout state.

Record the announcement date, the documentation’s displayed date, your check time, and the actual configuration value separately. This source check took place on November 12, 2026. It involved no Cloudflare account access, configuration creation, database connection, or load test, so it supplies no measured account rollout, performance gain, or cost-saving result.