Cloudflare Python Workers 怎麼接 Hyperdrive?PostgreSQL 與 MySQL 的設定邊界
Cloudflare Hyperdrive 現在可以讓 Python Workers 連到既有的 PostgreSQL 或 MySQL 資料庫,但 Python 支援在 2026 年 9 月仍是 Beta。直接答案是:先把 compatibility date 設為 2026-09-08 或更新、開啟 python_workers compatibility flag,再依資料庫選擇 async driver,最後用 pywrangler 打包與部署。 這條路適合已經有外部資料庫、想在 Worker 端使用 Python 的服務;不代表同步 SQLAlchemy、任意 socket 程式庫或 async SQLAlchemy 都已經完整支援。
本文聚焦 Python Worker 的 Hyperdrive 邊界。若你是用 JavaScript Worker 和 mysql2,可先看Cloudflare Hyperdrive 連 MySQL 的設定與連線池;若你的需求是把 WSGI/ASGI 應用搬到 Workers,則應先閱讀Cloudflare Python Workers 的 WSGI、ASGI 與框架選擇。
先確認 Beta 的適用條件
官方 Python Hyperdrive 文件列出的基本邊界是:
- compatibility date 要是
2026-09-08或更新版本。 - Wrangler 設定要加入
python_workerscompatibility flag。 - 目前可連 PostgreSQL 與 MySQL。
- 官方文件建議使用支援的 Python database driver,再透過 Hyperdrive binding 取得連線設定。
- Python Workers 透過 TCP socket API 連線;同步操作需要鎖定以序列化存取。
- 目前只有同步 SQLAlchemy,async SQLAlchemy 因為依賴 greenlet 而不支援。
這些條件不是部署後才處理的微調,而是選型門檻。如果你的應用程式依賴 async SQLAlchemy、需要大量同步資料庫操作,或必須使用尚未確認支援的 driver,先做小型 PoC,別直接搬整個 production service。
Wrangler 設定 Hyperdrive binding
以下是 JSONC 設定的最小方向;HYPERDRIVE 是程式碼裡要使用的 binding 名稱,id 必須換成你在 Cloudflare 建立的 Hyperdrive config ID:
{ "name": "python-hyperdrive-worker", "main": "src/entry.py", "compatibility_date": "2026-09-20", "compatibility_flags": ["python_workers"], "hyperdrive": [ { "binding": "HYPERDRIVE", "id": "replace-with-hyperdrive-config-id" } ]}這段設定使用目前日期只是示意,重點是不能早於 Python Hyperdrive 文件要求的 compatibility date。實際部署前,請確認專案的 Wrangler 版本、Hyperdrive config ID、資料庫網路可達性與 secrets 都已分開設定;不要把資料庫密碼寫進 repository。
若專案使用 wrangler.toml,欄位名稱和陣列語法會不同,但要表達相同的 compatibility_date、compatibility_flags 與 Hyperdrive binding。完成後先用本地開發命令確認打包結果,再部署:
uv run pywrangler devuv run pywrangler deploy這裡的命令是官方部署流程的寫法,不代表本次排程已替你的 Cloudflare 帳號執行;本次沒有進行 live Worker、資料庫或 migration 測試。
依資料庫選 driver 與依賴
官方範例目前建議的 driver 可以整理成這樣:
| 資料庫 | 可先評估的 driver | 先確認的事 |
|---|---|---|
| PostgreSQL | asyncpg、pg8000、psycopg | async/sync API 與你現有 repository 的使用方式 |
| MySQL | aiomysql、pymysql | event loop、連線關閉與 query timeout 行為 |
例如 pyproject.toml 可以先只加入一種目標資料庫 driver:
[project]dependencies = [ "asyncpg",]不要把表格中的所有 driver 都安裝進 Worker 來「增加相容性」。這會擴大 bundle、引入不必要的依賴,也讓真正使用哪一個 driver 變得不清楚。依官方範例選一個最符合資料庫與程式模型的 driver,再用最小 query 驗證。
PostgreSQL 的最小連線流程
Python Worker 會從 Hyperdrive binding 取得 connection string,再交給 driver。概念上的 asyncpg 寫法如下:
from workers import WorkerEntrypoint, Responseimport asyncpg
class Default(WorkerEntrypoint): async def fetch(self, request): connection = await asyncpg.connect( self.env.HYPERDRIVE.connectionString, ssl=False, ) try: row = await connection.fetchrow("SELECT 1 AS ok") return Response.json({"ok": row["ok"]}) finally: await connection.close()實際專案要依官方 Python Workers runtime、driver 版本與你的 entrypoint 形狀調整。這裡的 SELECT 1 只能確認最小連線路徑,不能證明 transaction、pool、query timeout、migration 或權限模型都適用。不要把這段示意程式當成已在本機或 production 執行過的測試。
MySQL 的最小連線流程
MySQL 可以依官方範例評估 aiomysql 或 pymysql。以 async driver 的概念寫法來說,重點是傳入 Hyperdrive 提供的連線參數,並在 request 結束前釋放連線:
import aiomysqlfrom workers import WorkerEntrypoint, Response
class Default(WorkerEntrypoint): async def fetch(self, request): connection = await aiomysql.connect( host=self.env.HYPERDRIVE.host, port=self.env.HYPERDRIVE.port, user=self.env.HYPERDRIVE.user, password=self.env.HYPERDRIVE.password, db=self.env.HYPERDRIVE.database, ssl=None, ) try: async with connection.cursor() as cursor: await cursor.execute("SELECT 1 AS ok") row = await cursor.fetchone() return Response.json({"ok": row[0]}) finally: connection.close()不同版本的 driver、Workers Python runtime 和 Hyperdrive 文件可能要求不同的連線欄位或 SSL 處理;上例是閱讀官方範例後整理的結構,不是本次執行的實測程式。部署前應把官方範例與你安裝的 driver 版本逐欄比對,並在測試資料庫驗證連線關閉、錯誤處理和權限。
SQLAlchemy、socket 與同步操作的限制
Python Hyperdrive 最容易被誤解的地方,是「能連資料庫」不等於所有 Python database stack 都已可用:
同步 SQLAlchemy 可以評估,async SQLAlchemy 目前不要直接假設支援
Cloudflare 文件目前指出同步 SQLAlchemy 可用,但 async SQLAlchemy 因為依賴 greenlet 而不支援。如果現有應用程式使用 create_async_engine、async session 或依賴 greenlet 的框架整合,先保留原本架構或改做小型 PoC,不要只把 connection URL 換成 Hyperdrive 就部署。
TCP socket API 會影響可用程式庫
Python Workers 的資料庫連線透過 TCP socket API。依賴特殊 OS socket 行為、背景 thread 或 native extension 的套件,不能只以「在一般 Python 伺服器跑過」推論在 Worker 會工作。把 driver、bundle、runtime 和一個真實測試資料庫放進驗證矩陣。
同步操作要有鎖
官方文件提醒同步操作需要 lock 以序列化存取。若你把共享連線或同步 client 放在 module scope,必須確認並行 request 不會同時修改同一個狀態;更保守的做法是按照官方範例管理 request 生命週期,並針對 timeout、錯誤與 close 寫測試。
上線前的最小驗證矩陣
在把原本的應用程式搬到 Python Worker 前,至少完成以下驗證:
- 用
uv run pywrangler dev確認 bundle 可以建立,且只包含真正需要的 driver。 - 在測試資料庫執行一個 read query、parameterized write 和 transaction rollback。
- 模擬資料庫拒絕、逾時、連線關閉與 Worker request 取消。
- 分別驗證單一 request、並行 request 和冷啟動,不把一次成功的
SELECT 1當成 pool 正常。 - 若使用 SQLAlchemy,確認是同步路徑,並把 session、transaction 和 lock 的生命週期寫進測試。
- 確認 Hyperdrive、資料庫與 Worker 的權限最小化,且 log 不會輸出 connection string。
- 再用
uv run pywrangler deploy部署到非 production 環境,觀察實際 latency、錯誤率與資料庫連線數。
這次排程只建立指南,沒有替你完成第 2 至 7 項的 live 驗證。這個限制很重要:Cloudflare 文件支援的是整合路徑,不是對你的 driver 版本、schema、query 和流量模型做保證。
常見問題
Q: Python Workers 的 Hyperdrive 現在可以直接用在 production 嗎?
A: 文件目前標示 Python Hyperdrive 支援為 Beta。你可以先做非 production PoC 和獨立的回復策略;是否上 production 應由你的風險門檻、資料庫需求和 Cloudflare 當前文件決定。
Q: 只要是 async Python driver 就一定支援嗎?
A: 不一定。文件列出可評估的 driver,但 runtime、bundle、socket、連線生命週期仍要實測。尤其不要把 async SQLAlchemy 的支援,從 asyncpg 或 aiomysql 的可用性推論出來。
Q: 可以沿用既有的 WSGI 或 ASGI 資料庫設定嗎?
A: 不能直接假設。WSGI/ASGI 框架的生命週期、背景工作和同步模型可能不符合 Python Workers。先分開驗證框架適配、Hyperdrive binding 和 driver,再決定是否整合。
參考資料:
Cloudflare Docs:Hyperdrive changelog
回報錯字、失效連結,或告訴我你想看的延伸主題。