Cloudflare D1 実践：SQLite エッジ DB とグローバル読み取りレプリケーション

0.01 ミリ秒。

これが SQLite でローカルから 1 行を読む時間です。同じクエリを Cloudflare D1 で実行すると約 0.5 ミリ秒。PostgreSQL をリージョン跨ぎで叩くと 1〜3 ミリ秒——差は小さく見えます。でもユーザーが東京にいて DB がバージニアにあるなら、ネットワーク往復だけで 100 ミリ秒以上を食います。

昨年、グローバル展開のプロジェクトでこの壁にぶつかりました。従来 DB なら高遅延を我慢するか、複雑な読み書き分離を組むか。Cloudflare が 2025 Developer Week で D1 のグローバルレプリケーションを出したとき、話が変わり始めました。

この記事では、D1 がどう SQLite をエッジに載せているか、Durable Objects や Lamport タイムスタンプ、Sessions API といった概念が実際どう使えるか、そして選ぶべき場面と避けるべき場面を整理します。

一、D1 とは：エッジで動く SQLite データベース

一言でいうと、D1 は Cloudflare が SQLite をエッジネットワーク上に載せ、世界 300 都市以上のノードで読み書きできるようにした DB です。

「SQLite + CDN」程度の話だと思うと、設計の野心を見落としがちです。従来の SQLite には本番運用の障壁があります。単一ファイルで分散しにくい、組み込みの障害復旧が弱い、書き込みで DB 全体がロックされる——D1 はこれらを踏まえて作り直されています。

従来の SQLite との違い

まず統合の仕方。D1 は Cloudflare Workers 上で直接動き、普通の関数のように DB を操作できます：

// wrangler.toml
[[d1_databases]]
binding = "DB"
database_name = "my-database"
database_id = "xxxx-xxxx-xxxx"

// Worker 内でクエリ
export default {
  async fetch(request, env) {
    const { results } = await env.DB.prepare(
      "SELECT * FROM users WHERE id = ?"
    ).bind(1).all();
    return Response.json(results);
  }
}

次に Time Travel。D1 は DB の履歴バージョンを自動保存し、任意の時点へロールバックできます——SQLite には贅沢な機能です。無料アカウントは 30 日、有料はそれ以上保持可能です。

3 つ目はグローバルレプリケーション（2025 年の大型アップデート）。プライマリは 1 リージョンに置きつつ、読み取りレプリカが世界各地へ同期されます。シンガポールのユーザーはシンガポールのレプリカから読み、遅延は 3 桁ミリ秒から一桁ミリ秒へ。

押さえておくべきハード制限

D1 は万能ではありません。選定前に知っておきたい制約があります：

単一 DB 10GB 上限。超えるなら分割か、別案の検討が必要です。1 アカウント最大 50,000 DB——多くのプロジェクトには十分ですが、「ユーザーごとに 1 DB」モデルなら計算が要ります。

単一ライター構成。同時に書き込めるノードは 1 つだけ。書き込みスループットに上限があり、実測はおおよそ 500〜2000 writes/sec。PostgreSQL の 10K〜50K とは比べられません。リアルタイム入札やログパイプラインのような高頻度書き込みには向きません。

順序一貫性であって、強い一貫性ではない。後述しますが、書いた直後の読み取りで最新が見えないことがあります——Sessions API を正しく使えば解決できます。

率直に言うと、D1 が最も合うのは読み取り中心の Web アプリです。多くのサイトは読み取りが 90% 以上。グローバル読み取りレプリケーションで近傍ノードから応答でき、体験の改善ははっきり出ます。

二、D1 アーキテクチャ：Durable Objects とグローバルレプリケーション

ここはやや硬派ですが、D1 を使いこなすには避けられない話です。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

Durable Objects：各 DB に専属の「執事」

D1 の中核は Durable Objects です。各 DB に専属の「執事プロセス」がいて、次を担当します：

