Cloudflare Hyperdriveは、きわめて具体的で、まったく華やかさのない問題のために存在しています。200の都市で走っているWorkerが、たった一つの都市に置かれた一つのPostgresデータベースと会話すると、そのデータベースのすぐ隣に座っているサーバーから同じクエリを投げた場合よりも遅くなります。少し遅い、という話ではありません。多くの場合は数倍遅く、しかもその理由は、クエリがどう書かれているかとはまったく関係がありません。
サーバーレスのアプリケーションが重たく感じられたとき、最初に働く直感は、クエリプランナーのせいにするか、インデックスをもう一本足すかのどちらかです。しかしリージョンに置かれたデータベースと会話するWorkersでは、クエリそのものはたいてい何の問題もありません。問題なのは接続のほうです。
Hyperdriveが実際に直しているもの: データベース接続を確立するためのコストであり、しかもそれはリクエストのたびに毎回支払わされるコストです。Postgresの接続では、一行のデータが動き出す前に、TCPのハンドシェイク、TLSのネゴシエーション、そして認証のやり取りが必要になります。そしてそのひとつひとつが、Workerが目を覚ました場所からデータベースが暮らしている場所までの往復です。Hyperdriveはあなたのデータベースの近くに温まった接続を保持し、それらをプールにまとめておきます。おかげでWorkerは、新しい接続を一から組み立てるのではなく、すでに開いている接続を借りるだけで済みます。
Postgresに直接つながったWorkerがなぜ遅いのか
従来型のアプリケーションサーバーは、起動時に一度だけ接続のプールを開き、そのプロセスが生きているあいだずっと使い回します。ハンドシェイクのコストは立ち上がりの瞬間に支払われ、その後は誰かがサービスを再起動するまで、何百万件ものリクエストのあいだに薄く広がっていきます。
Workersはそのようには動きません。ひとつひとつの実行は寿命が短く、Cloudflareのどの拠点で走るかも分かりません。プールを抱え続ける長寿命のプロセスが存在しないため、何の手当てもしなければ、すべてのリクエストが接続確立のコストを丸ごと支払うことになります。しかもそのコストは、エッジからあなたのオリジンのデータベースまでの距離ぶんだけかかります。
最初の1バイトのデータが届く前に往復が三回というのは、チューニングで解決する種類の問題ではありません。ロンドンのPostgresと会話しているWorkerに、シドニーの利用者がアクセスしたとしましょう。その利用者は同じレイテンシを四回支払います。まずTCP、次にTLS、続いて認証、そして最後にようやくクエリです。肝心のクエリそのものは、2ミリ秒で終わってしまうかもしれません。
もうひとつ、もっと静かに進行する故障もあります。Postgresは接続ごとにバックエンドプロセスをひとつ割り当てますが、その最大値は有限で、通常はせいぜい数百です。同時実行が数千件まで伸びるWorkerは、そのプールを使い果たし、接続拒否を拾い始めます。しかもそれが起きるのは、まさにあなたがエッジを導入した目的であるトラフィックのピークのときです。
Hyperdriveはそれに対して何をするのか
Hyperdriveは、Cloudflareがあなたに代わって運用するコネクションプーラーとして、Workerとデータベースのあいだに座ります。オリジンに向けた温まった接続を維持しているので、ひとつの実行は新しい接続をゼロから交渉するのではなく、既存の接続をひとつ借りるだけで済みます。
さらにクエリ結果のキャッシュも行います。繰り返される読み取りクエリは、オリジンにまったく触れることなく応答できます。これは、無視できない割合のトラフィックにおいて、レイテンシの問題をキャッシュヒット率の問題へと作り変えるということです。書き込みや、結果が一定にならない処理はそのまま素通りしてオリジンへ届きます。
設定と呼べるものは接続文字列ひとつだけです。データベースをCloudflareに登録し、Hyperdriveのバインディングを受け取り、既存のPostgresドライバーの向き先をデータベースではなくそのバインディングに変えます。ドライバーもSQLもスキーマも変わりません。これは聞こえる以上に重要です。変更が可逆であり、何ひとつ書き直すことなく、直接接続と比べて計測できるという意味だからです。
適合するかどうかを決める数字
2026年8月時点でCloudflareの公式ドキュメントと突き合わせて確認した値です。これらの数字は動くものなので、採用を決める前にもう一度確かめることをおすすめします。
| Workers Free | Workers Paid | |
|---|---|---|
| 費用 | 追加なし | 追加なし |
| クエリ | 1日あたり100,000件 | 無制限 |
| 設定できるデータベース | アカウントあたり10個 | アカウントあたり25個 |
| 設定あたりのオリジン接続 | およそ20 | およそ100 |
| クエリの最大実行時間 | 60秒 | 60秒 |
| キャッシュされる応答サイズ | 50 MB | 50 MB |
Hyperdriveはどちらのプランでも追加料金がかからず 、エグレス料金も発生しません。何をもってクエリとみなすかの定義は広く、select、insert、update、delete、そしてスキーマ変更はいずれも一件として数えられます。キャッシュから返されたクエリも、キャッシュされていないクエリとまったく同じように数えられます。無料枠の1日の割り当てはUTCの深夜零時にリセットされます。
制限に関するドキュメント には、初回接続のタイムアウトが15秒、アイドルタイムアウトが10分と記載されています。クエリあたり60秒という上限は、レポーティングのワークロードを移そうとしているチームがつまずくところです。cronジョブで2分かかっていた分析クエリは、ここでは単純に失敗します。
実際に動くデータベースはどれか
HyperdriveはPostgreSQLの9.0から17.x、MySQLの5.7から8.x まで、自前で運用しているものでもマネージドのものでもサポートします。MariaDBはMySQL互換の枠内で扱われます。
名前を挙げて示されているマネージドの提供元には、Postgres互換とMySQL互換の両形態のAWS Aurora、そしてNeon、Supabase、Timescale、Materialize、CockroachDB、PlanetScaleが含まれます。AzureやGoogle Cloud上のマネージドインスタンスも問題なく動きます。
実務上の制約はエンジンの種類ではなく、到達できるかどうかです。あなたのデータベースは、Cloudflareのネットワークからアドレス指定できる必要があります。公開エンドポイントを持たないプライベートなVPCの中に封じ込められたPostgresインスタンスは、Hyperdriveがそれを見ることすらできる状態にするために、トンネルかピアリングの取り決めを必要とします。そしてそれは設定変更ではなく、ネットワークの構築案件です。
Cloudflare Hyperdriveが答えにならない場面
データがエッジにあるべき場合。 アクセスパターンがキーと値の参照であるなら、Workers KVのほうが速く、しかも単純です。ひとつのリージョンではなくWorkerの近くで暮らす小さなリレーショナルデータベースが欲しいのなら、そのために設計された製品はD1です。Hyperdriveは、すでにPostgresやMySQLを持っていて、これからも使い続けるつもりだという場合のためのものです。
ワークロードが分析系である場合。 60秒という上限と、クエリ単位で数える課金の考え方は、トランザクション寄りのトラフィックに向いています。長い集計処理は、データベースと直接会話するジョブランナーの担当です。
まだ計測していない場合。 私たちが最もよく目にする失敗は、そもそも接続がボトルネックではなかったアプリケーションに、チームがHyperdriveを足してしまうというものです。一度で済むところを六回の逐次クエリで処理しているせいでWorkerが遅いのなら、その六本の接続をプールしたところで、ほんのわずかに遅さが減るだけで、本当の問題は手つかずのまま残ります。
その計測は、ほかの何よりも先に、きちんとやっておく価値があります。私たちがまとめたCloudflare WorkersとAWS Lambdaの比較 では、エッジ実行が本当に勝てる領域を扱っています。またCloudflare D1 の記事では、そこへ至る経路を速くするよりも、データベースそのものを動かしたほうがよいケースを扱っています。
判断を正しく下すために
データベースから遠く離れた場所から、直接接続でリクエストひとつを端から端まで計測し、続いてHyperdrive経由でもう一度計測してください。差が小さければ、あなたのレイテンシは別のどこかに住んでいるということであり、依存関係をひとつ増やさずに済んだことになります。差が大きければ、本物のお金を見つけたということです。
Mecanikはソフトウェア開発 チームを通じて、エッジのアーキテクチャを設計し、レビューしています。そこには、何かを作り直す前に、実際に何が遅いのかを誰かが計測するという、まったく華やかさのない工程も含まれます。あなたのサーバーレスアプリケーションが、置き換えたはずのサーバーより遅いのであれば、まず見るべき場所は接続の経路です。
あわせて読みたい: Cloudflare Workers APIの構築：サーバーレス入門2026 、Cloudflare Queues：エッジでのバックグラウンドジョブ 、LLMのレイテンシを削減する方法：キャッシュとエッジ戦略 、そして2026年にウェブアプリを構築する方法 。
よくある質問
Cloudflare Hyperdriveはどんな問題を解決しますか？ リクエストのたびにデータベース接続を開くコストです。Workerは寿命が短く、接続プールを抱えていません。そのためHyperdriveがなければ、実行のたびに、エッジからあなたのデータベースまでの距離ぶんだけTCPのハンドシェイク、TLSのネゴシエーション、認証のやり取りを支払ってから、ようやくデータが動き始めます。Hyperdriveはオリジンの近くにプールされた温かい接続を保持しておき、Workerはそこから一本借りるだけで済みます。
Cloudflare Hyperdriveの料金はいくらですか？ Workersのプラン以外に費用はかかりません。無料プランでも有料プランでも含まれており、別料金もエグレス料金もありません。無料プランは1日あたり100,000件のデータベースクエリを許可し、UTCの深夜零時にリセットされます。有料プランは無制限です。select、insert、update、delete、スキーマ変更はいずれもクエリとして数えられ、キャッシュから返されたクエリもキャッシュされていないクエリと同じように数えられます。
Hyperdriveはどのデータベースに対応していますか？ PostgreSQLの9.0から17.x、MySQLの5.7から8.xまでで、自前運用でもマネージドでも対応し、MariaDBはMySQL互換の枠内で扱われます。名前が挙がっている提供元にはAWS Aurora、Neon、Supabase、Timescale、Materialize、CockroachDB、PlanetScaleがあり、AzureやGoogle Cloud上のマネージドインスタンスも含まれます。データベースはCloudflareのネットワークから到達できる必要があります。
Hyperdriveの主な制限は何ですか？ 無料プランではアカウントあたり10個、有料プランでは25個の設定済みデータベース、設定あたりのオリジン接続は無料でおよそ20、有料でおよそ100、クエリの最大実行時間は60秒、キャッシュされる応答サイズは50 MB、初回接続のタイムアウトは15秒、アイドルタイムアウトは10分です。クエリあたり60秒という上限が、分析系のワークロードを阻む要因になります。
HyperdriveとD1のどちらを使うべきですか？ これからも使い続けるつもりのPostgresやMySQLのデータベースがすでにあり、問題がそこへ到達するまでのレイテンシであるならHyperdriveです。そもそもCloudflareのネットワーク上で暮らすリレーショナルデータベースが欲しいのならD1です。両者が解いている問題は別物で、一方は既存のデータベースへの経路を速くし、もう一方はデータそのものを動かして距離をなくします。
コメント