コンテンツにスキップ

価格設定

D1の請求は以下に基づいて行われます:

  • 使用量: D1に対して実行するクエリは、読み取られた行、書き込まれた行、またはその両方(トランザクションやバッチの場合)としてカウントされます。
  • スケール・トゥ・ゼロ: 時間やキャパシティユニットに対して請求されることはありません。データベースに対してクエリを実行していない場合、コンピュートに対して請求されることはありません。
  • ストレージ: プランに含まれる制限を超えるストレージに対してのみ請求されます。

請求メトリクス

Workers FreeWorkers Paid
Rows read5 million / dayFirst 25 billion / month included + $0.001 / million rows
Rows written100,000 / dayFirst 50 million / month included + $1.00 / million rows
Storage (per GB stored)5 GB (total)First 5 GB included + $0.75 / GB-mo

Definitions

  1. Rows read measure how many rows a query reads (scans), regardless of the size of each row. For example, if you have a table with 5000 rows and run a SELECT * FROM table as a full table scan, this would count as 5,000 rows read. A query that filters on an unindexed column may return fewer rows to your Worker, but is still required to read (scan) more rows to determine which subset to return.
  2. Rows written measure how many rows were written to D1 database. Write operations include INSERT, UPDATE, and DELETE. Each of these operations contribute towards rows written. A query that INSERT 10 rows into a users table would count as 10 rows written.
  3. DDL operations (for example, CREATE, ALTER, and DROP) are used to define or modify the structure of a database. They may contribute to a mix of read rows and write rows. Ensure you are accurately tracking your usage through the available tools.
  4. Row size or the number of columns in a row does not impact how rows are counted. A row that is 1 KB and a row that is 100 KB both count as one row.
  5. Defining indexes on your table(s) reduces the number of rows read by a query when filtering on that indexed field. For example, if the users table has an index on a timestamp column created_at, the query SELECT * FROM users WHERE created_at > ?1 would only need to read a subset of the table.
  6. Indexes will add an additional written row when writes include the indexed column, as there are two rows written: one to the table itself, and one to the index. The performance benefit of an index and reduction in rows read will, in nearly all cases, offset this additional write.
  7. Storage is based on gigabytes stored per month, and is based on the sum of all databases in your account. Tables and indexes both count towards storage consumed.
  8. Free limits reset daily at 00:00 UTC. Monthly included limits reset based on your monthly subscription renewal date, which is determined by the day you first subscribed.
  9. There are no data transfer (egress) or throughput (bandwidth) charges for data accessed from D1.

よくある質問

D1の価格設定に関するよくある質問:

D1には常に無料プランがありますか?

はい、Workersの無料プランには、D1を無料でプロトタイプや実験する機能が常に含まれます。

無料プランで読み取りと書き込みの1日の制限や総ストレージ制限を超えた場合はどうなりますか?

アカウントが1日の読み取りおよび/または書き込みの制限に達すると、D1に対してクエリを実行できなくなります。D1 APIは、1日の制限を超えたことを示すエラーをクライアントに返します。含まれるストレージ制限に達した場合は、新しいデータを挿入したり、テーブルを作成または変更したり、インデックスやトリガーを作成する前に、未使用のデータベースを削除するか、古いデータを整理する必要があります。

Workersの有料プランにアップグレードすると、通常数分以内にこれらの制限が解除されます。

有料プランで月間の含まれる読み取り、書き込み、またはストレージを超えた場合はどうなりますか?

D1の価格設定メトリクスに従って、追加の読み取り、書き込み、ストレージに対して請求されます。

D1はいつから請求を開始しますか?

Workersの有料プランのユーザーに対して、Cloudflareは含まれる読み取り、書き込み、ストレージを超える追加使用に対して2023年9月(それ以前ではない)から請求を開始する予定です。Cloudflareは、この変更の前にすべての顧客にメール(アカウントのスーパ管理者アドレス)で通知します。

(最終的な) 請求額をどのように見積もることができますか?

すべてのクエリは、読み取られた行の合計数(rows_read)と書き込まれた行の合計数(rows_written)を含むmetaオブジェクトを返します。たとえば、5000行のテーブルから全行スキャンを行うクエリ(例:SELECT * FROM users)は、rows_readの値として5000を返します:

"meta": {
"duration": 0.20472300052642825,
"size_after": 45137920,
"rows_read": 5000,
"rows_written": 0
}

これらはD1のCloudflareダッシュボード分析APIにも含まれており、特定のデータベース、期間、またはその両方に対して読み取りおよび書き込みのボリュームを帰属させることができます。

D1はデータ転送/エグレスに対して請求しますか?

いいえ。

D1は追加のコンピュートに対して追加料金を請求しますか?

D1自体は追加のコンピュートに対して請求しません。D1をクエリし、結果を計算するWorkers(たとえば、結果をJSONにシリアライズしたり、クエリを実行したりする)は、D1特有の使用に加えてWorkersの価格設定に基づいて請求されます。

ダッシュボードやWrangler(CLI)から実行するクエリは請求対象の使用量にカウントされますか?

はい、データベースに対して実行するすべてのクエリ、既存のデータを新しいデータベースに挿入する(INSERT)、テーブルスキャン(SELECT * FROM table)、またはインデックスを作成することは、読み取りまたは書き込みとしてカウントされます。

インデックスを使用してクエリによって読み取られる行数を減らすことはできますか?

はい、インデックスを使用してクエリによって読み取られる行数を減らすことができます。最もクエリされるテーブルやフィルタリングされた列のためにインデックスを作成することで、スキャンされるデータ量を減らし、同時にクエリのパフォーマンスを向上させることができます。読み取りが多いワークロード(最も一般的なケース)では、特に有利です。インデックスに参照される列に書き込むと、インデックスを更新するために少なくとも1行(1)の追加書き込みが発生しますが、これは通常、インデックスの利点による読み取られる行数の減少によって相殺されます。

新しく作成されたデータベースや、行がない空のテーブルは、私のストレージに寄与しますか?

はい、ただし最小限です。空のテーブルは、テーブル内の列の数(テーブルの幅)に基づいて、少なくとも数キロバイトを消費します。空のデータベースは、約100 KBのストレージを消費します。