1. グローバル一意性の保証：すべての書き込みがここを通り、同時更新の衝突を防ぐ
2. トランザクションログの維持：各書き込みを記録し、障害復旧とレプリカ同期に使う
3. 読み書きレプリカの調整：世界各地のレプリカへ「更新せよ」と指示する

設計は巧妙です。従来の分散 DB は複数ノード間の調整が必要で、ネットワーク遅延や障害が問題になります。D1 はプライマリを 1 つに決め、書き込みをそこで順番処理し、非同期でレプリカへ同期します。

Snapshot Isolation：読み取りはブロックしない

D1 で SELECT を実行すると、プライマリのキューには並ばず、近傍レプリカの「スナップショット」から読みます。

たとえばプライマリが北京（中国）、レプリカが東京・シンガポール・シドニーにあるとします。東京のユーザーが読み取ると、東京レプリカからその時点の状態が返ります。クエリ開始時点のスナップショットが固定され、同時刻にプライマリが書いていても読み取りはブロックされません。

ただし問題があります。書いた直後に読むと、レプリカ未同期で見えないことがある——だから Sessions API があります。

Lamport タイムスタンプ：順序に意味を持たせる

Leslie Lamport が 1978 年に提唱した分散システムのイベント順序付けが Lamport タイムスタンプです。各イベントに論理時計があり、後続イベントのタイムスタンプは必ず大きくなります。

D1 はこれで「順序一貫性」を保証します。1 セッション内で先に書いてから読むと、書き込み後の最新データが読めるようになります。古いレプリカのまま、ということは避けられます。

仕組みはこうです。書き込み完了のたびに D1 は「しおり」（commit token）を返します。このしおりは「この時点より前の変更はすべて反映済み」という印です。次回クエリでしおりを付けると、少なくともその点以降のデータが見えるよう保証されます。

ユーザー → 注文を書き込み → commit token "abc123" を取得
ユーザー → 注文を照会（token "abc123" 付き）→ 直前の書き込みが見えることを保証

グローバルレプリケーションの実装

D1 DB 作成時に「プライマリリージョン」（primary location）が選ばれます。デフォルトは最寄りの Cloudflare データセンターで、手動指定も可能です。

書き込みフロー：

1. 書き込みリクエストが近傍エッジノードへ到達
2. プライマリリージョンの Durable Object へルーティング
3. プライマリ DB ファイルへ書き込み
4. 非同期で各リージョンのレプリカへ複製

読み取りフロー：

1. 読み取りリクエストが近傍エッジノードへ到達
2. そのリージョンのレプリカから読み取り
3. セッション付き読み取りなら、一貫性のしおりを適用

Cloudflare 公式は、グローバルレプリケーションに追加課金なしと説明しています——データ転送コストは本来小さくないので良心的です。ただし書き込みは依然プライマリへ行き、遅延は物理距離に依存します。プライマリを米国、ユーザーをアジアに置くと、書き込み遅延は目に見えて増えます。

三、Sessions API 実践：順序一貫性のコード

理論はここまで。コードに移ります。

Sessions API は D1 が 2025 年に出した新機能で、「書いた直後に読む」一貫性問題向けです。MongoDB の causal consistency や CockroachDB の follower reads に近い考え方で、因果関係を追跡する印を使います。

基本の使い方

// Session を作成
const session = env.DB.withSession();

// 通常の読み取り。近傍レプリカへルーティング
const { results } = await session.prepare(
  "SELECT * FROM products WHERE category = ?"
).bind("electronics").all();

// 書き込み。自動的にプライマリへルーティング
await session.prepare(
  "INSERT INTO orders (user_id, product_id, quantity) VALUES (?, ?, ?)"
).bind(userId, productId, 2).run();

// 現在 Session の一貫性しおりを取得
const bookmark = session.latestCommitToken;

ポイントは withSession() です。「セッションコンテキスト」を作り、その中の操作は同じ一貫性ビューを共有します。

