Cloudflare Lets Python Apps Reuse Existing Databases

The Database Can Stay Where It Is

The useful part of this release is what you no longer have to move.

Hyperdrive is a managed connection layer between a Cloudflare Worker and an existing PostgreSQL or MySQL database. It isn't a new database, and it doesn't copy your records into Cloudflare. Your Python code opens a TCP connection with a normal database driver, using connection details supplied by a Hyperdrive binding. Hyperdrive handles the long-lived pool of connections to the database behind it.

That changes the common workaround. A Python Worker that couldn't use its database path directly might call a small API or server whose only job was to run SQL. The route looked like this:

Before: Python Worker → database bridge → PostgreSQL or MySQL

Now: Python Worker → Hyperdrive → PostgreSQL or MySQL

Cloudflare performs connection setup near the Worker and keeps pooled connections near the origin database. Its Hyperdrive guide counts seven round trips in a conventional setup before the first query: one for TCP, three for TLS, and three for database authentication. Reusing the pool avoids repeating that full setup for each short-lived Worker invocation.

The supported path is specific. Python Workers need a compatibility date of 2026-09-08 or later, and the feature is still beta. Cloudflare has tested asyncpg, pg8000, and psycopg for PostgreSQL, plus aiomysql and pymysql for MySQL. asyncpg and aiomysql are the recommended drivers.

Cloudflare says other TCP drivers may work. That isn't the same as promising that every package, ORM, or existing application will work. Database compatibility gets you to the first gate, not through the whole migration.

The Budget Line That Changed

The cleanest cost win appears when you already run the Python app on Workers and pay for a bridge only because the Worker needs database access.

The math is simple:

Current monthly cost = database + Worker + bridge host

Possible monthly cost = database + Worker

Your database bill remains. Hyperdrive's built-in connection pooling and query caching add no separate charge on Workers Paid, and Hyperdrive has no egress charge. If the account already sits inside its included Workers usage, the Cloudflare increment for this connection path is therefore $0. The possible cash saving is the bridge host bill that actually disappears.

Maintenance is part of the same calculation. Removing that bridge can also remove one deployment, one health check, one set of secrets, one log stream, and one failure boundary. Do not assign a dollar value to that work until you know who maintains it and how often it causes trouble.

For a new paid account, Workers Paid starts at $5 per account per month. That includes 10 million requests and 30 million CPU milliseconds each month. Overage is $0.30 per additional million requests and $0.02 per additional million CPU milliseconds. Hyperdrive database queries are listed as unlimited on that plan.

The Free plan can carry a small proof. It includes 100,000 Worker requests per day and 100,000 Hyperdrive database queries per day, with 10 milliseconds of CPU time per invocation. Those are separate counters. One request that runs several SQL statements can consume several database queries.

Who Can Use This Tomorrow

A Solo Founder With a FastAPI Service

Say a founder has a FastAPI Worker in front of a managed PostgreSQL database, plus a tiny container that accepts HTTP calls and runs SQL. If that container contains no business logic, a test with asyncpg can show whether Hyperdrive can replace it.

The payoff isn't a new database. It is keeping the current schema, backups, and provider while deleting a service that existed only as a connection adapter. The founder should migrate one route first, compare its result and latency, then remove the bridge after production behavior matches.

A Small Agency With Client MySQL Databases

A small agency may maintain several narrow Python APIs, each pointed at a client's MySQL database. The new path lets the agency test aiomysql or pymysql inside the Worker instead of deploying a database proxy beside every qualifying app.

The payoff is operational consistency. The agency can use one Worker deployment path and one Hyperdrive configuration per database. The bridge still stays when it performs tenant authorization, schema translation, auditing, or other work beyond passing queries through.

A Platform Team Moving One Read-Heavy Endpoint

A platform team does not have to migrate its whole backend. It can move one public, read-heavy Python endpoint to Workers, keep the regional database, and let Hyperdrive pool the origin connections.

