分散データベース 2025 完全ガイド — CockroachDB·Spanner·TiDB·Yugabyte·Aurora DSQL·Neon·PlanetScale·Turso·D1 徹底比較 (シーズン7 第3回)

プロローグ — 「どのDB？」がまた難しくなった理由

2015年頃は簡単だった。「関係型ならPostgres、速度ならMySQL、文書ならMongo、キャッシュはRedis」。10年経った2026年現在、「どのDB？」と聞かれると候補が10個以上出てくる。Neon? Supabase? PlanetScale? CockroachDB? Spanner? TiDB? Yugabyte? Aurora DSQL? Turso? D1? 「Postgres」とだけ言ってもどのPostgresかが別テーマになる。

3つの力が同時に動いた。

1. サーバーレスとエッジの普及 — Vercel·Cloudflare·Lambda のような短命ランタイムが主流になり、「コネクションプールを永遠に保持するDB」が合わなくなった。
2. マルチリージョン·グローバルユーザー — 単一リージョンPostgresでは地球規模の遅延とデータ主権が壁に。分散SQLが「Googleだけの問題」ではなくなった。
3. 課金モデルの再編 — 遊休でも定額課金されるRDSの代わりに、Scale-to-Zeroが可能なサーバーレスDBがスタートアップの基本になった。

本稿は分散SQLとサーバーレス/エッジDBがどう分岐し、どの問題に合うかを実戦的な選択基準でまとめる。「どれが一番か」ではなく「どの問題に何が合うか」が目標。

1章. CAP·PACELCを読み直す

10年前は「CAPから2つ選ぶ」で終わったが、現在はPACELC（Partition: A vs C / Else: Latency vs Consistency）のほうが有用。正常時でもレイテンシと一貫性はトレードオフ。

厳密な直列化（Strict-Serializable）はタダではない。SpannerはTrueTime、Cockroachはハイブリッド論理クロック + commit-wait。マルチリージョン書き込みは合意の往復が不可避。

実戦チェック

• P99書き込み100ms以上を許容できるか？ 不可ならシングルリージョン設計。
• 厳密一貫性が必要なトランザクションは何%？（残高·在庫·座席予約は必須、フィード·統計は不要）
• データ主権が契約にあるか？ EUデータはEU、韓国金融は国内、ならマルチリージョン + リージョンピンニングが必須。

2章. 分散SQL三強 — Spanner, CockroachDB, TiDB

2.1 Google Cloud Spanner

Googleが2012年に出した元祖グローバル分散RDB。検索·広告の裏で動く。2023年末にPostgresインターフェースがGA。「Postgres文法で書くグローバルDB」のポジション。

• TrueTime（原子時計 + GPS）で外部一貫性。
• マルチリージョン書き込みをボタン一つで。
• 2024年 Spanner Graph·全文検索追加。
• 高価。最小ノード規模とストレージ単価が高い。

使う時: GCPを既に利用中、マルチリージョン要件、運用負荷を最小化したい。 避ける時: 単一リージョンで十分。Cloud SQLのほうが10倍安い。

2.2 CockroachDB

2015年リリースのオープンソース「Spanner風」。Postgresワイアプロトコル、Raft合意、HLC。

• 2024–2025: ベクトルインデックス、CDCウェブフックシンク、プランナー改善。
• ライセンス変更(2024): セルフホストは規模超過で有償。選定で最も敏感な論点。
• Serverless商品は「Cockroach Cloud Basic/Standard」にリブランド。

長所: マルチリージョントポロジをSQL 1行 (ALTER TABLE ... SET LOCALITY REGIONAL BY ROW) で設定、オンラインスキーマ変更、Postgres互換性高。 短所: 単ノードはPostgresより遅い、複雑クエリのチューニング難、ライセンス理由でYugabyteへ流出。

2.3 TiDB

PingCAP製。MySQLプロトコル互換の分散SQL。アジア圏（中国·日本·韓国一部）で存在感大。

構成: TiDB(SQL層) + TiKV(分散KV, Raft) + PD(配置) + TiFlash(列ストア、分析用)。

2024–2025: TiDB ServerlessがGA拡大。ベクトル型 + HNSW。TiDB MCP公開(2025)。

