プロローグ — 「どのDB？」がまた難しくなった理由
2015年頃は簡単だった。「関係型ならPostgres、速度ならMySQL、文書ならMongo、キャッシュはRedis」。10年経った2026年現在、「どのDB？」と聞かれると候補が10個以上出てくる。Neon? Supabase? PlanetScale? CockroachDB? Spanner? TiDB? Yugabyte? Aurora DSQL? Turso? D1? 「Postgres」とだけ言ってもどのPostgresかが別テーマになる。
3つの力が同時に動いた。
- サーバーレスとエッジの普及 — Vercel·Cloudflare·Lambda のような短命ランタイムが主流になり、「コネクションプールを永遠に保持するDB」が合わなくなった。
- マルチリージョン·グローバルユーザー — 単一リージョンPostgresでは地球規模の遅延とデータ主権が壁に。分散SQLが「Googleだけの問題」ではなくなった。
- 課金モデルの再編 — 遊休でも定額課金されるRDSの代わりに、Scale-to-Zeroが可能なサーバーレスDBがスタートアップの基本になった。
本稿は分散SQLとサーバーレス/エッジDBがどう分岐し、どの問題に合うかを実戦的な選択基準でまとめる。「どれが一番か」ではなく「どの問題に何が合うか」が目標。
1章. CAP·PACELCを読み直す
10年前は「CAPから2つ選ぶ」で終わったが、現在はPACELC（Partition: A vs C / Else: Latency vs Consistency）のほうが有用。正常時でもレイテンシと一貫性はトレードオフ。
| システム | パーティション時 | 平時 |
|---|---|---|
| DynamoDB, Cassandra | A | L |
| Spanner, CockroachDB | C | C |
| MongoDB (既定) | A | L |
| MongoDB (majority write) | C | L→C |
厳密な直列化（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 三者要約
| 項目 | Spanner | CockroachDB | TiDB |
|---|---|---|---|
| プロトコル | Postgres | Postgres | MySQL |
| マルチリージョン書込 | 最強 | 強 | 並 |
| HTAP | 並 | 弱 | 強(TiFlash) |
| ベンダーロック | GCP | 低 | 低 |
| 価格 | 高 | 中 | 中〜低 |
| OSS | ✗ | 複雑(BSL) | Apache 2.0 |
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 要約
| 項目 | Neon | Supabase | PlanetScale |
|---|---|---|---|
| プロトコル | Postgres | Postgres | MySQL + Postgres |
| ブランチ | 最強 | 有 | 強 |
| Scale-to-Zero | O | O(Pro) | 制限 |
| 無料ティア | O | O | ✗ |
| BaaSバンドル | ✗ | O | ✗ |
| ベクトル | pgvector | pgvector | pgvector |
6章. エッジSQLite — Turso/libSQL, Cloudflare D1
6.1 Turso / libSQL
SQLiteフォークのlibSQL。埋め込みレプリカが核心。
- マスター(書き込み)は特定リージョン。
- 各エッジノードがローカルSQLiteファイル複製を保持。
- 読みはローカルファイルから → マイクロ秒レイテンシ。
- 書きはマスターへ。
利点: 読みレイテンシがネットワーク往復なし。マルチテナント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は数百コネクションで崩壊。
| ツール | 位置 | 特徴 |
|---|---|---|
| PgBouncer | アプリ↔DB | 伝統派。トランザクション/セッションプーリング |
| Supavisor | Supabase内蔵 | Postgresワイア互換プーラ(Elixir) |
| Neon Pooler | Neon内蔵 | サーバーレスレイテンシ最適化 |
| RDS Proxy | AWS | マネージド、Lambda向け |
| Prisma Accelerate | SaaS | グローバルエッジプール + クエリキャッシュ |
| HTTP Driver | クライアント | コネクション自体を捨てHTTPSでクエリ |
指針
- 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
- 新カラム追加（NULL許容、デフォルトなし）。
- アプリで両方書き込み（新旧同時）。
- バックフィル。
- 読みを新カラムへ。
- 旧カラム削除。
各段階が後方互換。デプロイ中のロールバックでも壊れない。
10章. 観測性·バックアップ·DR
機能は似て見えても、運用段階の品質は製品間で差が大きい。
- 観測性: スロークエリログ、
pg_stat_statements公開、EXPLAINUX、メトリクスダッシュボード。 - バックアップ: PITRの粒度、クロスリージョンコピー。
- 障害復旧: リージョン障害時のフェイルオーバー自動化、RPO/RTO数値。
- セキュリティ: IP allowlist, VPC Peering/Private Link, 暗号化、監査ログ。
- 規制: SOC2/ISO27001/HIPAA/PCI/GDPR/個人情報保護法。
| 製品 | PITR | マルチリージョンバックアップ | VPCピアリング |
|---|---|---|---|
| Aurora (RDS) | 秒単位 | O | O |
| CockroachDB Cloud | 分単位 | O | O |
| Neon | 任意時点 | 条件付 | O(Enterprise) |
| Supabase | 日次(PITR有償) | 有償 | Enterprise |
| Turso | 分単位 | 地域別 | 制限 |
11章. コスト構造 — 「お金が漏れる」5箇所
- IOPS·ストレージ分離課金 — Aurora·DSQL·Neonはストレージとコンピュート分離。コンピュートを削ってもストレージ固定費残る。
- イグレス(Egress) — クロスリージョン/クラウド外への出口が高い。
- コネクション当たりメモリ — Lambda数千個直接接続すれば、メモリがコネクションオーバーヘッドで枯渇。
- ブランチ·スナップショット蓄積 — Neon/PlanetScaleでブランチが増えれば「CoWストレージ」が積み上がる。
- ベクトルインデックスサイズ — 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年以降の注視点
- AIネイティブDB: Neon(Databricks傘下)、TiDB、MotherDuckが「エージェントのためのDB」機能に注力。DBがエージェントの作業空間になる。
- 分散ベクトルインデックス: pgvector HNSWのシャーディングは難。2026年の激戦地。
- Aurora DSQL GA後: AWS本流サービスのため影響大。既存Aurora, RDS, DynamoDBの位置づけ変動。
- 主権クラウド(Sovereign Cloud): EU·中東·日本でデータ主権規制強化 → マルチリージョンが必須に。
- ZFS·DuckDBのサーバー側浸透: ストレージ層にDuckDBやParquetを挟む「lakehouse風」DB登場。
実戦導入チェックリスト — 12個の質問
- 現行のクエリ·コネクションパターンを計測したか(P50/P99, 同時コネクションピーク)？
- 厳密一貫性が必要なテーブル/トランザクションを明文化したか？
- データ主権要件が明記されているか？
- 必要なPostgres拡張リストがあるか？候補DBすべてで対応可能か？
- Scale-to-Zeroが必要か？それとも24/7負荷か？
- ブランチングが実際のワークフローで意味があるか（PRごとにブランチ作るか）？
- バックアップ/PITR RPO·RTO数値は？
- コネクションプーラ戦略は決まったか（HTTPドライバ vs PgBouncer vs RDS Proxy）？
- スキーマ変更プロセスは？Atlas/pgroll/Deploy Request?
- 観測性スタック（Datadog·Grafana·pg_stat_statements）と統合可能か？
- ロックインコスト（離脱の辛さ）を計算したか？
- 3年後のデータ量·トラフィックで価格モデルが有効か？
よくある間違い10個
- 「ただのPostgres」とひとくくりにする — RDS/Aurora/Neon/Supabaseは細部が異なる。
- 厳密一貫性を全テーブルに要求 — 80%は結果整合性で十分。
- マルチリージョンを「後で」に延期 — リファクタ地獄。
- ブランチ掃除をしない — Neon/PlanetScaleで数千ブランチ積み上がり → コスト爆発。
- コネクションプーラなしのサーバーレス — サービスダウン最多原因。
- ベンダーロックを問わず — Spanner·DSQLは離脱難。
EXPLAIN ANALYZEを回さない — 分散DBほど実行計画重要。- タイムゾーン混乱 — UTC保存、表示時のみ変換。
- 外部キーなしで始める — 後付けが非常に高価。
- 「DBは変えなくていい」 — 5年以上のサービスなら1回は移行する。抽象化レイヤを先に。
次回予告
シーズン7 第4回はメッセージキューとイベントストリーミング 2025 — Kafka·Pulsar·NATS·Redpanda·NSQ·pgmq·AWS SQS/SNS·GCP Pub/Sub の比較。分散トランザクションの難しさ、イベントソーシングとCQRSの実戦、Exactly-onceが嘘である理由まで。
— 分散データベース編、完。