Durable Objects にストレージ課金が開始
SQLite バックエンドの Durable Objects について、それまで課金されていなかったストレージ利用分の課金が開始。読み取り行・書き込み行・保存データがそれぞれ従量課金の対象になり、課金開始日以降の利用分から計上される。
変更前
SQLite バックエンドの Durable Objects は利用できたが、ストレージ利用分は課金されていなかった。
課金されるのはリクエストと実行時間（Duration）が中心で、SQLite に書き込んだデータ量や、クエリが読んだ行数は請求に現れなかった。KV バックエンドの Durable Objects には以前からストレージ課金があり、両バックエンドで扱いが異なる状態だった。
変更後
SQLite バックエンドにもストレージ課金が適用される。有料プランでの単価は以下のとおり。
- 読み取り行: 月250億行まで込み、超過分は100万行あたり $0.001
- 書き込み行: 月5,000万行まで込み、超過分は100万行あたり $1.00
- 保存データ: 5GB-月まで込み、超過分は $0.20 / GB-月
課金開始日以降の利用分のみが対象で、それ以前に蓄積したストレージが遡って請求されることはない。
KV バックエンドの単価は据え置き（読み取り100万ユニットあたり $0.20、書き込み・削除は各 $1.00、保存データ $0.20 / GB-月、いずれも有料プランのみ）。
影響
単価の変更ではなく、これまで無償だった軸に課金が追加された変更である。したがって「何%値上げ」という形では影響が測れない。請求額がゼロだった項目が、ゼロでなくなる。
効く順に見ると、影響が大きいのは書き込み行である。読み取りは月250億行まで込みで単価も100万行あたり $0.001 と極端に安いのに対し、書き込みは月5,000万行までで、超過単価は読み取りの1,000倍にあたる100万行あたり $1.00。読み取り中心のワークロードならほぼ無視できる一方、頻繁に状態を書き戻す設計では実際に効いてくる。
バイト数ではなく行数で見積もる
特に注意すべきなのは、「行数」で課金される点が Durable Objects の使い方と相性が悪い場合があることである。
1つのオブジェクトが持つ状態を小さく分割して保存する設計にしていると、論理的には1回の更新でも書き込み行数は膨らむ。データ量は小さいのに行数だけが多いという状態になり得る。
同じ状態を保存するにも、
- キーごとに1行ずつ書く設計 — 行数が状態の項目数だけ増える
- 状態をまとめて1行に書く設計 — 1行で済むが、部分更新ができない
という差が、そのまま請求額の差になる。設計時にバイト数ではなく行数を数えること。
エラーも警告も出ない
既存プロジェクトへの影響は、課金開始日をまたいだ最初の請求で初めて見える。動作は何も変わらないため、気付く契機が請求書しかない。
SQLite バックエンドで本番運用しているなら、課金開始後の請求内訳を一度確認しておくこと。KV バックエンドを使っている場合、ストレージ課金は以前から適用されているため、この変更による影響はない。