Cloudflare Workers Pythonで既存DBへ直結、ブリッジを外せるか

Cloudflare Workers Pythonでもデータベースは移さなくていい

今回のリリースで重要なのは、移行せずに済むものです。

Hyperdriveは、Cloudflare Workerと既存のPostgreSQLまたはMySQLデータベースをつなぐマネージド接続レイヤーです。新しいデータベースではなく、レコードをCloudflareへコピーする仕組みでもありません。Pythonコードは、Hyperdriveバインディングから渡される接続情報を使い、通常のデータベースドライバーでTCP接続を開きます。背後では、Hyperdriveがデータベースへの長期接続プールを管理します。

これにより、従来よく使われていた回避策が変わります。データベースへ直接接続できないPython Workerでは、SQLを実行するためだけの小さなAPIやサーバーを呼び出す構成が必要でした。接続経路は次のとおりです。

従来: Python Worker → データベースブリッジ → PostgreSQLまたはMySQL

現在: Python Worker → Hyperdrive → PostgreSQLまたはMySQL

CloudflareはWorkerの近くで接続を確立し、接続プールはオリジンデータベースの近くに維持します。Hyperdriveガイドによると、一般的な構成では最初のクエリまでに7往復が発生します。内訳はTCPが1回、TLSが3回、データベース認証が3回です。プール内の接続を再利用すれば、短時間で終了するWorkerが呼び出されるたびに、この一連の接続処理を繰り返す必要がありません。

利用条件は明確です。Python Workersでは互換性の日付を2026-09-08以降にする必要があり、この機能はまだベータ版です。CloudflareはPostgreSQL用としてasyncpg、pg8000、psycopgを、MySQL用としてaiomysqlとpymysqlをテスト済みです。推奨ドライバーはasyncpgとaiomysqlです。

Cloudflareは、ほかのTCPドライバーも動作する可能性があるとしています。ただし、すべてのパッケージ、ORM、既存アプリケーションの動作を保証しているわけではありません。データベース互換性は移行の最初の関門にすぎず、それだけで移行が完了するわけではありません。

Cloudflare Hyperdriveで変わる月額コストの計算式

すでにPythonアプリをWorkersで動かし、Workerからデータベースへ接続するためだけにブリッジ費用を払っている場合、最もわかりやすいコスト削減が見込めます。

計算は単純です。

現在の月額コスト = データベース + Worker + ブリッジのホスティング

移行後に見込まれる月額コスト = データベース + Worker

データベース料金は残ります。Hyperdriveに組み込まれた接続プールとクエリキャッシュはWorkers Paidで別料金がかからず、Hyperdriveにはエグレス料金もありません。アカウントがすでにWorkersの付属利用枠に収まっているなら、この接続経路によって増えるCloudflare料金は$0です。実際に削減できる現金支出は、廃止できたブリッジのホスティング料金です。

保守負担も同じ計算に含める必要があります。ブリッジを外せば、デプロイ先、ヘルスチェック、シークレット一式、ログストリーム、障害境界をそれぞれ1つずつ減らせる可能性があります。ただし、誰が保守し、どの程度の頻度で問題を起こしているかを把握するまでは、その作業に金額を割り当てるべきではありません。

新規の有料アカウントでは、Workers Paidは1アカウントあたり月額$5からです。毎月1,000万リクエストと3,000万CPUミリ秒が含まれます。超過分は追加100万リクエストごとに$0.30、追加100万CPUミリ秒ごとに$0.02です。このプランでは、Hyperdriveのデータベースクエリ数は無制限とされています。

Freeプランでも小規模な検証は可能です。Workerリクエストは1日100,000件、Hyperdriveのデータベースクエリも1日100,000件まで含まれ、1回の呼び出しで使えるCPU時間は10ミリ秒です。リクエスト数とデータベースクエリ数は別々に数えられます。1回のリクエストで複数のSQL文を実行すれば、データベースクエリを複数回消費することがあります。

明日から試せるケース

FastAPIサービスを運営する個人創業者

ある創業者が、マネージドPostgreSQLデータベースの手前でFastAPI Workerを動かし、HTTPリクエストを受けてSQLを実行するだけの小さなコンテナも運用しているとします。そのコンテナにビジネスロジックがなければ、asyncpgを使ったテストでHyperdriveに置き換えられるか確認できます。

メリットは、新しいデータベースへ移ることではありません。現在のスキーマ、バックアップ、プロバイダーを維持したまま、接続アダプターとしてのみ存在していたサービスを削除できる点です。まず1つのルートを移行し、結果とレイテンシーを比較します。本番環境で同じ挙動を確認してからブリッジを外すべきです。

顧客のMySQLデータベースを扱う小規模エージェンシー

小規模なエージェンシーでは、それぞれ顧客のMySQLデータベースへ接続する小さなPython APIを複数保守していることがあります。新しい経路なら、条件に合うアプリごとにデータベースプロキシをデプロイする代わりに、Worker内でaiomysqlまたはpymysqlをテストできます。

