Cloudflare D1 料金ガイド：無料枠でクエリが止まる条件

2026年9月1日、Cloudflare D1 料金は本番環境の可用性を左右する判断事項になりました。1日の利用量が500万行の読み取り、または100,000行の書き込みのどちらかに達すると、D1のクエリはUTCの午前0時まで停止する可能性があります。

Cloudflareが変えたのはクォータではなく、上限到達時の挙動

無料の利用枠自体は以前からありました。変わったのは、その上限に達したときの挙動です。

Workers Freeでは、1日のどちらかの利用枠を超えると、Workers Binding APIとREST APIの両方でD1がクエリを拒否するようになりました。Cloudflareは読み取り上限と書き込み上限で別々のメッセージを示し、利用枠が00:00 UTCにリセットされればクエリが再開すると説明しています。保存済みのデータはそのまま残ります。ただし、アプリケーションからデータを読み取ったり変更したりできなくなる可能性があります。

この違いこそが今回の要点です。単なる利用量の目安が、可用性を明確に分ける境界線になりました。

Cloudflareは1日の上限に達するとメールを送信します。障害の原因は把握できますが、その時点ですでにデータベースは利用できません。本番チームに必要なのは、停止後の説明だけではなく、利用量の予算と早期アラートです。9月1日付のD1変更履歴には、障害発生時の正確な挙動とエラーメッセージが記載されています。

Workers Paidは、この1日単位の停止の影響を受けません。両方の利用枠を余裕をもって下回るプロトタイプなら、今すぐ移行する必要はないでしょう。一方、D1に依存する実稼働サービスでは、Workers Freeを停止点のあるリソースとして扱う必要があります。

重要なのはスキャンされた行数

読み取り枠は、500万回のAPI呼び出しでも、500万件の返却レコードでもありません。データベースがクエリに応答するためにスキャンした行数が500万行まで、という意味です。

たとえば、あるフィルターが1件の顧客だけを返すとしても、有効なインデックスがなければ、D1はそのレコードを見つけるために5,000行のテーブルをスキャンする可能性があります。このクエリを1,000回実行すると、それだけで1日分の500万行を使い切ります。返ってくる結果は小さくても、その裏で行われる処理は小さくありません。

書き込みはより単純です。INSERT、UPDATE、DELETEでは、変更した行数がカウントされます。10行を挿入すれば、書き込みは10行です。CREATE、ALTER、DROPなどのスキーマ操作でも、読み取りと書き込みの両方が発生する場合があります。

行のサイズはこの計測値に影響しません。1 KBの行も100 KBの行も、それぞれ1行として数えられます。読み取り数を左右するのはクエリの形です。

インデックスがあれば、D1はテーブル全体をスキャンせず、対象レコードへ直接アクセスできます。通常は書き込み処理が少し増える代わりに、読み取りを大幅に減らせます。インデックスの対象列へ書き込むと、D1はテーブルの行に加え、少なくとも1つのインデックス行も書き込みます。だからこそ、むやみに全列へインデックスを付けるのではなく、頻繁な絞り込みや結合に使う列を選ぶことが重要です。

Cloudflareのインデックス活用ガイドには、明快な確認方法が示されています。負荷の高いクエリの先頭にEXPLAIN QUERY PLANを付けてください。実行計画にSCANと表示されればテーブルを読み取っており、SEARCH ... USING INDEXならインデックスを利用しています。インデックスを追加した後はPRAGMA optimizeを実行し、クエリプランナーが最新の統計情報を参照できるようにします。

Cloudflare D1 料金で変わったビジネス判断

Workers Freeの料金は引き続き$0です。変わったのはリスクです。データベース料金の上限はゼロのままですが、UTCでその日が終わるまで、アプリケーションへのデータベース提供が止まる可能性があります。

Workers Paidは1アカウントあたり月額$5からです。1日単位の強制停止がなくなり、月ごとの基本利用枠と超過料金へ切り替わります。

