Cloudflare D1 2026 - Read ReplicationとTime Travelの使い分け

中級 | 7分 で読める | 2026.04.23

公式ドキュメント

Cloudflare D1とは

記事情報: 2026年4月23日初出。本文の仕様・提供状況は2026年7月25日に公式資料で再確認しています。

Cloudflare D1は、Cloudflare Workersから利用できるサーバーレスSQLデータベースです。SQLとデータモデルはSQLiteを基盤としており、Workerへ設定したbindingを通してクエリを実行します。

2026年にD1を検討するときの重要な機能は、読み取り用の複製を利用するGlobal Read Replication、読み取りの整合性を扱うSessions API、過去の状態へ戻すTime Travelです。Global Read Replicationは2026年7月25日時点でBetaとして提供されています。

この記事では、効果を固定の割合で断定せず、それぞれが何を解決する機能なのかを整理します。

D1では書き込みをprimaryで処理してreplicaへ非同期反映し、Sessions APIで同じ論理Session内の順序を保つRead Replicationと、既存DBを過去時点へ上書き復元するTime Travelの違いを示す図

D1の基本構成

D1では、書き込みを処理するprimary database instanceがデータの基準になります。通常の読み取りもprimaryで処理できます。

Read Replicationを有効にすると、複数の地域に読み取り専用のreplicaが作られます。利用者に近いreplicaへ読み取りを振り分けることで、ネットワーク距離を短くし、読み取り負荷を分散できる可能性があります。

ただし、次の点は変わりません。

  • 書き込みはprimaryへ送られる
  • replicaへの反映は非同期
  • 読み取り中心の処理で効果を得やすい
  • 実際の遅延はprimaryの位置、利用者の場所、SQL、インデックスで変わる

「エッジでSQLiteが完全に分散書き込みされる」という仕組みではありません。

D1を作成してWorkerへ接続する

Cloudflare公式のGetting startedでは、Wranglerを使ってD1を作成します。

npx wrangler@latest d1 create app-db

作成後、表示されたdatabase IDをWorkerの設定へ追加します。wrangler.jsoncを使う例です。

{
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "app-db",
      "database_id": "YOUR_DATABASE_ID"
    }
  ]
}

Workerではenv.DBからbindingへアクセスします。

interface Env {
  DB: D1Database;
}

export default {
  async fetch(_request: Request, env: Env): Promise<Response> {
    const result = await env.DB
      .prepare("SELECT id, title FROM posts ORDER BY id DESC LIMIT ?")
      .bind(10)
      .all();

    return Response.json(result.results);
  },
};

値は文字列連結せず、bind()で渡します。検索条件に使う列には、実行計画を確認したうえでインデックスを設定します。

Global Read Replication

注意: Global Read Replicationは2026年7月25日時点でBetaです。本番利用前に、最新の提供status、制約、障害時の切り戻し手順を確認してください。

Read Replicationはデータベース単位で有効化できます。2026年4月28日更新の公式ドキュメントでは、DashboardのD1設定から有効化する方法と、REST APIでread_replication.modeautoにする方法が案内されています。

重要なのは、有効化するだけではreplicaへクエリが振り分けられない点です。アプリケーション側でSessions APIを使います。

const session = env.DB.withSession();

const result = await session
  .prepare("SELECT id, title FROM posts ORDER BY id DESC LIMIT ?")
  .bind(10)
  .all();

引数なしのwithSession()は、最初のクエリをprimaryまたはreplicaで処理できます。最初に最新のprimaryを読む必要がある場合は、first-primaryを指定します。

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

Read Replicationは、書き込み直後に古いデータが見える問題を無視してよい仕組みではありません。Sessions APIはbookmarkを使い、同じ論理セッション内でsequential consistencyを保ちます。

bookmarkを引き継ぐ

複数のHTTPリクエストを同じ論理セッションとして扱う場合、前回のbookmarkをCookieやヘッダーなどで引き継げます。

const previous = request.headers.get("x-d1-bookmark");
const session = env.DB.withSession(previous ?? "first-unconstrained");

const result = await session
  .prepare("SELECT id, title FROM posts ORDER BY id DESC LIMIT ?")
  .bind(10)
  .all();

const response = Response.json(result.results);
const bookmark = session.getBookmark();

if (bookmark) {
  response.headers.set("x-d1-bookmark", bookmark);
}

return response;

bookmarkの保管場所を決めるときは、利用者間で値を混同しないこと、ヘッダーやCookieのサイズ、キャッシュとの関係も確認します。

Time Travel

Time Travelは、D1を過去の時点へ復元する機能です。production storage backendのデータベースでは自動的に有効になり、手動でバックアップを開始する必要はありません。

保持期間はプランによって異なります。2026年4月21日更新の公式Limitsでは、Workers Paidが30日、Freeが7日です。上限は変更される可能性があるため、運用前に公式ページを確認してください。

復元可能な時点を確認します。

npx wrangler d1 time-travel info app-db \
  --timestamp="2026-04-20T10:00:00Z"

復元は既存データベースを上書きする破壊的操作です。

npx wrangler d1 time-travel restore app-db \
  --timestamp="2026-04-20T10:00:00Z"

実行中のクエリは中断されます。復元前に対象DB、時刻、タイムゾーン、影響範囲を確認し、必要ならエクスポートも取得します。

Time Travelは長期保管用のバックアップと同じではありません。保持期間を超えて保存する必要がある場合は、公式ドキュメントで案内されているエクスポート方法を検討します。

制約を確認する

D1は用途を問わず従来型データベースを置き換えるものではありません。

公式Limitsでは、1データベースの最大サイズ、クエリごとの制約、1回のWorker呼び出しで実行できるクエリ数などが定められています。上限はFreeとPaidでも異なります。

採用前には次を確認してください。

  • 書き込みがprimaryへ集中しても要件を満たせるか
  • データサイズが上限内か
  • 読み取りと書き込みの割合
  • 必要なSQLite機能がD1で利用できるか
  • トランザクションと整合性の要件
  • Cloudflare Workers以外からのアクセス方法
  • 行読み取り数・書き込み数に基づく料金

料金表を記事内の固定値だけで判断せず、導入時点の公式PricingとDashboardの利用量を確認します。

どの用途に向いているか

D1は、Cloudflare Workers上のAPI、ブログやCMSのメタデータ、小〜中規模のWebアプリなど、WorkersとSQLを近い場所で組み合わせたい用途で検討できます。

大量の書き込みを複数地域で同時処理したい場合、非常に大きなデータベース、SQLiteと異なる機能を強く必要とする場合は、別のデータベースも比較してください。

Read Replicationの効果は、Dashboardの地域別metricsと、D1Resultのserved_by_regionserved_by_primaryで確認できます。導入前後を同じ条件で測定することが重要です。

まとめ

  • D1はWorkersから利用するSQLiteベースのサーバーレスSQLデータベース
  • Read Replicationは読み取り専用replicaを利用する機能
  • replicaを使うにはSessions APIが必要
  • 書き込みはprimaryで処理され、replicaへの反映は非同期
  • Time Travelは便利だが、復元は破壊的操作
  • 性能・料金・制約は自分のクエリと公式の最新情報で確認する

参考リソース

← 一覧に戻る
PR
PR
PR
PR