ここでの利点は、運用を統一できることです。エージェンシーは1つのWorkerデプロイ経路と、データベースごとに1つのHyperdrive設定を使えます。一方、テナント認可、スキーマ変換、監査など、クエリを中継する以上の処理をブリッジが担っている場合は、そのまま残します。

読み取り中心のエンドポイントを1つ移すプラットフォームチーム

プラットフォームチームがバックエンド全体を移行する必要はありません。一般公開されている読み取り中心のPythonエンドポイントを1つだけWorkersへ移し、リージョン内のデータベースは維持したまま、Hyperdriveにオリジン接続をプールさせることができます。

このケースでは、キャッシュ方針も明示的に決める必要があります。Hyperdriveは対象となる読み取り結果をデフォルトで60秒間キャッシュし、再検証中はさらに15秒間、古い結果を返す可能性があります。公開カタログやコンテンツの読み取りなら許容できるかもしれません。認証、権限、請求状態、書き込み直後の読み取りには、キャッシュを無効にした別のHyperdrive設定を使うべきです。

以前のDjangoとFastAPIの比較は、フレームワーク選びにも引き続き役立ちます。今回のリリースで変わったのは、その判断材料の一部です。PostgreSQLまたはMySQLを維持する構成がPython Workerの正式な接続経路になりましたが、DjangoやFastAPIアプリケーションの残りすべてが動作すると保証されたわけではありません。

最小構成で安全に接続をテストする

本番環境ではないMySQLデータベースと、権限を絞ったテストユーザーを使います。目的はSELECT 1で接続経路を確認することであり、顧客データを使って完全な移行を予行演習することではありません。

最初のテストでキャッシュされていないデータベースへの往復時間を測れるよう、キャッシュを無効にしたHyperdrive設定を作成します。

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

Wranglerが返す設定IDをwrangler.tomlへコピーします。次の日付は、最低要件の2026-09-08より後です。

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

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

ドライバーをpyproject.tomlへ追加します。

[project]
dependencies = [
    "aiomysql",
]

続いて、Cloudflareが案内している接続テストを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()

案内されているPython Workers用コマンドでデプロイします。

uv run pywrangler deploy

一見すると問題がありそうなのはssl=Noneの行です。Cloudflareのサンプルでは、これはWorkerからHyperdriveへのドライバー接続に対する指定です。Hyperdriveからオリジンデータベースへの接続には引き続きTLSが必要で、安全でない平文のオリジン接続はサポートされません。

ブリッジは不要になる場合があるが、自動的に時代遅れにはならない

今回変わったのは接続経路です。Python Workersが制約のないCPythonサーバーになったわけではありません。

Pythonパッケージは、pure Pythonパッケージ、PyEmscripten wheel、Pyodideに含まれるパッケージを利用できます。CloudflareはWebAssemblyパッケージのサポートを今も初期段階と位置づけているため、必要な依存関係がなければ移行は止まります。ドライバーとORMのドキュメントが現在サポートしているのは同期版SQLAlchemyのみです。Workers環境はgreenletをサポートしないため、非同期SQLAlchemyは利用できません。

データベースプロトコルにも制約があります。HyperdriveはPostgreSQL 9.0から17.x、MySQL 5.7から8.x、およびMariaDBに対応します。SQL ServerとMongoDBには対応しません。PostgreSQLのアドバイザリーロック、LISTEN、NOTIFYは利用できません。MySQLの複文クエリとプロトコルレベルのプリペアドステートメントも対象外です。FreeとPaidの両方で、クエリの最長実行時間は60秒です。

接続プールを導入すると、セッションに関する前提も変わります。Hyperdriveはトランザクションプーリングを採用しており、トランザクション終了時にオリジン接続がプールへ戻ります。トランザクションをまたいでセッション状態が残ることを前提にしたコードは、見直しが必要です。長時間のトランザクションはプールを使い切り、並行処理の利点を失わせる可能性もあります。

月曜日に着手すること

月曜日にアプリケーションを移行するのではありません。データベース接続だけを担うブリッジが本当に必要か、まず確かめます。

ブリッジの役割がデータベース接続だけで、アプリがPostgreSQLまたはMySQLを使い、テスト済みドライバーが対象ルートに対応するなら、今週中に動き始める価値があります。非同期SQLAlchemy、利用できないパッケージ、未対応のSQL動作、または切り分けられていない厳密な書き込み後読み取り整合性に依存するなら待つべきです。アプリを現在のサーバーで運用し続ける場合や、Hyperdriveでは置き換えられないビジネスロジックをブリッジが担っている場合は、今回の変更による影響はありません。

次のプラットフォーム変更も月曜日の判断に落とし込んで受け取りたい方は、ニュースレターに登録してください。