このガイドでは、Cloudflare Workers で使えるストレージおよびデータベース製品と、推奨ユースケース、ベストプラクティスを説明します。
次の表は、ストレージおよびデータベース製品を、一般的な業界用語と推奨ユースケースに対応づけています。
| 用途 | 製品 | 向いている用途 |
|---|---|---|
| Key-value ストレージ | Workers KV | 設定データ、サービスルーティングのメタデータ、パーソナライゼーション（A/B テスト） |
| オブジェクトストレージ / blob ストレージ | R2 | ユーザー向け Web アセット、画像、機械学習とトレーニングデータセット、分析データセット、ログとイベントデータ |
| Postgres または MySQL データベースの高速化 | Hyperdrive | 既存のデータベースドライバーと ORM を使い、クラウドまたはオンプレミスの既存データベースへ接続する場合 |
| グローバルな調整とステートフルなサーバーレス | Durable Objects | 共同作業アプリの構築、クライアント間のグローバルな調整、リアルタイム WebSocket アプリ、強い一貫性のあるトランザクションストレージ |
| 軽量 SQL データベース | D1 | ユーザープロファイル、商品一覧と注文、顧客データなどのリレーショナルデータ |
| タスク処理、バッチ処理、メッセージング | Queues | バックグラウンドジョブ処理（メール、通知、API）、メッセージキュー、遅延タスク |
| ベクトル検索と embeddings クエリ | Vectorize | セマンティック検索と分類タスク向けに、AI モデルの embeddings を保存する場合 |
| ストリーミング取り込み | Pipelines | クリックストリーム分析、テレメトリ / ログデータ、クエリ用の構造化データなど、ストリーミングデータの取り込みと処理 |
| 時系列メトリクス | Analytics Engine | Workers や SQL を使い、高カーディナリティの時系列データ、使用量メトリクス、サービスレベルのテレメトリを書き込み・クエリする場合 |
アプリケーションは、複数のストレージおよびデータベース製品の上に構築できます。たとえば、セッションデータには Workers KV、大きなファイルやメディアアセット、ユーザーアップロードには R2、ホストされた Postgres または MySQL データベースへの接続には Hyperdrive を使います。
Workers でアプリケーションを作るとき、SQL ベースのデータベースには次の 3 つの選択肢があります。
- Hyperdrive — 既存の Postgres または MySQL データベースがある場合、大規模（1 TB、100 TB 以上）の単一データベースが必要な場合、既存のデータベースツールを使いたい場合です。PlanetScale ↗ や Neon ↗ などのデータベースプラットフォームにも Hyperdrive を接続できます。
- D1 — 読み取りが多く、軽量なサーバーレスアプリケーション向けです。グローバルなユーザーが D1 の 読み取りレプリケーション の恩恵を受けられ、従来型 RDBMS の運用・保守が不要な場合に向きます。
- Durable Objects — ステートフルなサーバーレス負荷、ユーザー単位または顧客単位の SQL 状態、分散システムの構築向けです（D1 と Queues は Durable Objects の上に作られています）。Durable Objects の 厳格な直列化可能性（strict serializability） ↗ により、リクエストとストレージ操作のグローバルな順序を保証できます。
セッションデータ、認証情報（API キー）、設定データの保存には Workers KV を推奨します。これらは通常、高いレート（数千 RPS 以上）で読まれ、変更は少なく（KV の一意キーあたり 1 書き込み RPS の上限内）、即時の一貫性は不要です。
頻繁に読まれるキーは KV の 内部キャッシュ の恩恵を受けます。こうした「ホット」キーへの繰り返し読み取りは、通常 500µs〜10ms 程度の遅延です。
OpenAuth ↗ などの認証フレームワークは、Cloudflare にデプロイするとセッションストレージに Workers KV を使います。Cloudflare Access は、ユーザー認証情報を安全に保存・配布するために KV を使い、ユーザーの近くで検証して全体の遅延を下げます。
Workers KV は、Cloudflare のグローバルネットワーク上でキャッシュする、結果整合性のキーバリューデータストアです。
次のようなプロジェクトに向きます。
- 読み取り量が多い、または同じキーへの繰り返し読み取りがある。
- 低遅延のグローバル読み取り（ホットキーでは通常 10ms 以内）。
- オブジェクトごとの TTL（有効期限）。
- 分散設定やセッションストレージ。
KV を始めるには、次を参照してください。
- KV の仕組み を読む。
- KV 名前空間 を作成する。
- KV Runtime API を確認する。
- KV の 制限 を確認する。
R2 は S3 互換の blob ストレージです。一般的なクラウドストレージに付きもののエグレス料金なしで、大量の非構造化データを保存できます。
次のようなプロジェクトに向きます。
- アクセス頻度が低いファイルの保存。
- 大きなオブジェクトの保存（たとえばオブジェクトあたり数 GB 以上）。
- オブジェクト単位の強い一貫性。
- Web サイトのアセット保存（キャッシュガイド を参照）。
R2 を始めるには、次を参照してください。
- 始め方ガイド を読む。
- R2 の 制限 を確認する。
- R2 Workers API を確認する。
Durable Objects は、グローバルな一意性とトランザクションストレージ API により、Workers プラットフォームに低遅延の調整と一貫したストレージを提供します。
-
グローバル一意性（Global Uniqueness）は、ある ID を持つ Durable Object クラスのインスタンスが、世界中で同時に 1 つだけ動くことを保証します。Durable Object ID へのリクエストは、Workers ランタイムがその Durable Object を所有する Cloudflare データセンターへルーティングします。
-
トランザクションストレージ API は、Durable Object に強い一貫性のキーバリューストレージを提供します。各 Object は、その Object に紐づくキーだけを読み書きできます。Durable Object の実行はシングルスレッドですが、複数のリクエストイベントは、Object に到着した順とは異なる順で処理されることがあります。
次のようなプロジェクトに向きます。
- リアルタイム共同作業（チャットアプリやゲームサーバーなど）。
- 一貫したストレージ。
- データの局所性。
Durable Objects を始めるには、次を参照してください。
- 紹介ブログ記事 ↗ を読む。
- Durable Objects ドキュメント を確認する。
- Durable Objects を始める。
- Durable Objects の 制限 を確認する。
D1 は Cloudflare のネイティブなサーバーレスデータベースです。D1 では、データのインポート、またはテーブル定義とクエリの記述を、Worker 内または API 経由で行ってデータベースを作成できます。
D1 は次の用途に向きます。
- ユーザーデータ、アカウントデータ、その他の構造化データセット向けの永続的なリレーショナルストレージ。
- データ全体をアドホックに（SQL で）照会する必要があるユースケース。
- 書き込みに対して読み取りの比率が高いワークロード（ほとんどの Web アプリケーション）。
D1 を始めるには、次を参照してください。
- ドキュメント を読む。
- 始め方ガイド に従って、最初の D1 データベースを用意する。
- D1 Workers Binding API を確認する。
Cloudflare Queues は、配信を保証してメッセージを送受信できる機能です。Cloudflare Workers と統合され、少なくとも 1 回の配信、メッセージのバッチ処理に対応し、エグレス帯域の課金はありません。
Queues は次の用途に向きます。
- リクエストから処理を切り離し、あとで実行する。
- Worker から Worker へデータを送る（サービス間通信）。
- 上流システム（サードパーティ API や Cloudflare R2 を含む）へ書き込む前に、データをバッファまたはバッチする。
Queues を始めるには、次を参照してください。
- 最初のキューを設定する。
- Queues の仕組み を確認する。
Hyperdrive は、MySQL および Postgres データベースへのクエリを高速化するサービスです。ユーザーの所在地に関係なく、世界中からデータへより速くアクセスできます。
Hyperdrive では次のことができます。
- 接続のオーバーヘッドなしで、既存のデータベースに Workers から接続する。
- よく使うクエリを Cloudflare のグローバルネットワーク上でキャッシュし、トラフィックの多いコンテンツの応答時間を短くする。
- コネクションプーリングでオリジンデータベースの負荷を下げる。
Hyperdrive を始めるには、次を参照してください。
- 既存のデータベースに Hyperdrive を接続する。
- Hyperdrive がデータベースクエリを高速化する仕組み を確認する。
Pipelines は、インフラを自分で運用せずに、大量のリアルタイムデータを取り込めるストリーミング取り込みサービスです。
Pipelines では次のことができます。
- 非常に高いスループット（毎秒数万レコード以上）でデータを取り込む。
- データをバッチし、オブジェクトストレージへ直接書き込み、照会できる状態にする。
- （将来）取り込み中にデータを変換・集計する。
Pipelines を始めるには、次を参照してください。
- レコードをバッチして R2 に書き込める Pipeline を作成する。
Analytics Engine は、Cloudflare の時系列およびメトリクス用データベースです。組み込み API で Workers からデータポイントを書き込み、そのデータを SQL で直接照会できます。カーディナリティ無制限の分析を大規模に書けます。
Analytics Engine では次のことができます。
- 自社の顧客向けにカスタム分析を公開する。
- 利用量ベースの課金システムを作る。
- 顧客単位またはユーザー単位でサービスの健全性を把握する。
- 頻繁に呼ばれるコードパスに計測を追加する。性能への影響や、外部分析システムへのイベント過多を避けられる。
Cloudflare は社内でも Analytics Engine を使い、D1 や R2 などの製品メトリクスを大規模に保存しています。
Analytics Engine を始めるには、次を参照してください。
- Analytics Engine の始め方 を確認する。
- Analytics Engine に時系列データを書き込む例 を見る。
- データセットからデータを読む SQL API を理解する。
Vectorize は、グローバルに分散したベクトルデータベースです。Cloudflare Workers と Workers AI で、フルスタックの AI アプリケーションを構築できます。
Vectorize では次のことができます。
- 任意のベクトル埋め込みモデルからの埋め込み（Bring Your Own embeddings）を保存し、セマンティック検索や分類に使う。
- 検索拡張生成（Retrieval Augmented Generation、RAG）ワークフローの一部としてベクトル検索を使い、大規模言語モデル（LLM）のクエリに文脈を足す。
- ベクトルメタデータで絞り込む ことで検索空間を狭め、より関連の高い結果を返す。
Vectorize を始めるには、次を参照してください。
- 最初のベクトルデータベースを作成する。
- Workers AI と Vectorize を組み合わせて、テキスト埋め込みを生成、保存、照会する。
- ベクトルデータベースの仕組み を確認する。
Cloudflare Workers には、SQLite をバックエンドにしたサーバーレスデータベース製品 D1 があります。Durable Objects の SQLite と D1 をどう比較すればよいでしょうか。
D1 はマネージドなデータベース製品です。
D1 は、アプリケーションサーバーがネットワーク経由でデータベースと通信する、開発者にとってなじみのある構成に合います。アプリケーションサーバーは通常 Workers です。ただし D1 は HTTP API ↗ による外部（Worker 以外）からのアクセスにも対応しており、D1 向けの サードパーティツール の利用につながります。
D1 は必要な機能が最初から揃った機能セットを目指しています。上記の HTTP API、データベーススキーマ管理、データのインポート / エクスポート、データベースクエリインサイト が含まれます。
D1 ではアプリケーションコードと SQL データベースのクエリが同じ場所にないため、アプリケーションの性能に影響することがあります。D1 で性能が気になる場合、Workers の Smart Placement を使うと、D1 を含む Worker が通信するすべての対象を考慮し、Worker リクエスト全体のレイテンシが小さくなる場所で Worker を動的に実行できます。
Durable Objects の SQLite は、分散システム向けの、より低レベルのコンピュートとストレージの構成要素です。
設計上、Durable Objects へのアクセスは Workers からのみです。
Durable Objects は手間が増えますが、そのぶん柔軟性と制御が得られます。Durable Objects では、別の場所で動く 2 つのコードを実装する必要があります。インターネットからの受信リクエストを一意の Durable Object へルーティングするフロントエンド Worker と、SQLite データベースと同じマシンで動く Durable Object 本体です。どこで何を動かすかを選べます。アプリケーションのビジネスロジックの一部をデータベースのすぐ隣で動かすと、利点がある場合もあります。
Durable Objects の SQLite では、D1 に最初から付いているデータベースツールの一部を、自分で作る必要があることもあります。
SQL クエリの料金と制限は、D1（料金、制限）と Durable Objects の SQLite（料金、制限）で同じになる想定です。