強み: MySQL生態系そのまま + 分散拡張。HTAP構成で行+列ストアを一クラスタ内で。 弱み: Postgres派には不向き。マルチリージョン書き込みはSpanner/Cockroach未満。

2.4 三者要約

3章. Yugabyte — 「本物のPostgresな分散SQL」

YugabyteのYSQLは実際のPostgresコードをフォーク。Postgres 13+の文法·関数·拡張 (pgcrypto, pg_trgm, pgvector) がほぼそのまま動く。

• デュアルAPI: YSQL(Postgres互換) + YCQL(Cassandra系)。
• マルチリージョン: xCluster(非同期)、ジオパーティショニング(同期)。
• Yugabyte Aeon: サーバーレス、条件付きScale-to-Zero。
• Apache 2.0コア。Cockroachライセンス騒動後の第一の移行先。

短所: 単一リージョン性能はバニラPostgresに及ばず、コミュニティはCockroach/TiDBより小さい。

4章. Aurora DSQL — AWSの「サーバーレス + 分散 + Postgres」

2024年 re:Invent で発表。

• 「Spanner級グローバル + Postgres互換 + サーバーレス」。
• Active-Activeマルチリージョン書き込み（プレビュー整理中）。
• Postgresワイアプロトコル互換だが完全なPostgresではない — 外部キー·シーケンス·一部拡張に制限。
• スケール-to-ゼロ、使用量課金、クエリプロセッサ·トランザクションマネージャ·ストレージ分離。
• IAM認証ネイティブ — Lambdaトークン接続。

注意: 2025年時点GA進行中、機能マトリクスは完全Postgres互換ではない。AWSロックイン。

使う時: AWS生態系、Scale-to-Zeroが重要なスタートアップ、GCPに縛られたくないがSpanner風が欲しい。

5章. サーバーレスPostgres三強 — Neon, Supabase, PlanetScale

5.1 Neon — 「Gitのようにブランチできるpostgres」

• ストレージ·コンピュート分離。遊休時コンピュート自動停止。
• ブランチ: mainからfeature-xを作って同じデータスナップショット上でマイグレーション実験。CoWなので複製コストほぼゼロ。
• 任意時点Point-in-Time Restore。
• 2024年末DatabricksがNeon買収 — 「AI·エージェントのためのDB」ポジション強化。

短所: シングルリージョン（書き込み）。グローバル読み取りレプリカに限定。

5.2 Supabase — 「Postgres + Auth + Storage + RT + Edge」

Postgres中心にFirebase風バックエンドを束ねたスタック。

• Supabase Queues、Cron、AI Assistant。
• pgvector標準搭載 — RAG/ベクトル検索即可。
• Row-Level Security(RLS)がAuthと深く統合。
• セルフホスト可能（オープンソースコア）。

短所: RLSは強力だが初期のミスが多い（誰でも読める穴）。マネージドはシングルリージョン。

5.3 PlanetScale — 「元々MySQL、今はPostgresも」

元はVitess基盤のMySQL互換サーバーレス。ブランチング/Deploy Request の元祖。

• 2024年無料ティア廃止 → Neon/Supabaseへの流出加速。
• 2025年PlanetScale for Postgres発表 — Neonと正面対決。
• スキーマ変更プロセスが最も洗練（branch → deploy request → safe migrations）。

短所: 無料ティアなし。Postgres製品はNeon比で新興。

5.4 要約

6章. エッジSQLite — Turso/libSQL, Cloudflare D1

6.1 Turso / libSQL

SQLiteフォークのlibSQL。埋め込みレプリカが核心。

1. マスター(書き込み)は特定リージョン。
2. 各エッジノードがローカルSQLiteファイル複製を保持。
3. 読みはローカルファイルから → マイクロ秒レイテンシ。
4. 書きはマスターへ。

利点: 読みレイテンシがネットワーク往復なし。マルチテナントSaaSでテナント当たりDB 1個が現実的（DB生成秒単位）。 限界: 書き込みスループット上限。複雑なジョイン·分析は依然Postgresが優位。

6.2 Cloudflare D1

Cloudflare Workers統合のSQLiteベースDB。