FreeからPaidへの差は、一見した印象よりも大きなものです。Freeの読み取り上限まで30日間使い続けても合計は1億5,000万行で、Paidに含まれる250億行のわずか0.6%です。Freeの書き込み上限を30日間使った場合も合計300万行で、Paidに含まれる5,000万行の6%にすぎません。

多くの小規模アプリケーションにとって、最初の有料化判断は超過料金の問題ではありません。月額$5で可用性を確保するかどうかの判断です。Workersのリクエスト、CPU、5 GBを超えるD1ストレージ、その他のCloudflare製品には、それぞれ別の計測項目があります。したがって、$5は最低額であり、アカウント全体の料金が必ず$5に収まるという意味ではありません。詳しい区分はCloudflareの料金レビューで確認できます。

D1にはデータ転送量やスループットに対する料金がありません。それでも、Freeでの停止リスクが軽くなるわけではありません。今回の判断でエグレスを計算に入れる必要がない、というだけです。

4つのチームに必要な4つの対応

稼働中のSaaSを運営する個人開発者

サインイン、請求状態、顧客向けダッシュボードのいずれかがD1を読み取るなら、Freeプランには本番停止のリスクがあります。まず通常営業日のうち最も負荷が高い日を特定し、フルスキャンを修正してください。それでも上限へ近づくなら、データベースを利用できない時間が何時間になるか分からない状況へ備えるより、最低$5を支払うほうが安く済みます。

ここで得られる効果は、単にデータベース容量が増えることではありません。障害復旧計画から「UTCの午前0時まで待つ」という条件を外せることです。

1つのアカウントで複数データベースを扱う制作会社

上限はアカウント単位で定義されています。制作会社の運用担当者は、1つの顧客サイトだけを確認して安全と判断するのではなく、そのCloudflareアカウントにあるすべてのD1データベースを洗い出す必要があります。

データベースごとのメトリクスから利用量の多いプロジェクトを見つけ、合計値を算出してからアカウントの予算を決めます。運用チームが管理できる共通の数値を持てることが、その成果です。あるプロジェクトの非効率なスキャンが、同じアカウント内の別の場所で原因不明の停止を招く事態は避けなければなりません。

高コストな読み取りを追うバックエンドエンジニア

必要なのは、無作為にデータを削除することではなく、負荷の原因となるクエリの形を特定することです。D1は各クエリのmetaオブジェクト内でrows_readとrows_writtenを返します。この値から、1回の実行にかかった正確なコストが分かります。

CloudflareはWranglerとGraphQL Analytics APIでもクエリインサイトを提供しています。読み取り数で並べ替えて繰り返し発生するスキャンを見つけ、実行計画を確認し、対象を絞ったインデックスを追加してから再計測します。同じ変更でクォータ消費量が減り、通常はレイテンシも改善します。

インポートや同期を実行する運用責任者

一括同期だけで100,000行の書き込みを消費し、顧客トラフィックがデータベースを使う余地を失うことがあります。緊急でないジョブはリセット時刻をまたいで処理量を調整するか、本番インポートの前にアカウントをPaidへ移行してください。

書き込み上限に達してから後片付けをする計画は成り立ちません。DELETE自体が書き込み操作なので、利用枠を使い切っていると、リセットまで削除クエリも実行できない可能性があります。バッチ処理中も実稼働の書き込み枠を確保できることが、この対応の利点です。

アラートが届く前にCloudflare D1 無料枠の予算を決める

最初の運用ルールとして、公開されているFree利用枠の80%を本番環境の予算に設定する方法があります。これはCloudflareの要件ではなく、運用者側の基準です。1日の運用上限を読み取り400万行、書き込み80,000行とし、突発的な増加や計測遅延に備えて読み取り100万行、書き込み20,000行を残します。

1. 1

   実際の1日分を計測する

   Cloudflareを開き、D1へ移動して各データベースを選び、Metricsを開きます。デフォルト表示は直近24時間です。通常の平日、リリース、インポート、トラフィック急増時の様子が分かるだけの履歴を確認してください。D1では、このメトリクスが31日間保持されます。

