D1とは？サーバーレスSQLiteデータベース

《 Cloudflare完全ガイド 目次へ 》

前ページのKVは「キーを指定して値を取り出す」だけの仕組みでした。速い代わりに、「今月登録した利用者を一覧する」「注文と商品を突き合わせて売上を集計する」といった問い合わせはできません。

こうした問い合わせを担うのがデータベースです。CloudflareがWorkers向けに用意しているデータベースがD1で、広く使われているSQLiteをもとにしています。サーバーを立てず、使った分だけ支払う形で、本格的なSQLをエッジから利用できます。

このページで分かること

• リレーショナルデータベースとSQLとは何か
• D1の仕組みと、Workersからの使い方
• 読み取りレプリカによる高速化（公開ベータ）
• 「読んだ行数」で決まる料金と、インデックスがなぜ重要なのか
• 無料枠・制限と、向いている用途

リレーショナルデータベースとSQL

リレーショナルデータベースは、データを表（テーブル）の形で管理する仕組みです。表には列（カラム）が定義され、1件のデータが1行（レコード）として入ります。

この表を操作するための言語がSQLです。たとえば次のように書きます。

SELECT name, email FROM users WHERE created_at >= '2026-08-01';

「usersという表から、created_atが8月1日以降の行の、nameとemailを取り出す」という意味になります。複数の表を突き合わせる（JOIN）、件数を数える（COUNT）、平均を出す（AVG）といった処理も、すべてSQLで表現できます。

KVでは不可能だったこの「条件で絞り込む・集計する」がデータベースの本質であり、D1が提供するものです。

D1の仕組み

D1はSQLiteというデータベースエンジンをもとにしています。SQLiteは1つのファイルにデータベース全体が収まる軽量な仕組みで、スマートフォンのアプリやブラウザの内部でも広く使われている、実績のある技術です。

D1は、そのSQLiteをCloudflareが運用する形にしたものです。利用者はサーバーの構築も、バージョンアップも、バックアップの設定も行いません。データベースを作り、Workerに結び付けて、SQLを書くだけです。

使い始めの流れは次のとおりです。

1. wrangler d1 create my-db でデータベースを作る
2. 設定ファイルでWorkerに結び付ける（バインディング）
3. マイグレーション（表を作るSQL）を実行する
4. Workerのコードから env.DB.prepare("SELECT ...").bind(値).all() のように問い合わせる

値を bind() で渡すのは、SQLインジェクション（第2章のWAFで触れた攻撃）を防ぐためです。SQL文の中に利用者の入力を直接つなげてはいけません。

読み取りレプリカ

D1のデータベースにはプライマリ（正本）が1つあり、書き込みはすべてそこで処理されます。プライマリが東京にあれば、ヨーロッパからの問い合わせは毎回東京まで往復することになります。

これを緩和するのが読み取りレプリカです。Cloudflareが世界の各地域に読み取り専用の複製を自動で用意し、読み取りだけを近くのレプリカが処理します。追加の保存料金や計算料金は掛かりません。

利用するには、SQLをそのまま書くのではなくSessions APIという書き方を使います。これは「この一連の問い合わせは、少なくともここまでの更新が反映された状態で読む」という指定を付ける仕組みで、自分が書いた内容を自分が読むときには必ず新しい値が返るよう保証されます。2026年8月時点では公開ベータとして提供されています。

Sessions APIを使わない場合、すべての問い合わせはプライマリだけで実行されます。つまり、何もしなければ従来どおりの動作です。

料金と「読んだ行数」

D1の料金は、保存量に加えて読んだ行数と書いた行数で決まります。

転送量やリクエスト数に対する課金はありません。

ここで重要なのは、読み取り行数は「返ってきた行数」ではなく「データベースが調べた行数」で数えられるという点です。

10万行の表から WHERE email = '[email protected]' で1件を探す場合を考えます。emailの列にインデックス（索引）がなければ、データベースは10万行すべてを順に確認します。結果は1行でも、読み取り行数は10万行として数えられます。

emailにインデックスを張っておけば、索引をたどって数行を確認するだけで済みます。同じ結果を得るのに、費用も速度も桁違いに変わるということです。

