前ページのD1は、Cloudflareの中に新しくデータベースを用意する仕組みでした。しかし現実には、すでにPostgreSQLやMySQLで動いているシステムがあり、そのデータをWorkersから使いたい、という場面のほうが多いかもしれません。
ところが、既存のデータベースをWorkersからそのまま使うと、多くの場合とても遅くなります。Hyperdriveは、その遅さの原因を取り除き、既存のデータベースをコードをほとんど変えずに高速化する仕組みです。
このページで分かること
- 既存のデータベースをWorkersから使うと、なぜ遅くなるのか
- Hyperdriveの3つの仕組み（エッジでの接続受け付け・接続プール・クエリキャッシュ）
- 対応しているデータベースと、使い始めの流れ
- キャッシュの注意点（何がキャッシュされないか）
- 料金と制限
なぜ既存のデータベースは遅くなるのか
原因は、データそのものの転送ではなく、接続を確立するまでのやり取りにあります。
データベースに接続するとき、クライアントとサーバーは次の手順を踏みます。
- TCP接続を確立する（往復1回以上）
- TLSで暗号化を確立する（往復1〜2回）
- 利用者名とパスワードで認証する（往復1回以上）
- ようやくクエリを送る（往復1回）
1回の往復が仮に150ミリ秒だとすると、クエリを1つ実行するだけで1秒近く掛かることになります。東京のWorkerから、アメリカにあるデータベースへ接続する場合を思い浮かべてください。
さらにWorkersには固有の事情があります。Workerはリクエストごとに立ち上がり、終われば消えます。通常のサーバーのように「起動時に接続を作って使い回す」ことができないため、リクエストのたびにこの手順を最初からやり直すことになります。
加えて、データベース側にも同時接続数の上限があります。世界中のCloudflare拠点からWorkerが一斉に接続を張れば、上限に達して接続を拒否されることも起こります。
Hyperdriveの3つの仕組み
Hyperdriveは、Workerとデータベースの間に入り、3つの方法でこの問題を解決します。
1. 接続の確立をエッジで受ける
Workerは、遠くのデータベースではなく、すぐ隣にいるHyperdriveに接続します。TCP・TLS・認証のやり取りは同じ拠点の中で完結するため、往復にかかる時間がほぼ無くなります。
2. 接続プールを持つ
Hyperdriveは、データベースの近くの拠点に確立済みの接続をまとめて保持しています（接続プール）。Workerからの要求は、この既存の接続に相乗りする形で処理されるため、毎回の接続確立が不要になります。
同時にこれは、データベース側から見た接続数を一定に保つ働きもします。世界中のWorkerが同時に動いても、データベースが受け取る接続はプールの数に収まります。
3. 読み取りクエリをキャッシュする
Hyperdriveは、読み取り専用のクエリ（SELECT）の結果を既定でキャッシュします。同じクエリが再び来れば、データベースまで行かずにその場で返します。
キャッシュの保持時間は既定で60秒、その後15秒間は「古い値を返しつつ裏で更新する」設定（stale-while-revalidate）になっています。保持時間は最長1時間まで延ばせます。
対応しているデータベース
PostgreSQLとMySQL、およびその互換データベースに対応しています。MySQLへの対応は2026年8月7日に正式提供（GA）となりました。
- PostgreSQL系：Amazon RDS / Aurora、Google Cloud SQL、Azure Database、Neon、Supabase、CockroachDB、Timescale など
- MySQL系：Amazon RDS / Aurora MySQL、Google Cloud SQL for MySQL、Azure Database for MySQL、PlanetScale、MariaDB など
自分で立てたサーバー上のデータベースでも、インターネットから接続できれば利用できます。第3章のCloudflare Tunnelを使えば、データベースをインターネットに公開せずにつなぐこともできます。
使い始めの流れ
npx wrangler hyperdrive create my-db --connection-string="postgres://..."で設定を作る- 設定ファイルでWorkerに結び付ける（バインディング）
- コードでは、これまで使ってきたドライバやORMをそのまま使い、接続文字列だけ
env.HYPERDRIVE.connectionStringに差し替える
コードの書き換えはほとんど必要ありません。これがHyperdriveの大きな利点です。既存のクエリもORMもそのまま動きます。
なお、データベースのドライバはNode.jsの機能を使うため、Workerの設定でNode.js互換を有効にする必要があります（第5章のWorkersで触れた nodejs_compat のことです）。
キャッシュで気をつけること
キャッシュは既定で有効なので、何がキャッシュされないのかを知っておくことが重要です。
- 書き込みはキャッシュされません：INSERT、UPDATE、DELETE、CREATE TABLEなどは必ずデータベースに届きます
- 結果が毎回変わる関数を含むクエリはキャッシュされません：
NOW()、CURRENT_TIMESTAMP、RANDOM()などを使ったクエリが該当します。時刻が必要なら、アプリケーション側で値を計算してパラメータとして渡すことが推奨されています - 50MBを超える結果はキャッシュされません：ただし結果自体はWorkerに返ります
問題は「読み取りだが、常に最新でなければ困る」クエリです。認証や権限の確認、書き込んだ直後の読み取りなどがこれにあたります。この場合、キャッシュを無効にした設定を別に作り、用途によって使い分けます。
npx wrangler hyperdrive create my-db-fresh --caching-disabled
同じデータベースに対して、キャッシュ有効の設定（大量の読み取り用）とキャッシュ無効の設定（正確さが必要な処理用）を並行して持てます。
料金と制限
Hyperdrive自体に追加料金は掛かりません。Workersの無料プランでも利用できます（2026年8月時点）。ただし、接続先のデータベース側の利用料金は当然発生します。
| 項目 | 無料プラン | 有料プラン |
|---|---|---|
| 設定できるデータベース数 | 10 | 25 |
| データベース側への接続数（設定ごと） | 約20 | 約100 |
| 1クエリの最長実行時間 | 60秒 | 60秒 |
| キャッシュできる結果の大きさ | 50MB | 50MB |
| 接続確立のタイムアウト | 15秒 | 15秒 |
| 未使用接続の保持時間 | 10分 | 10分 |
Workerからの同時接続数に制限はありません。制限が掛かるのは、Hyperdriveからデータベースへ向かう側です。
向いている用途・向かない用途
向いている用途
- すでにPostgreSQL / MySQLで動いているシステムのデータを、Workersから使いたい場合
- 既存のアプリケーションをWorkersへ移したいが、データベースは動かせない場合
- 読み取りが多く、数十秒古い結果でも問題ないページ（一覧、商品情報、記事など）
- データベースの同時接続数の上限に悩んでいる場合
向かない用途
- 新規にデータベースを作る場合。特別な理由がなければD1のほうが構成が単純です
- Cloudflareの外から接続できないデータベース（Tunnelを併用すれば可能です）
- 常に最新でなければならない読み取りが大半を占める処理（キャッシュを無効にすれば使えますが、利点は接続の高速化だけになります）
初心者が注意するポイント
- キャッシュは既定で有効です：「更新したのに古い値が出る」場合は、まずキャッシュを疑ってください
- 接続情報はCloudflareに保存されます：データベースの利用者名とパスワードを預けることになるため、Hyperdrive専用の利用者を作り、必要最小限の権限だけを与えることをおすすめします
- Node.js互換の設定を忘れずに：これがないとドライバが動きません
- クエリは60秒で打ち切られます：長時間かかる集計処理には向きません
- データベース自体が速くなるわけではありません：Hyperdriveが減らすのは往復の時間と接続の手間です。遅いクエリはインデックスの設計で直す必要があります
- キャッシュ無効の設定も用意しておく：認証まわりの処理は、必ずキャッシュを通さない経路で行ってください
関連サービス
- Workers：Hyperdrive経由でデータベースに問い合わせる実行環境
- D1：新規に作るならこちら（前ページ）
- Cloudflare Tunnel：データベースを公開せずにHyperdriveから接続する
- Workers KV：クエリ結果をさらに長くキャッシュしたい場合の選択肢
-
Cloudflare CDN：キャッシュという考え方の基礎（第1章）
-
ストレージの使い分け：R2 / KV / D1 / Durable Objects の選び方（第6章のまとめ）
まとめ
- 既存のデータベースをWorkersから使うと遅いのは、リクエストのたびに接続確立の往復が発生するため
- Hyperdriveは、接続の確立をエッジで受け、データベースの近くに接続プールを持ち、読み取り結果をキャッシュする
- PostgreSQLとMySQL（2026年8月にGA）およびその互換データベースに対応する
- 既存のドライバやORMをそのまま使え、接続文字列を差し替えるだけで導入できる
- キャッシュは既定で有効。書き込みや
NOW()を含むクエリはキャッシュされない - Hyperdrive自体は追加料金なしで、無料プランでも使える
これで第6章の個別サービスは一通り揃いました。R2、KV、D1、Hyperdrive、そして第5章のDurable Objects――保存先の選択肢は多く、最初は迷うはずです。次のページでは、それらをどう使い分けるのかを1枚の判断基準としてまとめます。
次に読む
※本記事の情報は 2026年8月時点のものです。