2. 2

   行数を消費しているクエリを見つける

   重要な経路をテストしながら、クエリごとのmeta.rows_readとmeta.rows_writtenを確認します。クエリインサイトを使い、実行頻度やコストが高いステートメントを順位付けしてください。最も負荷の高い読み取りクエリにEXPLAIN QUERY PLANを実行し、プランのアップグレードだけを解決策と考える前にフルスキャンを修正します。

3. 3

   強制停止より前にアラートを出す

   ダッシュボードと同じデータセットを読み取るGraphQL Analytics APIを使い、アカウントを定期確認します。読み取り400万行または書き込み80,000行で担当者へ通知してください。上限到達時に届くCloudflareのメールは障害の確認には役立ちますが、本番環境で最初に受け取る通知にしてはいけません。

4. 4

   障害時の判断を今のうちに決める

   D1が上限エラーを返したとき、Workerが何を返すか決めておきます。別のD1クエリを実行しないのであれば、キャッシュ済みの読み取り結果は引き続き利用できる可能性があります。書き込み経路には、利用不可を明示するレスポンスか、別途設計したキューが必要です。UTCの午前0時またはアップグレードまで回復しないクォータに対して、再試行を繰り返してはいけません。

D1メトリクスのドキュメントでは、GraphQLのフィールド名としてrowsReadとrowsWrittenが示され、ダッシュボードも同じ分析データを利用していることが確認できます。小規模なチームでも、今すぐ使える手動の確認手段と、データベースが通知担当者を置くほど重要になったときに自動化できる手段の両方を持てます。

対策にも限界がある

インデックスにもコストがあります。ストレージを消費し、インデックス対象の値が変われば書き込みが増えます。高コストなスキャンを解消するインデックスだけを追加し、その後のバランスを計測してください。すでに100,000行の書き込み上限へ近づいているアカウントでは、無差別なインデックス追加が逆効果になり得ます。

Paidも無制限ではありません。月間250億行の読み取りと5,000万行の書き込みが含まれ、それを超えると公開料金に基づく超過料金が発生します。アップグレードすれば通常は数分以内にFreeの日次停止が解除されますが、非効率なクエリの監視やWorkers全体の料金予測は引き続き必要です。運用手順書には、Cloudflareの最新のD1料金ページを参照資料として残しておきましょう。

情報源の履歴には、1点注意が必要です。2025年1月のD1リリースノートでは、適用開始日が2025年2月10日とされていました。一方、より新しく今回の事象に特化した変更履歴では、2026年9月1日に開始すると記載されています。本稿では、現在の展開を直接示している後者を基準としました。古い検索結果に異なる日付が表示されるのは、このためです。

最後に、「保存済みデータは影響を受けない」という説明は、「プロダクトに問題がない」という意味ではありません。データ自体が安全でも、そのデータを必要とするすべての経路でエラーが返ることはあります。ビジネス上の問題は可用性です。

月曜日にやるべきこと

顧客向けアプリケーションをWorkers Freeで運用し、リクエスト経路にD1があるなら、今週中に対応してください。まず計測し、明らかなスキャンを修正して、読み取り400万行と書き込み80,000行のアラートを設定します。そのうえで、$5のPaid移行を事前承認しておきます。

使い捨てのプロトタイプで、31日間の履歴が運用予算を十分に下回り、クエリが1日停止しても顧客や売上へ影響しないなら、移行を待っても構いません。それでも、トラフィックとテーブルサイズのどちらも読み取り量を変化させるため、アラートは残してください。

アカウントがすでにWorkers Paidを利用しているか、アプリケーションがD1へクエリを実行しない場合、今回の日次停止の影響は受けません。

月曜日に行うことは明快です。すべてのデータベースでD1のMetricsタブを開き、アカウントで読み取りと書き込みが最も多かった日の数値を記録し、最大のスキャンを発生させているクエリを特定して、1人にアップグレード権限を与えます。クエリを修正しても通常のピークが読み取り400万行または書き込み80,000行を超えるなら、その日のうちにアカウントをWorkers Paidへ移行してください。

次のプラットフォーム変更も運用上の判断として読み解きたい方は、ニュースレターにご登録ください。