{"id":18133,"date":"2026-07-13T12:29:05","date_gmt":"2026-07-13T05:29:05","guid":{"rendered":"https:\/\/www.cipher.co.th\/blogs\/cloudflare-hyperdrive-postgres-2\/"},"modified":"2026-07-13T12:29:05","modified_gmt":"2026-07-13T05:29:05","slug":"cloudflare-hyperdrive-postgres","status":"publish","type":"post","link":"https:\/\/www.cipher.co.th\/en\/blogs\/cloudflare-hyperdrive-postgres\/","title":{"rendered":"Cloudflare Hyperdrive: Keep Your Existing Postgres, Move Your Compute"},"content":{"rendered":"

Quick answer:<\/strong> Hyperdrive is a connection pooler and query cache that sits between Cloudflare Workers and the PostgreSQL or MySQL database you already run. It exists because a Worker can open only 6 outgoing connections per invocation, and because traditional databases have a hard connection ceiling that a globally distributed serverless runtime will exhaust in minutes. You do not migrate your database, change your schema, or drop any extensions \u2014 you take your existing connection string, create a config, and bind it to your Worker. The one thing you must understand before switching it on is that the cache does not invalidate on write.<\/p>\n

The single biggest reason engineering teams reject Cloudflare Workers is the database. They already run PostgreSQL. The schema is stable, the reports depend on it, the backups have been tested, and someone knows how to restore it. What they want is to move compute to the edge \u2014 lower latency, no idle servers to pay for \u2014 without touching the part of the stack that works.<\/p>\n

The problem is that connecting a Worker directly to Postgres hits a wall almost immediately. A Worker gets 6 simultaneous outgoing connections per invocation, and Workers run in thousands of short-lived isolates spread across Cloudflare network. If every invocation opens a fresh connection to your database, you will exhaust its connection limit within minutes of real traffic.<\/p>\n

Hyperdrive exists specifically to fix this. This article covers what it actually does, its real limits, and the trap you will fall into if you leave the default cache settings on without reading the documentation. All numbers are from Cloudflare official documentation, checked as of July 2026.<\/p>\n

The problem Hyperdrive solves<\/h2>\n

Six connections per invocation<\/h3>\n

Workers cap simultaneous outgoing connections at 6 per invocation. The implication is that a Worker is not a long-lived server process that can hold a connection pool in memory. It is an isolate that spins up per request and disappears, with 128 MB of memory that is not shared across invocations.<\/p>\n

Translation: the connection pool that every backend engineer is used to \u2014 open 20 connections at boot, reuse them for hours \u2014 does not exist here. When traffic arrives from 300-plus cities at once, each isolate that needs the database tries to open its own connection, and Postgres eventually answers with too many connections<\/code>.<\/p>\n

Connection setup costs multiple round trips<\/h3>\n

Opening a PostgreSQL connection is not one request. It is a TCP handshake, then a TLS handshake, then the Postgres protocol authentication exchange. If your Worker runs at the edge in Bangkok and your database is in another region, every one of those round trips crosses the ocean before the first query even goes out.<\/p>\n

Hyperdrive moves that connection setup as close to your Worker as possible, and keeps the pool of real database connections near your database. Worker-to-Hyperdrive setup is fast because it happens within the same location; Hyperdrive-to-database is a warm connection that already exists.<\/p>\n

What Hyperdrive actually does<\/h2>\n

One: edge connection setup<\/h3>\n

Instead of your Worker completing a handshake across a continent, it completes a handshake with Hyperdrive in the same location. The latency of the setup phase largely disappears.<\/p>\n

Two: connection pooling near the database<\/h3>\n

Hyperdrive maintains a pool in one or more regions closest to your origin database, and caps the number of connections it opens to it: roughly 20 per configuration on the Free plan, roughly 100 on Paid. Notably, Hyperdrive does not limit how many client connections your Workers make to it. You can have as many isolates as you like; they all funnel into a bounded pool.<\/p>\n

Cloudflare is honest about one caveat here: Hyperdrive is a distributed system, and if a client cannot reach an existing pool it will establish a new one with its own connection allocation. Actual connection counts may occasionally exceed the listed limits, because the system prioritises availability over strict enforcement. Leave headroom in your Postgres max_connections<\/code>.<\/p>\n

Three: query caching<\/h3>\n

Hyperdrive parses the database wire protocol to distinguish a mutating query from a non-mutating one, and caches responses only for eligible reads. Defaults are max_age<\/code> of 60 seconds and stale_while_revalidate<\/code> of 15 seconds, and you can raise max_age<\/code> to a maximum of 1 hour. Caching is on by default.<\/p>\n

The real limits<\/h2>\n
\n\n\n\n\n\n\n\n\n\n\n\n
Limit<\/th>\nWorkers Free<\/th>\nWorkers Paid<\/th>\n<\/tr>\n<\/thead>\n
Configured databases per account<\/td>\n10<\/td>\n25<\/td>\n<\/tr>\n
Database queries<\/td>\n100,000 \/ day<\/td>\nUnlimited<\/td>\n<\/tr>\n
Origin database connections (per config)<\/td>\n~20<\/td>\n~100<\/td>\n<\/tr>\n
Initial connection timeout<\/td>\n15 seconds<\/td>\n15 seconds<\/td>\n<\/tr>\n
Idle connection timeout<\/td>\n10 minutes<\/td>\n10 minutes<\/td>\n<\/tr>\n
Maximum query duration<\/td>\n60 seconds<\/td>\n60 seconds<\/td>\n<\/tr>\n
Maximum cached query response<\/td>\n50 MB<\/td>\n50 MB<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

The one people trip over is 25 configurations per account on Paid. If you want one cached config and one cache-disabled config per database \u2014 which you probably do, for reasons covered below \u2014 that is two configs per database. Also note that a response larger than 50 MB is not cached, but is still returned to your Worker normally.<\/p>\n

Pricing, as of July 2026<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
Item<\/th>\nWorkers Free<\/th>\nWorkers Paid<\/th>\n<\/tr>\n<\/thead>\n
Database queries via Hyperdrive<\/td>\n100,000 \/ day (resets 00:00 UTC)<\/td>\nUnlimited<\/td>\n<\/tr>\n
Connection pooling<\/td>\nIncluded<\/td>\nIncluded, no additional charge<\/td>\n<\/tr>\n
Query caching<\/td>\nIncluded<\/td>\nIncluded, no additional charge<\/td>\n<\/tr>\n
Egress \/ data transfer<\/td>\nNo charge<\/td>\nNo charge<\/td>\n<\/tr>\n
Do cache hits count as queries<\/td>\nYes<\/td>\nYes (but Paid is unlimited)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

In short: on Workers Paid ($5\/month), Hyperdrive adds nothing to your bill. You still pay for your Postgres as before, and for Workers as normal. That makes the ROI calculation unusually simple, because the marginal cost of adding Hyperdrive is zero.<\/p>\n

A worked example: e-commerce with Postgres already in production<\/h2>\n

Say you run an online retailer selling into Thailand and the rest of Southeast Asia. Your PostgreSQL sits in ap-southeast-1<\/code>. The catalog holds 200,000 SKUs. You use PostGIS to find the nearest store to a buyer. Finance has written a pile of long, gnarly SQL reports against it.<\/p>\n

Migrating all of this to D1 is a non-starter \u2014 PostGIS alone rules it out. But what you do want is product pages rendered from the edge, without moving the database at all.<\/p>\n

What you build<\/h3>\n

You create two Hyperdrive configurations. The first has caching enabled, for reads that tolerate a short stale window: product listings, category pages, search results. The second is created with --caching-disabled<\/code>, for everything where stale data is a bug: authentication, sessions, permissions, cart contents, inventory counts at checkout, and any read that immediately follows a write.<\/p>\n

Bind both to the same Worker, construct a separate database client per binding, and pass the cache-disabled client to your auth and checkout modules while the cached client serves the catalog. This matters especially if an ORM owns your SQL, because the ORM writes the query, not you \u2014 the only thing you control is which client it uses.<\/p>\n

What you get<\/h3>\n

Repeated catalog queries are answered from cache at the edge, without a round trip to the database, and the load on Postgres drops correspondingly. Connections are bounded by Hyperdrive during traffic spikes instead of piling up. You did not stand up PgBouncer, you do not operate it, and you do not patch it.<\/p>\n

What to watch<\/h3>\n

If your Worker issues several sequential queries per request, running it at the edge means each query pays a cross-ocean round trip in series. Cloudflare documents the difference bluntly: 20-30 ms per query from a distant region, versus 1-3 ms when the Worker is placed near the database. The fix is Smart Placement \u2014 run the Worker close to the database instead of close to the user. But if your Worker makes only one query per request, Placement does not help, because the total round-trip time is the same either way.<\/p>\n

The traps you need to know before turning it on<\/h2>\n

The cache does not invalidate when you write<\/h3>\n

This is the one that bites teams hardest. Cloudflare documentation is explicit: Hyperdrive does not purge or invalidate cached read query results when your application writes to your database. A later matching SELECT<\/code> can return the cached result until max_age<\/code> expires, and can keep serving it during the stale_while_revalidate<\/code> window while it refreshes in the background.<\/p>\n

If you leave caching on at defaults and point it at your permissions table or your session table, you have just created a security hole with a 60-second fuse. Cloudflare guidance is direct: use a cache-disabled configuration for authentication, sessions, permissions, billing state, admin settings, and reads immediately after a write.<\/p>\n

Functions like NOW() make a query uncacheable<\/h3>\n

Hyperdrive only caches queries built from functions PostgreSQL classifies as IMMUTABLE<\/code>. Functions classified STABLE<\/code> or VOLATILE<\/code> \u2014 NOW()<\/code>, CURRENT_DATE<\/code>, CURRENT_TIMESTAMP<\/code>, RANDOM()<\/code>, LASTVAL()<\/code> \u2014 make the whole query uncacheable.<\/p>\n

So a dashboard query written as WHERE created_at > NOW() - INTERVAL 1 hour<\/code> will never be cached, not once. The fix is to compute the timestamp in application code and pass it in as a parameter. And do not write those function names in SQL comments either: Cloudflare warns that its parser uses text pattern matching and may treat a query as uncacheable because of a comment.<\/p>\n

Transaction pooling means SET does not persist<\/h3>\n

Hyperdrive pools in transaction mode. A connection returns to the pool when the transaction completes, and is then RESET<\/code>. Your SET<\/code> statements do not carry over to the next query. You must re-issue them per transaction, or bundle the SET<\/code> into the same query. Cloudflare also explicitly advises against wrapping many operations in one long transaction just to preserve state \u2014 doing so pins a connection for the whole duration and defeats the point of pooling.<\/p>\n

When a direct connection, or a server in the same region, is the better choice<\/h2>\n

Hyperdrive is not the right answer for everyone.<\/p>\n

If your backend is a long-running server sitting in the same region as your database \u2014 an API on ECS or EC2 in ap-southeast-1<\/code> \u2014 you already have an in-process connection pool and single-digit millisecond latency to the database. Putting Hyperdrive in the middle adds a hop and buys you nothing. Do not do it.<\/p>\n

If your application needs long transactions holding SET<\/code> state, advisory locks, LISTEN<\/code>\/NOTIFY<\/code>, or prepared statements that must survive across requests, transaction pooling will fight you. This is not a Hyperdrive-specific flaw \u2014 it is inherent to every transaction-mode pooler, PgBouncer included \u2014 but you need to know it before you commit.<\/p>\n

And if your workload is batch work with queries running longer than 60 seconds \u2014 ETL, large backfills, heavy reporting \u2014 Hyperdrive will terminate them. That work belongs on a server talking to Postgres directly, not in a Worker. We have written more about the boundaries in when not to use Cloudflare Workers<\/a>, and about how the runtimes compare in Cloudflare Workers vs AWS Lambda<\/a>.<\/p>\n

Summary<\/h2>\n

Hyperdrive does not magically make your Postgres faster. It removes the two structural reasons Workers cannot talk to a normal database \u2014 the 6-connection ceiling and the cost of connection setup \u2014 and adds a cache on top. That is enough to move compute to the edge without touching the database, which is exactly what most teams actually want.<\/p>\n

Cipher designs and implements systems on the Cloudflare Developer Platform for businesses in Thailand. If you have a PostgreSQL that works and you are trying to decide which parts of your compute should move to Workers, we can assess the architecture and tell you which parts are worth moving and which should stay where they are.<\/p>\n

Frequently Asked Questions<\/h2>\n

Does using Hyperdrive require migrating the database<\/h3>\n

No. Hyperdrive connects to the PostgreSQL or MySQL database you already run, whether that is RDS, Cloud SQL, Azure Database, or a server you manage yourself. You take your existing connection string, create a configuration, and bind it to your Worker. No schema changes and no dropped extensions.<\/p>\n

How much does Hyperdrive cost<\/h3>\n

As of July 2026, Hyperdrive is included in both the Workers Free and Workers Paid plans. The Free plan caps database queries at 100,000 per day; the Paid plan does not limit query volume. Connection pooling and query caching are included with no additional charge, and Hyperdrive does not charge for egress.<\/p>\n

Does the Hyperdrive cache return stale data after a write<\/h3>\n

Yes. Cloudflare documentation states that Hyperdrive does not purge or invalidate cached read results when your application writes to the database. The defaults are a max_age of 60 seconds and a stale_while_revalidate of 15 seconds. For authentication, sessions, permissions, and reads that immediately follow a write, create a second cache-disabled Hyperdrive configuration and bind it alongside the cached one.<\/p>\n

Why is a query containing NOW() never cached<\/h3>\n

Hyperdrive only caches queries whose functions PostgreSQL classifies as IMMUTABLE. Functions such as NOW(), CURRENT_DATE, and RANDOM() are classified STABLE or VOLATILE and therefore make the query uncacheable. The workaround is to compute the value in application code and pass it in as a query parameter.<\/p>\n

Does Hyperdrive actually reduce latency<\/h3>\n

It does, because connection setup happens near the Worker and the connection pool sits near the database. But if your Worker issues several sequential queries per request, you should also use Placement to run the Worker near the database. Cloudflare documents roughly 20-30 ms of latency per query from a distant region versus 1-3 ms when the Worker is placed nearby.<\/p>\n","protected":false},"excerpt":{"rendered":"

Quick answer: Hyperdrive is a connection pooler and query cache that sits between Cloudflare Workers and the PostgreSQL or MySQL […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_angie_page":false,"content-type":"","site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"page_builder":"","footnotes":""},"categories":[152],"tags":[],"class_list":["post-18133","post","type-post","status-publish","format-standard","hentry","category-technology-en"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts\/18133","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/comments?post=18133"}],"version-history":[{"count":0,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/posts\/18133\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/media?parent=18133"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/categories?post=18133"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cipher.co.th\/en\/wp-json\/wp\/v2\/tags?post=18133"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}