3 つの一貫性モード

Sessions API には 3 モードがあり、用途に応じて選びます：

1. first-unconstrained（デフォルト）

const session = env.DB.withSession("first-unconstrained");

最も緩いモード。読み取りは近傍レプリカから、そのレプリカが最新かどうかは問いません。商品一覧やブログ表示など、リアルタイム性がそれほど重要でない用途向きです。

2. first-primary

const session = env.DB.withSession("first-primary");

最初の読み取りだけプライマリへ行き、以降はレプリカ。Session 作成時点の最新状態以上が読めることを保証します。「今書いたデータ」を見たいが、毎回プライマリは避けたい場面向きです。

3. しおりで前セッションを継続

// リクエストヘッダーから前回のしおりを取得
const previousToken = request.headers.get("x-d1-token") ?? "first-unconstrained";

// しおり付き Session を作成
const session = env.DB.withSession(previousToken);

// 操作を実行...

// 新しいしおりを返す
response.headers.set("x-d1-token", session.latestCommitToken);

最も強力な使い方です。しおりをクライアント（Cookie やリクエストヘッダー）に保存し、リクエストごとに付ければ、複数リクエストに跨いでも一貫性を保てます。

実践例：EC 注文システム

グローバル EC を想定します。商品閲覧は近傍レプリカから、遅延最小。注文後の確認は、今書いた注文が必ず見える必要があります。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // リクエストヘッダーから session token を取得（初回は null）
    const token = request.headers.get("x-d1-token") ?? "first-unconstrained";
    const session = env.DB.withSession(token);

    // ケース1：商品一覧（強い一貫性は不要）
    if (url.pathname === "/api/products") {
      const { results } = await session.prepare(
        "SELECT * FROM products WHERE status = ?"
      ).bind("active").all();

      return new Response(JSON.stringify(results), {
        headers: {
          "Content-Type": "application/json",
          "x-d1-token": session.latestCommitToken
        }
      });
    }

    // ケース2：注文作成（書き込み。自動的にプライマリへ）
    if (url.pathname === "/api/orders" && request.method === "POST") {
      const body = await request.json();

      await session.prepare(`
        INSERT INTO orders (user_id, total_amount, status)
        VALUES (?, ?, ?)
      `).bind(body.userId, body.total, "pending").run();

      // 書き込み直後に照会し、今書いたデータを確実に取得
      const order = await session.prepare(`
        SELECT * FROM orders WHERE user_id = ?
        ORDER BY created_at DESC LIMIT 1
      `).bind(body.userId).first();

      return new Response(JSON.stringify(order), {
        headers: {
          "Content-Type": "application/json",
          "x-d1-token": session.latestCommitToken  // 新 token を返す
        }
      });
    }

    // ケース3：注文詳細（前回 token で一貫性を確保）
    if (url.pathname.startsWith("/api/orders/")) {
      const orderId = url.pathname.split("/")[3];

      // 直前に注文していれば token が最新データを保証
      const order = await session.prepare(
        "SELECT * FROM orders WHERE id = ?"
      ).bind(orderId).first();

      return new Response(JSON.stringify(order), {
        headers: {
          "Content-Type": "application/json",
          "x-d1-token": session.latestCommitToken
        }
      });
    }
  }
}

実用的な設計です。閲覧は first-unconstrained で性能優先。注文後にクライアントが token を保存し、以降の照会で付与すれば一貫性が保てます。

クライアント側の対応

フロントエンドはシンプルです。x-d1-token を保存し、毎回リクエストに付けます。

// フロントエンド例
let d1Token = localStorage.getItem('d1-token') ?? 'first-unconstrained';

async function fetchProducts() {
  const response = await fetch('/api/products', {
    headers: { 'x-d1-token': d1Token }
  });
  d1Token = response.headers.get('x-d1-token');
  localStorage.setItem('d1-token', d1Token);
  return response.json();
}