• D1 Read Replicas登場(2025)。
• Workersから env.DB.prepare(...) 一行でアクセス、コールドスタートなし。

限界: DB上限サイズ、トランザクション分離·高負荷書き込みは進化中。

6.3 使い分け

• グローバル読み中心（文書、商品カタログ、CMS、ブログ）: エッジSQLite圧勝。
• テナント当たりDBモデルのSaaS: Turso最適。
• グローバル書き込み中心（共同編集、リアルタイム）: 分散SQL。

7章. 「Postgres拡張戦争」 — pgvector, Citus, TimescaleDB, pgmq

Postgresが「単純RDB」から「データプラットフォーム」へ進化したのが2022–2025の大きな流れ。

• pgvector — 埋め込み、HNSW/IVFFlat。RAGの基本。
• Citus — 分散Postgres。MicrosoftがAzure Database for PostgreSQLに内蔵。
• TimescaleDB — 時系列。2024年ライセンス変化で全マネージドPostgresで利用可能に。
• pgmq — Postgresでメッセージキュー。小規模イベントでSQS代替。
• PostgREST / pg_graphql — テーブルを即API化。
• pg_trgm / pg_bigm — 全文検索（日本語·韓国語N-gram）。

実戦アドバイス: 必要拡張のリストを先に作ってから候補DBを絞る。拡張が動かなければ乗り換え大変。

8章. コネクション管理 — サーバーレスの真の病目

サーバーレス環境でPostgresを使う時の真の問題は「DB性能」ではなくコネクション。Lambdaが1000個直接DBに繋げばPostgresは数百コネクションで崩壊。

指針

• Vercel/Lambda + Postgres → HTTPドライバ（Neon serverless driver, Prisma Accelerate）を最優先。
• コンテナ/ECS/Fargate + Postgres → PgBouncer or マネージドプーラ。
• 大規模単一アプリ → アプリ内プール（HikariCP, PgBouncerサイドカー）。

9章. マイグレーション·スキーマ変更 — 2025年の定石

伝統的な痛み: 大テーブルでのALTER TABLEロック数分〜数時間、ロールバック困難、環境間ドリフト。

2025年の解法

ツール

• Atlas — 宣言型スキーマ + 診断 + CI統合。
• pgroll — Postgresオンラインマイグレーション。シャドウスキーマ + 双方向ビュー。
• Neon Branch — 「ブランチで変更 → デプロイ」。
• PlanetScale Deploy Request — 元祖。ブランチ + レビュー + 安全マイグレーション。
• Prisma Migrate / Drizzle Kit / Sqitch — 各ORM/ツールのパイプライン。

原則 — Expand & Contract

1. 新カラム追加（NULL許容、デフォルトなし）。
2. アプリで両方書き込み（新旧同時）。
3. バックフィル。
4. 読みを新カラムへ。
5. 旧カラム削除。

各段階が後方互換。デプロイ中のロールバックでも壊れない。

10章. 観測性·バックアップ·DR

機能は似て見えても、運用段階の品質は製品間で差が大きい。

• 観測性: スロークエリログ、pg_stat_statements公開、EXPLAIN UX、メトリクスダッシュボード。
• バックアップ: PITRの粒度、クロスリージョンコピー。
• 障害復旧: リージョン障害時のフェイルオーバー自動化、RPO/RTO数値。
• セキュリティ: IP allowlist, VPC Peering/Private Link, 暗号化、監査ログ。
• 規制: SOC2/ISO27001/HIPAA/PCI/GDPR/個人情報保護法。

11章. コスト構造 — 「お金が漏れる」5箇所

1. IOPS·ストレージ分離課金 — Aurora·DSQL·Neonはストレージとコンピュート分離。コンピュートを削ってもストレージ固定費残る。
2. イグレス(Egress) — クロスリージョン/クラウド外への出口が高い。
3. コネクション当たりメモリ — Lambda数千個直接接続すれば、メモリがコネクションオーバーヘッドで枯渇。
4. ブランチ·スナップショット蓄積 — Neon/PlanetScaleでブランチが増えれば「CoWストレージ」が積み上がる。
5. ベクトルインデックスサイズ — pgvector HNSWは速いがメモリ大。「10M × 1536-d ≈ 60GB+」を事前計算。

