Cloudflare does not sell a managed PostgreSQL product. D1 is SQLite. What Cloudflare offers instead is Hyperdrive, a connection pooler and query cache that lets a Worker talk to a regular Postgres database you already run somewhere else.
The search “cloudflare postgres” usually starts from a reasonable assumption: Cloudflare has D1, so surely it has a Postgres equivalent too. It does not, and the actual answer is more interesting than a missing product. It is a piece of network infrastructure that makes any existing Postgres database behave better from inside a Worker, wherever that database actually lives.
Table of contents
- What Cloudflare actually ships, and what it does not
- How Hyperdrive actually works
- Setting it up: wrangler hyperdrive create
- Connecting from a Worker with node-postgres
- Your database still has to be reachable
- Latency still depends on where the database actually lives
- When this setup is the right one, and when it isn’t
- How this fits the rest of the stack
- FAQ
What Cloudflare actually ships, and what it does not
Cloudflare’s own database product is D1, and D1 is SQLite under the hood, not Postgres. If your project needs Postgres’s type system, its indexing, or an existing schema you already run elsewhere, D1 is not a substitute and was never trying to be one.
What Cloudflare does ship for Postgres users is Hyperdrive, a service that sits between a Worker and your existing regional database. Hyperdrive does not store your data. It maintains a connection pool inside Cloudflare’s network and caches the read queries it sees repeated, so a Worker running near a visitor in Singapore does not pay the full TCP handshake, TLS negotiation, and authentication round trip on every request to a database sitting in a single AWS region.
That distinction matters because it changes what you’re actually evaluating. You are not choosing a database vendor. You are choosing whether to put an accelerator in front of the Postgres you already have, or already need to provision, somewhere else entirely.
It also explains why the search itself is so common. “Cloudflare postgres” is what someone types when they’ve already decided to build on Workers and assume the database story follows the same one-vendor simplicity as the rest of the platform. Cloudflare’s own documentation is upfront that Hyperdrive works with any Postgres or MySQL database, including ones hosted on AWS, Google Cloud, Azure, Neon, and PlanetScale, along with Postgres-compatible engines like CockroachDB and Timescale. The product was built around the assumption that your database lives somewhere else.
How Hyperdrive actually works
A cold connection to Postgres costs roughly seven round trips before your first query even runs: one for the TCP handshake, three for TLS negotiation, three for database authentication. From a Worker running at the edge, each of those round trips crosses real distance to your database’s region.
Hyperdrive keeps a warm connection pool open inside Cloudflare’s network, so a Worker borrows an existing connection instead of opening a new one per request. It also understands the difference between read and write queries, and caches the results of repeated reads for a short, configurable window, which takes load off the origin database as a side effect.
- Connection pooling removes the handshake and auth cost from the request path
- Query caching is default-on for eligible read queries
- Write queries are never cached and always reach the origin database
- Your existing driver and ORM keep working unchanged
Setting it up: wrangler hyperdrive create
Hyperdrive configuration lives outside your code, created once with Wrangler and then bound into a Worker. You need the database’s host, port, username, password, and database name, in the same connection-string shape most drivers already expect.
npx wrangler hyperdrive create my-postgres-db \
--connection-string="postgres://user:password@HOST:5432/dbname"That command returns an id. Add it to your Wrangler configuration alongside a binding name, and the connection string becomes available to your Worker at runtime without ever appearing in your source code.
{
"hyperdrive": [
{
"binding": "HYPERDRIVE",
"id": "<your-hyperdrive-id>"
}
],
"compatibility_flags": ["nodejs_compat"]
}The nodejs_compat flag is not optional. Postgres drivers rely on Node APIs that Workers do not expose by default, and without it the deploy will fail well before you reach a database error.
Connecting from a Worker with node-postgres
With the binding in place, a Worker connects the way it would against any Postgres instance, just pointed at the connection string Hyperdrive hands it rather than one you manage yourself.
import { Client } from "pg";
export default {
async fetch(request, env) {
const client = new Client({
connectionString: env.HYPERDRIVE.connectionString,
});
await client.connect();
const result = await client.query("SELECT id, name FROM projects LIMIT 20");
return Response.json(result.rows);
},
};Creating a new client per request looks expensive if you’re used to long-lived server processes, but it is not: Hyperdrive keeps the real connection pool warm on its side, so a new client object in your Worker is cheap. postgres.js works the same way if you prefer it over node-postgres.
Your database still has to be reachable
Hyperdrive accelerates a connection, it does not create a network path that does not exist. Your Postgres instance needs to be reachable from Cloudflare’s network, which means one of two shapes in practice.
- A publicly reachable database with SSL enforced, and firewall rules that allow Cloudflare’s connecting IP ranges
- A private database reached through Cloudflare Tunnel or the Workers VPC connect path, so the database never needs a public IP at all
The second option is the one worth taking seriously if the database was never meant to face the internet. Punching a hole in a security group to satisfy a serverless function is exactly the kind of shortcut that turns into an incident report.
Latency still depends on where the database actually lives
Hyperdrive removes the connection-setup tax, not the speed of light. A query that requires a fresh read from the origin still travels from Cloudflare’s network to wherever your Postgres instance is deployed, and a cache miss on a single-region database in Virginia is still a trip to Virginia.
The gains are largest for read-heavy workloads with cacheable queries and a Worker population spread across regions the database was never near. If your traffic and your database already live in the same region, the marginal benefit is smaller, and the architecture question becomes whether Hyperdrive is solving a problem you actually have.
When this setup is the right one, and when it isn’t
This shape fits teams that are already committed to Workers for the application layer and have a Postgres database they are not ready to move, whether that’s a managed instance on another cloud or something self-hosted.
If you’re starting from scratch and don’t have a strong reason to run on Workers specifically, running the application and the database close together, on infrastructure built to hold both, removes a network hop the Hyperdrive architecture exists to paper over. Sometimes the better fix is proximity, not caching.
There’s also a cost dimension worth naming honestly. Hyperdrive itself is available on free and paid Workers plans, but you’re still paying for the origin Postgres database separately, wherever it’s hosted, plus egress from that provider every time a query actually reaches it. The pitch of “one platform” gets less true the moment your invoice arrives from three different vendors instead of one.
How this fits the rest of the stack
None of this is a criticism of Hyperdrive, which does exactly what it says. It just means the decision starts with your database, not with Cloudflare. If you’re weighing whether to run the whole stack somewhere the app and the Postgres instance sit next to each other instead, RunxBuild runs managed Postgres with connection limits, backups, and private networking alongside the service that queries it, and the RunxBuild hosting calculator breaks down what that pairing costs before you commit to either architecture.
If the Postgres behind Hyperdrive does not exist yet, a managed instance can be created from the RunxBuild dashboard and its connection string dropped into the Hyperdrive config.
Useful related references:
- Prisma Postgres: What It Actually Adds Over Plain Postgres
- Google Cloud Postgres: Cloud SQL, AlloyDB, and What to Actually Pick
- Cloudflare VPS: Why the Search Keeps Landing on the Wrong Product
- Databases on RunxBuild
FAQ
Does Cloudflare have a managed PostgreSQL database?
No. Cloudflare’s own database product, D1, is built on SQLite, not Postgres. For Postgres, Cloudflare provides Hyperdrive, which connects Workers to a Postgres database you host elsewhere rather than hosting one itself.
Is D1 the same as PostgreSQL?
No. D1 is a SQLite-based database built for Workers. It has a different SQL dialect, different type system, and different scaling model from PostgreSQL, and it is not a drop-in replacement for an existing Postgres schema.
Do I need to change my database driver to use Hyperdrive?
No. Hyperdrive is designed to work with your existing driver or ORM. You install node-postgres or postgres.js as you normally would and point the connection string at the value Hyperdrive provides through the binding.
Can Hyperdrive connect to a private database that isn’t publicly reachable?
Yes. Besides a public database secured with SSL, Hyperdrive supports reaching a private database through Cloudflare Tunnel or the Workers VPC connect path, so the database never needs a public IP address.
Does Hyperdrive make every query faster?
It removes the connection setup overhead on every request and caches eligible read queries, but it does not change physical distance. A cache miss still travels to wherever the origin database is deployed, so gains are largest for read-heavy, geographically distributed workloads.