This is also where caching needs an explicit decision. Hyperdrive caches eligible reads by default for 60 seconds and may serve a stale result for another 15 seconds while it revalidates. Public catalog or content reads may tolerate that. Authentication, permissions, billing state, and reads immediately after a write should use a separate cache-disabled Hyperdrive configuration.

The earlier Django versus FastAPI comparison still helps with framework choice. This release changes one part of that decision: keeping PostgreSQL or MySQL is now a documented Python Worker path, but it does not certify the rest of a Django or FastAPI application.

Build the Smallest Safe Connection Test

Use a non-production MySQL database and a limited test user. The goal is to prove the connection path with SELECT 1, not to rehearse a full migration against customer data.

Create a cache-disabled Hyperdrive configuration so the first test measures a fresh database round trip:

npx wrangler hyperdrive create python-db-test --connection-string="mysql://user:password@HOSTNAME_OR_IP_ADDRESS:PORT/database_name" --caching-disabled

Copy the configuration ID from Wrangler into wrangler.toml. The date below is later than the required 2026-09-08 minimum:

name = "python-hyperdrive"
main = "src/main.py"
compatibility_date = "2026-09-16"
compatibility_flags = ["python_workers"]

[[hyperdrive]]
binding = "HYPERDRIVE"
id = "<HYPERDRIVE_CONFIG_ID>"

Add the driver to pyproject.toml:

[project]
dependencies = [
    "aiomysql",
]

Then use Cloudflare's documented connection test in src/main.py:

import aiomysql
from workers import Response, WorkerEntrypoint


class Default(WorkerEntrypoint):
    async def fetch(self, request):
        hd = self.env.HYPERDRIVE
        connection = await aiomysql.connect(
            host=hd.host,
            port=int(hd.port),
            user=hd.user,
            password=hd.password,
            db=hd.database,
            ssl=None,
        )
        try:
            cursor = await connection.cursor()
            await cursor.execute("SELECT 1")
            result = await cursor.fetchone()
            return Response.json({"result": result[0]})
        finally:
            connection.close()

Deploy it with the documented Python Workers command:

uv run pywrangler deploy

The line that often looks wrong is ssl=None. That is the driver connection from the Worker to Hyperdrive in Cloudflare's example. Hyperdrive's connection to the origin database still requires TLS, and insecure plaintext origin connections are not supported.

The Bridge Is Optional, Not Automatically Obsolete

The launch changes a connection path. It does not turn Python Workers into an unrestricted CPython server.

Python package support covers pure Python packages, PyEmscripten wheels, and packages included with Pyodide. Cloudflare still calls WebAssembly package support early, so a missing dependency can stop the migration. The driver and ORM documentation currently supports synchronous SQLAlchemy only. Async SQLAlchemy is not supported because the Workers environment lacks greenlet support.

The database protocol has its own walls. Hyperdrive supports PostgreSQL 9.0 through 17.x and MySQL 5.7 through 8.x, plus MariaDB. It does not support SQL Server or MongoDB. PostgreSQL advisory locks and LISTEN or NOTIFY are out. MySQL multi-statement queries and protocol-level prepared statements are out. A 60-second maximum query duration applies on both Free and Paid.

Pooling changes session assumptions too. Hyperdrive uses transaction pooling, which means the origin connection returns to the pool when the transaction ends. Code that expects session state to survive across transactions needs review. Long transactions can also exhaust the pool and erase the concurrency benefit.

The Monday Move

Do not migrate the application on Monday. Prove whether one database-only bridge deserves to exist.

Act this week if the bridge exists only for database access, the app uses PostgreSQL or MySQL, and a tested driver covers the route. Wait if you rely on async SQLAlchemy, an unavailable package, unsupported SQL behavior, or strict read-after-write consistency you have not separated. You are unaffected if the app is staying on its current server or the bridge carries business logic that Hyperdrive does not replace.

For the next platform change translated into a Monday decision, join the newsletter.