async function createOrder(data) {
  const response = await fetch('/api/orders', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'x-d1-token': d1Token
    },
    body: JSON.stringify(data)
  });
  d1Token = response.headers.get('x-d1-token');
  localStorage.setItem('d1-token', d1Token);
  return response.json();
}

コード量は多くありませんが、解く問題は大きいです。この仕組みがないと、注文直後に一覧を見て空になる——体験は最悪です。

四、性能ベンチマークと競合比較

数字は嘘をつきにくいです。主要案の比較を、公式ドキュメントとコミュニティ実測ベースで整理しました。

遅延比較

いくつかの所感：

Turso の読み取り遅延は本当に速い。0.02 ミリ秒は、ほぼローカルメモリアクセス並みです。組み込み SQLite で DB ファイルをエッジノードへ複製し、読み取りを完全ローカル化しているからです。代償としてデータ同期は別途必要で、書き込み遅延はむしろ高くなりがちです。

D1 の読み取り遅延も優秀。0.5 ミリ秒はエッジ DB としてトップクラスです。書き込み遅延の差は目立ちます——書き込みはプライマリへ行くため、物理距離が下限を決めます。プライマリが米西海岸、ユーザーがシンガポールなら、書き込みは太平洋を跨ぎ 30 ミリ秒以上が普通です。

PlanetScale と Neon は従来型アプリ向き。遅延数字は D1/Turso ほど派手ではありませんが、エコシステムと機能の成熟度で勝ります。ストアドプロシージャ、トリガー、豊富なインデックス型が必要ならこちらが適します。

スループット比較

D1 の弱点は書き込みスループットです。単一ライター構成が上限を決めます。秒間 5000 行以上の書き込みが必要なら、ボトルネックになり得ます。DB 分割は複雑度が上がるので、別案の方が現実的なこともあります。

無料枠比較

無料枠だけ見ると D1 はかなり厚いです。月 250 億行の読み取りは個人〜小規模アプリに十分。ただし書き込みは月 5000 万行、1 日平均 166 万行。ログ収集やイベントトラッキングのような高頻度書き込みはすぐ超えやすいです。

課金モデル

D1 は従量課金で最低利用料なし。無料枠超過後、100 万行読み取り $0.001、100 万行書き込み $0.10。ストレージは GB あたり $0.75/月。

Turso は「行読み取り」と「複製トラフィック」の 2 軸があり、更新が多いと複製コストが膨らみ得ます。

PlanetScale は行読み取り・行書き込みベース。書き込み単価は D1 より低く、読み取りはやや高めです。

すでに Cloudflare エコシステム（Workers、KV、R2）を深く使っているなら、D1 の課金統合で請求が見やすくなります。独立プロジェクトなら 3 社試して実データで決めるのが確実です。

五、選定判断ツリー：いつ D1 を選ぶか

ここまで読んで、D1 を選ぶべきか。簡単な判断ツリーを置きます。

D1 が向くシーン

読み取り中心のアプリ。コンテンツサイト、EC（閲覧中心）、ブログ、ドキュメントシステムなど。操作の 90% 以上が読み取りなら、グローバル読み取りレプリケーションで遅延を一桁ミリ秒へ下げられます。

ユーザーが世界各地にいる。単一リージョン DB だと遠方ユーザーは毎回越洋通信。D1 はデータをユーザー近くへ置き、体験改善は即効性があります。

すでに Cloudflare Workers を使っている。D1 との統合はネイティブで、数行の設定で使えます。別途 DB 接続プール不要、コールドスタートも気にしにくく、開発体験は滑らかです。

DB 規模が 10GB 以内。単一 DB 上限は 10GB、超えるなら分割が必要。「テナントごと 1 DB」モデルなら、この制限は問題になりにくいです。

D1 が向かないシーン