12章. 意思決定ツリー

Q1: 厳密一貫性 + グローバル書き込み必須？
├─ はい: Spanner / Cockroach / Yugabyte / Aurora DSQL
└─ いいえ → Q2

Q2: サーバーレス/エッジが主ランタイム？
├─ 読み中心 + エッジ: Turso(libSQL), Cloudflare D1
├─ 書きも頻繁 + 普通のCRUD: Neon, Supabase, PlanetScale
└─ いいえ → Q3

Q3: 大型分析·HTAP が必要？
├─ はい: TiDB(HTAP), or OLAPをBigQuery/Snowflake/ClickHouseに分離
└─ いいえ → Q4

Q4: Postgres拡張生態系を100%欲しい？
├─ はい、マネージド: Supabase, Neon, RDS for Postgres
├─ はい、セルフホスト: Postgres + Citus + TimescaleDB
└─ いいえ → 一般的RDB: RDS MySQL, Aurora MySQL, Cloud SQL

13章. 2026年以降の注視点

1. AIネイティブDB: Neon(Databricks傘下)、TiDB、MotherDuckが「エージェントのためのDB」機能に注力。DBがエージェントの作業空間になる。
2. 分散ベクトルインデックス: pgvector HNSWのシャーディングは難。2026年の激戦地。
3. Aurora DSQL GA後: AWS本流サービスのため影響大。既存Aurora, RDS, DynamoDBの位置づけ変動。
4. 主権クラウド(Sovereign Cloud): EU·中東·日本でデータ主権規制強化 → マルチリージョンが必須に。
5. ZFS·DuckDBのサーバー側浸透: ストレージ層にDuckDBやParquetを挟む「lakehouse風」DB登場。

実戦導入チェックリスト — 12個の質問

1. 現行のクエリ·コネクションパターンを計測したか(P50/P99, 同時コネクションピーク)？
2. 厳密一貫性が必要なテーブル/トランザクションを明文化したか？
3. データ主権要件が明記されているか？
4. 必要なPostgres拡張リストがあるか？候補DBすべてで対応可能か？
5. Scale-to-Zeroが必要か？それとも24/7負荷か？
6. ブランチングが実際のワークフローで意味があるか（PRごとにブランチ作るか）？
7. バックアップ/PITR RPO·RTO数値は？
8. コネクションプーラ戦略は決まったか（HTTPドライバ vs PgBouncer vs RDS Proxy）？
9. スキーマ変更プロセスは？Atlas/pgroll/Deploy Request?
10. 観測性スタック（Datadog·Grafana·pg_stat_statements）と統合可能か？
11. ロックインコスト（離脱の辛さ）を計算したか？
12. 3年後のデータ量·トラフィックで価格モデルが有効か？

よくある間違い10個

1. 「ただのPostgres」とひとくくりにする — RDS/Aurora/Neon/Supabaseは細部が異なる。
2. 厳密一貫性を全テーブルに要求 — 80%は結果整合性で十分。
3. マルチリージョンを「後で」に延期 — リファクタ地獄。
4. ブランチ掃除をしない — Neon/PlanetScaleで数千ブランチ積み上がり → コスト爆発。
5. コネクションプーラなしのサーバーレス — サービスダウン最多原因。
6. ベンダーロックを問わず — Spanner·DSQLは離脱難。
7. EXPLAIN ANALYZEを回さない — 分散DBほど実行計画重要。
8. タイムゾーン混乱 — UTC保存、表示時のみ変換。
9. 外部キーなしで始める — 後付けが非常に高価。
10. 「DBは変えなくていい」 — 5年以上のサービスなら1回は移行する。抽象化レイヤを先に。

次回予告

シーズン7 第4回はメッセージキューとイベントストリーミング 2025 — Kafka·Pulsar·NATS·Redpanda·NSQ·pgmq·AWS SQS/SNS·GCP Pub/Sub の比較。分散トランザクションの難しさ、イベントソーシングとCQRSの実戦、Exactly-onceが嘘である理由まで。

— 分散データベース編、完。