Hyperdriveが『エッジ×既存DB』の遅さを解消する
Cloudflare Workersから既存PostgreSQL/MySQLに接続すると、Workers環境はステートレスのため毎回新規接続が必要・接続時間がボトルネックという課題がありました。Cloudflare Hyperdriveはこの課題を解消するサービスで、エッジでの接続プール・クエリキャッシュにより、既存DBへの接続のたびに発生する待ち時間を減らします。Neon・Supabase・AWS RDS・Google Cloud SQL等の既存DBそのままで、エッジ実行のメリットを享受できます。
採用すべき5つのシグナル
- Cloudflare Workersから既存PostgreSQL/MySQLに接続している
- 既存DBを移行せず、エッジ実行に移行したい
- Neon/Supabase等のサーバーレスDBの接続レイテンシが課題
- 読み込み中心のクエリでキャッシュ効果が期待できる
- Workers→D1への完全移行は段階的に進めたい
従来の問題と解決
問題: WorkersはステートレスなのでDBコネクションを保持できない。毎回TCP接続+TLSハンドシェイク+認証の往復が発生し、DBが遠いほど遅延が大きくなる。
従来の対策: PgBouncer等の接続プールを別途運用・複雑化。
Hyperdrive: Cloudflareが接続プールを各リージョンで管理。Workersは『プロキシ経由で既に確立した接続』を利用し、毎回の接続確立の往復を省く。
主要機能
- 接続プーリング: 各リージョンで永続的な接続維持
- クエリキャッシュ: 自動キャッシュで読み込み高速化
- 圧縮: ネットワーク圧縮でデータ転送量削減
- 暗号化: TLS終端をCloudflare側で実施
- 監視: ダッシュボードで性能確認
実装の基本パターン
(1) wrangler hyperdrive createでHyperdrive設定を作成
(2) Workers側のwrangler.tomlで接続情報を環境変数に
(3) コードからは通常のpgクライアント等で接続
(4) クエリキャッシュ: 読み取り専用のクエリは既定で自動キャッシュ(無効にするなら設定時に--caching-disabled)
(5) Drizzle/Prismaとも統合可能
料金(公式・2026年10月21日確認)
| 項目 | Workers Free | Workers Paid |
|---|---|---|
| 使えるか | 使える | 使える |
| データベースへのクエリ数 | 1日10万件まで(UTCの0時にリセット。超えるとエラー) | 無制限 |
| 接続プール・クエリキャッシュ | — | 追加料金なしで含まれる |
| データ転送(Egress) | 課金なし | 課金なし |
※Cloudflare 公式ドキュメント「Hyperdrive Pricing」。キャッシュから返したクエリも、そうでないクエリも同じように1件と数えます。背後のDB(Neon/Supabase/RDS など)の料金は別にかかります。
制限とキャッシュの仕様(公式)
| 項目 | Workers Free | Workers Paid |
|---|---|---|
| 設定できるデータベースの数 | アカウントあたり10 | アカウントあたり25 |
| 1つの設定から元のDBへの最大接続数 | 約20 | 約100 |
| 1つのクエリの最大実行時間 | 60秒 | 60秒 |
| アイドル接続のタイムアウト | 10分 | 10分 |
| キャッシュできる応答の最大サイズ | 50MB | 50MB |
※Cloudflare 公式ドキュメント「Hyperdrive Limits」「Query caching」(2026年10月21日確認)。
キャッシュされるのは読み取り専用のクエリの応答だけで、INSERT や CREATE TABLE のような書き込みはキャッシュされません。NOW() や RANDOM() のように呼ぶたびに結果が変わる関数を使うクエリも対象外です。既定のキャッシュ時間(max_age)は60秒で、最長1時間まで延ばせます。期限切れのあと15秒は古い応答を返しながら裏で更新する(stale_while_revalidate)設定です。最新の値が必要な読み取りだけは、キャッシュを無効にした別の Hyperdrive 設定(バインディング)を用意して使い分ける構成が、公式ドキュメントでも勧められています。
D1 と Hyperdrive を公式の数字で比べる
| 項目 | D1 | Hyperdrive |
|---|---|---|
| データの置き場所 | Cloudflare 上の SQLite | 既存の PostgreSQL / MySQL(Neon・Supabase・RDS など) |
| 無料プランの上限 | 1日に読み取り500万行・書き込み10万行 | 1日10万クエリ |
| 1つのクエリの最大実行時間 | 30秒 | 60秒 |
| データベースの大きさ | 1つ最大10GB(有料プラン) | 元のデータベースの上限に従う |
※Cloudflare 公式ドキュメント(D1 と Hyperdrive の Pricing・Limits、2026年10月21日確認)。
データを Cloudflare に移せるなら D1、既存のデータベースを動かしたくないなら Hyperdrive、という分け方が、公式の制限からもそのまま読み取れます。
本番採用の判断基準
(1) Workers環境を使っている前提
(2) DB を Neon/Supabase 等で運用中
(3) Cloudflare D1への移行が現実的でない(複雑クエリ・PostgreSQL固有機能等)
(4) 読み込み中心ワークロードでキャッシュ効果大
(5) 既存DBは継続維持・段階的にエッジ化
実装で詰まる3つの落とし穴
- キャッシュ無効化: 書き込みとの整合性・TTL設計
- 長時間処理: Hyperdrive 経由のクエリは1つ最大60秒(公式の制限)。重い集計は分割する
- VPCピアリング: プライベートDB接続にはCloudflare Tunnel併用
30日プラン
- 1週目: Hyperdriveセットアップ・既存PostgreSQL接続
- 2週目: Drizzle/Prisma統合・クエリキャッシュ
- 3週目: 性能ベンチマーク・最適化
- 4週目: 本番運用・モニタリング
関連リンク
Cloudflare Workersは Cloudflare Workers深掘り、D1は Cloudflare D1深掘り、Drizzleは Drizzle ORM深掘り を参照してください。
この記事のデータの出典
- Cloudflare 公式ドキュメント「Hyperdrive Pricing」「Hyperdrive Limits」「Query caching」、D1 の「Pricing」「Limits」(2026年10月21日確認)

