UUIDをデフォルトにするな

先月、シニアエンジニアが遅いクエリのデバッグに2日費やすのを見た。犯人？5,000万行のテーブルにUUIDを主キーとして使っていた。インデックスは必要な2倍のサイズで、レンジスキャンは痛いほど遅かった。

UUIDは多くのチームにとってデフォルトの選択になっている。でもデフォルトは疑うべきだ。

UUIDの本当のコスト

UUIDは16バイト。整数は4-8バイト。些細に聞こえるが、計算するとそうでもない。

5つの外部キーを持つ1億行のテーブル：

• BIGINT (8バイト): PKインデックス ~800MB + FKインデックス ~3.7GB = 合計 ~4.5GB
• UUID (16バイト): PKインデックス ~1.6GB + FKインデックス ~7.4GB = 合計 ~9.0GB

ストレージ2倍。メモリ圧力2倍。I/O 2倍。

でも大きな問題はインデックスの断片化だ。UUIDv4はランダムなので、挿入がB-treeのあちこちに着地する。ページ分割が絶えず起きる。

数百万行の本番PostgreSQLセットアップで、BIGINTの挿入はUUIDv4より一貫して30-40%速かった。レンジスキャン？BIGINTは劇的に速かった。UUIDv7は書き込みでBIGINTに近く、それが重要な理由だ。

UUIDが本当に意味があるとき

UUIDは特定の問題を解決する：

分散システム — 10個のデータベースシャード間でオートインクリメントを調整できない。UUIDは調整なしでどこでも生成できる。

パブリックAPI — シーケンシャルIDは情報を漏らす。GET /api/users/1000で、攻撃者は約1000人のユーザーがいることを知り、/api/users/1001、/api/users/1002を試す... 典型的なIDOR脆弱性。GET /api/users/550e8400-e29b-...では、何もわからず他のユーザーを列挙できない。

マージ衝突 — データベース間でデータを同期？シーケンシャルIDは衝突する。UUIDはしない。

これらがユースケースに当てはまらないなら、おそらくUUIDは必要ない。

ハイブリッドパターン

本番で実際に効くのはこれ：両方使う。

内部クエリは高速な整数を使う。APIは安全なUUIDを公開。両方の良いとこ取り。

UUIDv7が状況を変える

UUIDv7は時間順序付き。最初の48ビットはタイムスタンプなので、挿入は整数のようにシーケンシャルだがUUIDのようにグローバルユニーク。

UUIDv4 (550e8400-e29b-41d4-a716-446655440000): ランダムビット、順序なし。挿入ごとにB-treeインデックスを断片化。

UUIDv7 (019006f3-2e47-7000-8000-000000000001): 最初の48ビットがUnixタイムスタンプ(ms)、自然にソート。挿入は整数のようにインデックスの末尾に。

ベンチマークでは、UUIDv7はユニーク性保証を保ちながら挿入パフォーマンスのほとんどを回復する。

挿入パフォーマンス（100万行）: BIGINTがベースラインで100%。UUIDv7は92% — ほぼ同等。UUIDv4は68% — 大きなペナルティ。

UUIDが必要なら、v7を使え。PostgreSQL 17+はネイティブサポート。古いバージョンは、アプリケーションコードで生成するかpg_uuidv7エクステンションを使う。

決定チェックリスト

• IDは内部のまま、単一データベース？ → BIGINT（シンプル、速い、コンパクト）
• IDがURLやAPIで公開される？ → UUIDかハイブリッド（両方の良いとこ取り）
• 分散マイクロサービス、マルチリージョン？ → UUIDv7（グローバルユニーク + 時間順序）
• 高書き込みOLTPワークロード？ → 内部はBIGINT + 外部参照はUUID
• データベースをマージまたはオフライン同期する必要がある？ → UUID（衝突リスクなし）

キーはどちらが「良い」かではない。何をトレードオフしているか理解することだ。意図的に選択しろ。

---

普遍的なIDはない。アクセスパターンに適したものだけがある。

— blanho