Cloudflare Hyperdrive для Python Workers: PostgreSQL и MySQL на edge

16 сентября 2026 года Cloudflare добавил поддержку Hyperdrive в Python Workers. Это позволяет Python-приложению на Workers подключаться к существующей PostgreSQL- или MySQL-базе через Hyperdrive, не вынося backend на отдельный VPS только ради TCP-соединения с БД.

Для проектов с API, ботами, интеграциями и небольшими serverless-сервисами изменение практичное: Python Worker можно оставить на edge, а данные — в уже существующей региональной базе. При этом важно учитывать, что поддержка Hyperdrive в Python Workers пока имеет статус beta.

Что даёт Hyperdrive

Hyperdrive работает как слой между Worker и существующей PostgreSQL/MySQL-базой. Cloudflare поддерживает пул соединений внутри своей сети и сокращает лишние сетевые round trip при установлении соединения. Для read-запросов Hyperdrive также умеет использовать кэширование.

Саму базу переносить в Cloudflare не требуется. Hyperdrive поддерживает обычные PostgreSQL и MySQL, а также совместимые сервисы и провайдеры, включая managed-базы в AWS, Google Cloud, Azure, Neon, PlanetScale и другие совместимые решения.

Что изменилось именно для Python Workers

До этого Hyperdrive в первую очередь использовался из JavaScript/TypeScript Workers. Теперь Python Workers могут получать Hyperdrive binding и устанавливать соединение через TCP socket support.

По текущей документации Cloudflare для Python Workers требуется compatibility_date не раньше 2026-09-08. В конфигурации также используется флаг python_workers.

{
  "name": "python-hyperdrive",
  "main": "src/main.py",
  "compatibility_date": "2026-09-16",
  "compatibility_flags": ["python_workers"],
  "hyperdrive": [{"binding": "HYPERDRIVE", "id": "<HYPERDRIVE_CONFIG_ID>"}]
}

Какие драйверы поддерживаются

Cloudflare пишет, что технически можно использовать Python-драйверы, которые работают через TCP, но отдельно перечисляет протестированные варианты.

Пример PostgreSQL через asyncpg

После добавления binding параметры подключения доступны через self.env.HYPERDRIVE. В Python Worker можно передать их привычному драйверу:

import asyncpg
from workers import WorkerEntrypoint, Response

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        hd = self.env.HYPERDRIVE
        conn = await asyncpg.connect(
            host=hd.host,
            port=int(hd.port),
            user=hd.user,
            password=hd.password,
            database=hd.database,
            ssl=False,
        )
        value = await conn.fetchval("SELECT 1")
        await conn.close()
        return Response.json({"ok": value == 1})

Здесь Worker подключается не напрямую к публичному адресу БД, а к параметрам, которые предоставляет Hyperdrive binding.

Пример MySQL через aiomysql

import aiomysql
from workers import WorkerEntrypoint, Response

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

Почему Hyperdrive полезнее прямого подключения

Региональная база может находиться далеко от пользователя, а Worker выполняется в сети Cloudflare рядом с запросом. Если каждый Worker заново проходит TCP/TLS/authentication до origin, задержка складывается из нескольких сетевых обменов.

Hyperdrive держит соединения к базе через свою инфраструктуру и повторно использует их. Это особенно заметно для API, где один HTTP-запрос делает один-два коротких SQL-запроса и сам SQL выполняется быстрее, чем устанавливается новое соединение.

Ограничения beta, которые нужно учитывать

Поддержка Hyperdrive в Python Workers сейчас обозначена Cloudflare как beta, поэтому production-переход лучше делать после тестирования конкретного драйвера и нагрузки.

• TCP socket support. Большинство стандартных socket-операций работает, но низкоуровневые сценарии могут отличаться от обычного CPython на Linux.
• Concurrency. Внутренняя реализация сокетов асинхронная, однако синхронные операции с драйвером нужно сериализовать, если библиотека не рассчитана на параллельный доступ.
• SQLAlchemy. В Python Workers сейчас поддерживается только синхронный SQLAlchemy ORM. Async SQLAlchemy пока ограничен отсутствием greenlet в среде Workers.
• Драйверы. Лучше начинать с вариантов, которые Cloudflare явно протестировал, а не переносить произвольную библиотеку без проверки.

Нужно ли включать SSL в Python-драйвере

В официальных примерах Python Workers для подключения к Hyperdrive у asyncpg используется ssl=False, а у aiomysql — ssl=None. Это относится к соединению Worker → Hyperdrive. Настройки защищённого соединения Hyperdrive → origin задаются конфигурацией Hyperdrive и инфраструктурой базы.

Не стоит механически переносить параметры из прямого connection string к базе: Worker подключается к Hyperdrive endpoint, а не к origin тем же способом, что локальное приложение.

Когда архитектура подходит

• serverless API на Python должен читать или изменять данные существующей PostgreSQL/MySQL;
• нужно оставить базу у текущего провайдера, но приблизить backend-обработчик к пользователям;
• Cloudflare Worker используется как API-шлюз между сайтом, CRM, ботом и базой;
• проект не хочется переносить на D1 только ради запуска на Workers;
• нужно использовать Python-библиотеки и привычный SQL-драйвер вместо переписывания backend на JavaScript.

Когда лучше не спешить

Если приложение сильно зависит от нестандартных socket-возможностей, async SQLAlchemy, специфического native-пакета или сложного connection lifecycle, beta-режим нужно проверить на staging. То же относится к системам с длинными транзакциями и большим числом одновременно открытых соединений.

Hyperdrive не заменяет нормальную схему БД: индексы, медленные запросы, транзакции и блокировки всё равно остаются ответственностью приложения и базы.

Связь с другими возможностями Workers

Python Workers постепенно становятся полноценнее как backend-среда: рядом доступны bindings к R2, D1, KV, Durable Objects, Queues, Workflows и другим сервисам. Hyperdrive закрывает отдельный сценарий — когда данные уже живут в обычной PostgreSQL/MySQL и переносить их не хочется.

Если проект использует Workers как интеграционный слой, полезно также учитывать изменения runtime и модулей. Я отдельно разбирал обновление module registry в Cloudflare Workers.

Официальные источники

• Cloudflare Hyperdrive Changelog — 16 сентября 2026
• Cloudflare Docs — Hyperdrive from Python Workers
• Cloudflare Hyperdrive Overview
• Supported databases and features

Если нужно собрать serverless API или интеграционный слой вокруг существующего сайта, CRM и базы, можно обсудить автоматизацию или прислать текущую схему проекта. Сначала имеет смысл определить источники данных, нагрузку и требования к отказоустойчивости, а уже потом выбирать Workers, Hyperdrive или обычный сервер.