無料プランの1日500万行という枠は、インデックスさえ適切なら十分に余裕があります。逆に、インデックスのない表への検索を繰り返すと、あっという間に使い切ります。D1ではインデックスの設計が、そのまま料金の設計になります。

制限

共通の制限として、1つの問い合わせは最長30秒、1行・1つの値の大きさは2MB、SQL文の長さは10万文字、1つの表の列数は100までです。

Time Travelは、過去の任意の時点の状態にデータベースを戻せる機能です。バックアップの設定をしなくても、有料プランなら30日前までさかのぼれます。誤ってデータを消したときの備えとして覚えておいてください。

なお、D1のデータベースは1つずつ順番に問い合わせを処理します（単一スレッド）。1件あたりの処理が速いほど、こなせる件数が増えるという関係です。1つの巨大なデータベースに集中させるより、用途ごとに分ける設計が向いています。

向いている用途・向かない用途

向いている用途

• 個人サイトや小〜中規模サービスのデータ管理（利用者、記事、商品、注文など）
• 読み取りが中心で、書き込みが比較的少ないアプリケーション
• 管理画面、社内ツール、予約や在庫の一覧表示
• Workersで作るAPIのデータ置き場
• 集計やレポートなど、SQLで表現したい処理

向かない用途

• 10GBを超える大きなデータ（有料プランの1データベース上限）
• 毎秒大量の書き込みが発生する処理（プライマリ1か所で処理するため）
• 画像・動画などのファイル本体（R2に置き、D1にはその場所を記録する）
• 1つのキーを取り出すだけの単純な読み取りが大半を占める用途（KVのほうが速く安い）
• 既存のPostgreSQLやMySQLをそのまま使いたい場合（次ページのHyperdriveの担当）

初心者が注意するポイント

• インデックスを張ってください：料金と速度の両方に直結します。WHERE や JOIN で使う列には必ず検討してください
• SELECT * を避ける：必要な列だけを指定するほうが、扱うデータ量が減ります
• 値は必ず bind() で渡す：SQL文に文字列を直接つなげると、SQLインジェクションの入口になります
• DDLも課金対象です：表の作成や変更（CREATE / ALTER / DROP）も読み書きの行数として数えられます
• 無料プランは1データベース500MBまで：本格運用を見込むなら、早い段階で有料プランを前提に設計してください
• 書いた直後の読み取りに注意：読み取りレプリカを有効にする場合は、Sessions APIを使わないと古い値を読む可能性があります
• Time Travelは無限ではありません：保持期間（無料7日／有料30日）を超えた過去には戻れません

関連サービス

• Workers：D1に問い合わせる実行環境。バインディングでつながる
• Workers KV：単純な読み取りが中心ならこちらが速い（前ページ）
• R2：ファイル本体の保存先。D1にはパスを記録する
• Durable Objects：1か所で強い整合性を保ちたい状態の管理

• Hyperdrive：既存のPostgreSQL / MySQLをWorkersから高速に使う仕組み（次ページ）

• ストレージの使い分け：R2 / KV / D1 / Durable Objects の選び方（第6章のまとめ）

まとめ

• D1は、SQLiteをもとにしたCloudflareのサーバーレスSQLデータベース
• 表・行・列とSQLで、条件検索や集計といったKVでは無理な処理ができる
• 書き込みはプライマリ1か所、読み取りは各地のレプリカに分散できる（Sessions API・公開ベータ）
• 料金は「読んだ行数・書いた行数・保存量」で決まり、無料枠は1日500万行の読み取り
• 読み取り行数は調べた行数で数えられるため、インデックスの設計が費用を左右する
• 1データベース10GBまで。ファイル本体はR2、単純な読み取りはKVと役割を分ける

D1は「Cloudflareの中に新しくデータベースを作る」選択肢でした。しかし現実には、すでに動いているPostgreSQLやMySQLがあり、それをWorkersから使いたい場面も多くあります。次のページでは、そのための仕組み――Hyperdriveを見ていきます。

次に読む

• Hyperdriveとは？既存DBを高速化する仕組み
• Workers KVとは？エッジのKey-Valueストア

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。