第14章：KVの制限とアンチパターンを知ろう ⚠️🚧

KVは便利ですが、制限があります。
制限を知らずに使うと、あとで設計を変えることになります。
この章では、KVでやらない方がよいことを先に知っておきます 😊

1. 代表的な制限 📏

2026年時点の公式Limitsでは、次のような制限が案内されています。

正確な数字は今後変わる可能性があるため、実装前には公式Limitsを確認します。

Understanding KV limits

アクセス数のようなカウンターを、同じKVキーで毎回更新する設計は向きません。

counter:page = 123

アクセスごとにこのキーを書き換えると、同じキーへの書き込み制限や整合性の問題にぶつかります。

Why KV is bad for counters

カウンター用途では、Durable Objects、Analytics Engine、D1など別の選択肢を検討します。

在庫数や残高のように、正確さが強く必要なデータをKVだけで扱うのは危険です。

理由です。

こうしたデータには、より強い整合性を持つ設計が必要です。

Not using KV for strict inventory/balances

KVは、キーで読むのが得意です。

Differentiating KV and D1 for search

タグ検索、全文検索、日付順一覧、集計などには向きません。

メモ一覧やユーザー管理を本格的に作るならD1を検討します。

キーが分かっている → KV
条件で探したい → D1

この切り分けが大事です。

KVのvalue sizeは25 MiBです。
小さなJSONや文字列ならよいですが、画像やPDFの本体をKVに入れるのは自然ではありません。

Using R2 for large files instead of KV

ファイル本体はR2、ファイル情報はD1やKVへ置く形を考えます。

この章で覚える一言はこれです。
KVは軽い記憶。万能DBや巨大ファイル倉庫として使いすぎないようにしよう ⚠️

Summary of KV limitations