Hyperdriveは、WorkersがPostgreSQLデータベース（ベクトル検索用のpgvector拡張機能を使用しているものを含む）と直接通信できるようにする、マネージドなコネクションプーリングサービスです。サーバーの近くに再利用可能なデータベース接続セットを保持することで、Hyperdriveは、長らくエッジAIのワークロードを妨げてきたハンドシェイクのオーバーヘッドを削減します。
なぜWorkersとPostgreSQLは相性が悪いのか
Cloudflare Workersは、数十のエッジロケーションで短寿命のJavaScript関数として実行されます。リクエストが来るたびに新しいプロセスが開始され、通常のパターンではバックエンドのデータベースに対して新しいTCP接続を開きます。しかし、PostgreSQLはクライアントプロセスごとに安定した接続を必要とし、同時接続の総数に制限があります。その結果、2つの問題が発生します。
- 高い接続コスト – 接続の確立には、認証やプロトコルのネゴシエーションのために、複数回のラウンドトリップが必要です。これらのラウンドトリップは、すべてのリクエストにレイテンシを加算します。
- 接続制限 – Workersは数千の同時実行までスケールできるため、PostgreSQLのコネクションプールをすぐに使い果たし、データベースをクラッシュさせる可能性があります。
Hyperdriveがどのようにそのギャップを埋めるか
HyperdriveはWorkerとデータベースの間に位置し、PostgreSQLインスタンスのネットワーク的に近いサーバー上で、永続的な接続のプールを維持します。Worker側から見た唯一の変化は、新しい接続文字列（connection string）になるだけです。内部的には、プロキシが各インカミングクエリに対して既存の接続を再利用するため、ハンドシェイクのコストが排除されます。
セットアップは意図的に軽量化されています：
- Wrangler CLI（Cloudflareのコマンドラインツール）を実行して、元のデータベースURLを指定し、Hyperdriveインスタンスを作成します。
- 生成されたHyperdriveバインディングを
wrangler.toml設定ファイルに追加します。 - Workerのコード内で
node-postgresのような互換性のあるドライバーを使用します。ドライバーからは、Hyperdriveのエンドポイントは通常のPostgreSQLサーバーとして見えます。
データベースのパスワードはHyperdriveの設定内にのみ存在するため、Workerのソースコードに現れることがなく、攻撃対象領域（attack surface）を削減できます。
ベクトル検索のための実践的なヒント
pgvectorを使用したベクトル検索のワークロードでは、クエリごとに変化しやすい大きな浮動小数点配列を扱います。Hyperdriveのデフォルトの動作にはリードキャッシュが含まれていますが、これは絶えず変化するデータと衝突する可能性があります。結果を最新に保つには、キャッシュを無効にした2つ目のHyperdrive設定を用意してください。
長時間のトランザクションも別の落とし穴です。外部のAIモデルのレスポンスを待っている間にデータベース接続を保持し続けると、プールのスロットを占有してしまい、プーリングの目的が果たせなくなります。推奨されるパターンは以下の通りです：
- トランザクションを開く。
- クエリを実行する。
- すぐにコミットする。
- トランザクションの外でAIモデルを呼び出す。
pgvectorのパラメータ（例えば、検索精度を制御する hnsw.ef_search 設定など）の微調整は、短いトランザクション内で SET LOCAL 文を使用して行うことができます。これにより、変更が現在のクエリにのみ適用され、プールを共有している他のWorkersに影響を与えないことが保証されます。
残る制限事項
Hyperdriveはデータベース自体を移動させるわけではありません。PostgreSQLサーバーが遠く離れたクラウドリージョンにある場合、レイテンシは依然としてその物理的な距離によって制限されます。Cloudflareの「Smart Placement」機能は、Hyperdriveインスタンスも存在する最も近いエッジノードにWorkersをルーティングすることで役立ちますが、根本的なネットワークのラウンドトリップを排除することはできません。
キャッシュレイヤーは静的な読み取りには有用ですが、リクエストごとに変化するベクトルデータでは頻繁にキャッシュミスが発生します。開発者は、キャッシュヒット率と検索結果の鮮度の間のトレードオフを検討する必要があります。
代替案を選ぶべき時
リレーショナルな結合（join）を必要とせず、純粋なベクトルストレージのみが必要なアプリケーションの場合、CloudflareはVectorizeという専用サービスを提供しています。Vectorizeはエッジで直接ベクトルを保存するため、PostgreSQLバックエンドの必要性がなくなります。一方で、ユーザープロファイルや取引履歴などの既存のリレーショナルテーブルとベクトルを結合する必要がある場合は、Hyperdriveの方が優れた選択肢となります。
まとめ
Hyperdriveは、PostgreSQLの接続制限を使い果たすことなく、AI駆動のベクトル検索を実行するための実用的なツールをエッジ開発者に提供します。ハンドシェイクのレイテンシを削減し、認証情報を一元化し、キャッシュやトランザクションの長さを細かく制御できます。このサービスは、エッジとデータベースの間の根本的な距離を消し去るものではなく、キャッシュミスも引き続き懸念事項として残りますが、リレーショナルな結合とベクトル類似性の両方を必要とするワークロードにとって、Hyperdriveはスケーラブルで低レイテンシなエッジスタックへの最も直接的な道です。