高頻度書き込み。リアルタイム入札、ログパイプライン、IoT 収集——秒間数万書き込みは単一ライター構成の限界です。PostgreSQL、ClickHouse、TimescaleDB の方が適します。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

複雑なトランザクション。D1 は SQLite レベルのトランザクションをサポートしますが、SERIALIZABLE 分離、DB 跨ぎトランザクション、複雑なストアドプロシージャが必要なら足りません。

データ量が 10GB 超。分割は可能ですが運用が複雑になります。時系列データやログアーカイブのように最初から巨大なら、最初から別案の方が楽です。

強い一貫性が必須。D1 は結果整合性で、書いた直後に読むと最新が見えないことがあります（Sessions API なら緩和可能）。常に最新が見える必要があるなら別案を検討してください。

PostgreSQL から移行する際の注意

既存 PostgreSQL アプリを D1 へ移すなら、先に押さえたい点：

1. SQL 方言の差

SQLite は PostgreSQL の一部機能を持ちません：

• RETURNING 句なし（挿入後に別クエリで取得）
• SERIAL 型なし（INTEGER PRIMARY KEY AUTOINCREMENT を使用）
• JSONB 型なし（JSON は TEXT + json_extract()）
• ARRAY 型なし（関連テーブルで代替）

2. データ移行ツール

Cloudflare 公式は PostgreSQL から SQL をエクスポートして D1 へインポートするツールを提供しています：

# PostgreSQL データをエクスポート
pg_dump --format=insert mydb > dump.sql

# D1 へインポート
npx wrangler d1 execute my-d1-database --file=dump.sql

複雑なスキーマは手動調整が必要なことが多いです。

3. 接続方式の変化

従来 DB は長接続、D1 はステートレスな関数呼び出しです。ORM の調整が必要になることもあり、素の SQL 直書きも選択肢です。Prisma には D1 アダプターがありますが、機能はまだ発展途上です。

クイック判断

迷ったら、この簡易フローで：

書き込み頻度 > 1000 回/秒？
├─ はい → D1 は見送り
└─ いいえ
    └─ 強い一貫性が必要？
        ├─ はい → D1 は見送り（Sessions API と組み合わせなら可）
        └─ いいえ
            └─ データ量 > 10GB？
                ├─ はい → 慎重に検討
                └─ いいえ → D1 は有力候補

まとめ

D1 の価値は 3 点に集約できます。エッジ配置で遅延を一桁ミリ秒へ、サーバーレスで運用負荷を下げ、Sessions API で分散システムの「書いた直後に読む」問題をシンプルに解く。

すべてのシーンに合うわけではありません。高頻度書き込み、複雑トランザクション、超大規模データ——こうした場合は PostgreSQL や時系列 DB が依然として適します。銀の弾丸はなく、トレードオフの話です。

グローバルユーザー向けで読み取り中心、すでに Cloudflare Workers を使っているなら、D1 は試す価値があります。テスト DB の作成は数分です：

# DB を作成
npx wrangler d1 create my-first-db

# テーブルを作成
npx wrangler d1 execute my-first-db --command="CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)"

# データを挿入
npx wrangler d1 execute my-first-db --command="INSERT INTO users (name) VALUES ('test')"

実際に動かし、東京から米西海岸 DB への遅延差を体感すれば、自分のプロジェクトに合うか判断しやすくなります。

"D1 は Cloudflare の SQLite エッジ DB で、グローバル読み取りレプリケーションとサーバーレス体験を提供します。Sessions API は Lamport タイムスタンプで順序一貫性を実現し、分散システムでよくある書き込み後読み取りの一貫性問題を解決します。"

参考資料

• Building D1: a Global Database — Cloudflare 公式ブログ、2024
• D1 Global Read Replication Beta — Cloudflare 公式ブログ、2025
• D1 Getting Started — Cloudflare 公式ドキュメント
• The SQLite Renaissance — DEV Community、2026
• Database Free Tier Comparison 2026 — Agent Deals