Skip to content
Published on

分散SQL / NewSQL 2026 — CockroachDB / TiDB / YugabyteDB / Spanner / Aurora DSQL / Neon 徹底比較

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

プロローグ — 「NewSQL」という単語ではもう括れない風景

2012年に「NewSQL」という単語が初めて使われたとき、定義はすっきりしていた。OLTPワークロードをNoSQL並みに水平スケールしつつ、ACIDとSQLを保つデータベース。 Spanner論文が同じ年に出て、CockroachDBとTiDBがその直後に始まった。当時、候補は片手で数えられた。どこも似た約束をした — 「シャードの手動運用を終わらせる」。

2026年の風景は、その一語では括れない。分散SQLは少なくとも3つに枝分かれしている。

  • True distributed(シェアードナッシング+合意): CockroachDB、TiDB、YugabyteDB、Spanner、Aurora DSQL。すべてのノードが対等で、RaftやPaxosで合意し、リージョンを跨ぐ。
  • Sharded SQL(オーケストレーション層): Vitess(MySQL)、Citus(Postgres)、PlanetScale Metal。ノードは依然として通常のMySQL/Postgresで、その上にルーター/コーディネータが乗る。
  • Serverless Postgres(ストレージ/コンピュート分離): Neon、Aurora Serverless v2、Xata。1つのインスタンスを分散させるのではなく、ストレージが別の分散システムで、コンピュートをゼロにスケールできる。

この3つを同じ「分散SQL」という傘の下で比較しようとすると、ほとんどの比較が意味を失う。Aurora DSQLとNeonはどちらもPostgres互換だが、前者はマルチリージョンのactive-active OLTPを、後者はシングルリージョンでコンピュートを0に絞ることを狙っている。CockroachDBとPlanetScaleはどちらも「水平スケールするSQL」と謳うが、片方はすべてのトランザクションを合意で調整し、もう片方はシャードキーで先に切り分ける。

本稿は12のシステムを1つの表に押し込まない。代わりに各システムが何を優先したかを一行で示し、合意・MVCC・ハイブリッド論理クロック・オンラインスキーマ変更という共通語彙で比較し、最後に「グローバル / SaaSマルチテナント / HTAP / サーバレス」という4つの用途で誰を選ぶべきかまで書く。

1. 2026年の分散SQLマップ — 3つの軸

まずは一枚の絵。

                    [SQLを水平にスケールする]
                            |
        +-------------------+-------------------+
        |                   |                   |
[True Distributed]    [Sharded SQL]      [Serverless Postgres]
   合意アルゴリズム      外部コーディネータ      ストレージ/コンピュート分離
        |                   |                   |
   CockroachDB 24       Vitess               Neon (Databricks)
   TiDB 8               Citus / Cosmos PG    Aurora Serverless v2
   YugabyteDB           PlanetScale (Metal)  Xata
   Google Spanner
   Aurora DSQL (GA)
   AlloyDB Omni

この図が一冊分の差異を一ページに圧縮する。同じ軸上のシステムは互いに直接の代替だが、別の軸のシステムとは多くの場合併存する。例えば1つのSaaSがNeonをメインOLTPに、CockroachDBをグローバルなメタデータ保管庫に並べて使うのは2026年にはありふれたパターンだ。

各軸には次のような前提が敷かれている。

軸既定の仮定失うもの得るもの
True distributedすべてのトランザクションは合意で調整される単一リージョンOLTPのレイテンシ下限マルチリージョンactive-active、自動リバランス
Sharded SQLシャードキーが良ければ合意は不要クロスシャードトランザクションの安さ単一ノードOLTPレイテンシの維持
Serverless Postgresコンピュートは小さく、頻繁にオンオフされるマルチリージョン書き込み分単位課金、即時ブランチ

この3つのどれが自分のワークロードに合うかを決めずに道具を比較すれば、答えは出ない。だから1章はこの一枚で終える。

2. CockroachDB 24 — ライセンス変更後の座標

CockroachDBは2024年8月に最大の外部事件を迎えた。Cockroach LabsはBSL(Business Source License)からさらに進み、すべての新リリースを実質的にプロプライエタリ(ソース閲覧可、商用利用制限あり)に転換した。 既存のv23.x以前のApache 2.0コードはそのままだが、v24以降はセルフホスティングをするにはエンタープライズ契約が必要になった。

この変更には2つの効果があった。

  • Cockroach Cloudユーザーへの影響はほぼゼロ。 価格はわずかに調整されたが、機能はそのまま。
  • セルフホスティングのOSSユーザーはv23.xに残るか、別の道を探した。 一部はYugabyteDB(Apache 2.0維持)へ、一部はPostgres + Citusへ、一部はそのままv23.xに留まった。

ライセンス論争を脇に置けば、v24の技術的変化も小さくない。

  • PostgreSQL 17ワイヤ互換の強化。 Cockroachは当初からPostgresワイヤを使ってきたが、v24でシーケンス・トリガー・CTE・拡張関数の互換性がさらに狭まった。
  • マルチリージョンがよりシンプルに。 ALTER DATABASE ... PRIMARY REGION = 'aws-us-east-1' のような一行でリージョンポリシーが設定できる。
  • Vector型を追加。 pgvector互換のベクトルインデックスがv24.1で入り、RAGワークロードをCockroach内に置く例が増えた。
  • Logical Data Replication。 v24.2から、2つのクラスタ間で双方向active-active複製がベータで入った。

CockroachDBの中核資産は依然として Raftベースの合意でマルチリージョン書き込みを自動化する点にある。 あるキーの書き込みはすべてそのキーのRaftグループリーダーへルーティングされ、リーダーが過半数のレプリカへログを複製してからコミットされる。マルチリージョンクラスタにおいてリーダーがどこに居るかがレイテンシを決める。REGIONAL BY ROWは行ごとにホームリージョンを別々に置き、GLOBALテーブルはすべてのリージョンで高速に読まれる。

-- マルチリージョンテーブルの例
CREATE DATABASE app PRIMARY REGION 'aws-us-east-1'
  REGIONS 'aws-us-east-1', 'aws-eu-west-1', 'aws-ap-northeast-1';

ALTER TABLE app.users SET LOCALITY REGIONAL BY ROW;
ALTER TABLE app.products SET LOCALITY GLOBAL;

CockroachDBが得意な場所ははっきりしている。マルチリージョンOLTP、強整合性、自動フェイルオーバー。 苦手な場所もはっきりしている。シングルリージョンの単一ノードワークロードでは、素のPostgresの方が速くて安い。

3. TiDB 8(PingCAP) — HTAPを本番に降ろした場所

TiDBは初日から2つを狙った。MySQLワイヤ互換 + 行/列ストアの同時運用。 8.xシリーズ(2024-2025)でその両方が磨かれた。

  • TiKV(行ストア)+ TiFlash(列ストア) が同じRaftグループのラーナー(learner)レプリカとして繋がる。同じトランザクションがOLTPとOLAPの両側で一貫したスナップショットとして見える。
  • Pinterest、Square、Shopee がペタバイト規模で運用している事例を公開している。Pinterestは広告メトリクス、Shopeeはeコマースの注文・在庫、Squareは決済分析。
  • TiDB Serverless(2024投入、2025正式GA) は使用量課金と自動スケーリングを持ち込んだ。新規SaaSが入る際に最もよく挙がる選択肢。
  • HTAPクエリのルーティング はオプティマイザが自動でやる。SELECT COUNT(*)のように集計が重ければTiFlashへ、単件参照はTiKVへ流れる。

アーキテクチャは綺麗に3層に分かれる。

+----------+   +-------+   +--------+
| TiDB SQL |-->|  PD   |-->|  TiKV  |  (行ストア、Raft)
+----------+   |(Meta) |   +--------+
                 |             |
                 v             v
              ratchet     +---------+
                          | TiFlash | (列ストア、Raftラーナー)
                          +---------+

PD(Placement Driver)はメタデータ・リージョンマッピング・リーダー選出を担い、TiKVはキー範囲でリージョン単位にデータを置き、TiFlashは同じデータの列形式コピーをラーナーレプリカとして持つ。SQLノードはステートレスなので自由に増減できる。

MySQLワイヤ互換は5.7から始まり8.xへ上がってきた。名前が同じでも100%互換ではない。トリガー、外部キー制約(部分対応)、一部のストアドプロシージャは違う挙動を示すことがある。

TiDBの得意領域。MySQL互換が必要なSaaS、HTAPが必要なワークロード、ペタバイト級水平スケール。 弱点は運用の複雑さ(3種類のノード管理)とRAM要件。

4. YugabyteDB — Postgres互換分散の安定した一席

YugabyteDBは2つのAPIを持つ。YSQL(PostgreSQLワイヤ + Postgresコードの一部を流用) と YCQL(Cassandraワイヤ互換)。実戦ではほぼYSQLが使われる。

設計上の決定的な違いは、Postgresのクエリレイヤーのコードをほぼそのまま再利用する点だ。 CockroachDBは最初からGoで書き直したが、YugabyteDBはPostgresのコードを分散ストレージ(DocDB)の上に乗せる道を選んだ。そのおかげで拡張関数・トリガー・ストアドプロシージャの互換性が相当に高い。Postgresで動いていたバックエンドコードの移行の摩擦が小さい。

DocDBはRocksDB + Raftの組み合わせで、CockroachDBのストレージエンジンと概念的に似ているが、キーエンコーディングとトランザクションマネージャが異なる。Hybrid Logical Clock(HLC) でマルチリージョントランザクション順序を決める。

YugabyteDBの2026年の座標は2つに整理される。

  • CockroachDBのライセンス離反の受け皿。 v2.20以降、Apache 2.0維持が明示的なマーケティングポイントになった。セルフホスティングを希望するOSS陣営の一部が移った。
  • Postgres互換が本物の互換だという評判。 Django、Rails、Hibernate などのORM互換は比較的滑らか。

YugabyteDBが得意な場所。Postgres互換を保ちつつグローバル分散が必要なワークロード、Apache 2.0が重要なセルフホスティング。 弱い場所。分散環境でクエリオプティマイザが常に最良のプランを出すわけではないので、巨大なJOINはチューニングが必要なことが少なくない。

5. Google Spanner — 外部一貫性のチャンピオン

Spannerは他のすべての分散SQLの基準点だ。2012年のOSDI論文から14年が経った今も、中核資産は 外部一貫性(external consistency) にある。すべてのトランザクションはグローバルに合意されたタイムスタンプを受け取り、世界中どこから読んでも、そのタイムスタンプ以降のトランザクションしか見えない。

この保証を可能にするのが TrueTime API だ。GPSと原子時計を背景に、Googleデータセンターのすべてのノードが「現在時刻はこの区間にある」という狭い不確実性区間(通常7ms以下)を知る。トランザクションはこの区間が経過するまで待ってからコミットされ、その結果、時計同期の仮定なしにグローバル順序を保証する。

2026年のSpannerは次の変化を経た。

  • PostgreSQLインターフェースが正式GA後、広く採用された。 Spanner SQLが独自方言だった時代を越えて、いまやPostgreSQLワイヤでアクセスできる。
  • Spanner Graph(2024年投入) がSQL内でグラフクエリをサポート。GRAPH_QUERY構文がISO GQLに準拠。
  • ベクトル検索の統合。 Vertex AIのエンベディングをそのまま索引できる。
  • Spanner Data Boost — サーバレス分析コンピュートがOLTPに影響を与えずに大規模集計を処理する。

Spannerの弱点は長く変わらない。安くない。 最小ノード費が他のOLTP DBと比較にならず、トラフィックが軽いSaaSではCloud SQLの方がずっと合理的。GCPの外では使えない。

Spannerが得意な場所。グローバルSaaS、外部一貫性がビジネス要件である金融/取引システム、ある場所の障害が別の場所を止めてはならないドメイン。

6. Aurora DSQL(2024.12 GA) — AWSの答案

Aurora DSQLは2024年のre:InventでGAが発表された。PostgreSQL互換 + マルチリージョンactive-active + サーバレス。 この3語が同時に並んだのはAWSの初の正式な応答だった。

設計の中核は トランザクションをリージョナルなクォーラムではなくグローバルなクォーラムにコミットする点だ。 通常のAuroraは1リージョン内に6つのコピー(3 AZ × 2)を保つが、DSQLは複数のリージョンが共同でトランザクション順序を決める。

簡略化したDSQLのトランザクションフロー。

1) クライアント → 最寄りリージョンのendpointでBEGIN
2) クエリはローカルでOCC(楽観的同時実行制御)で実行
3) COMMIT時にグローバルtimestampサービスが順序を決定
4) StorageレイヤーにそのtimestampでWrite
5) すべてのリージョンが同じ順序で見える

OCCベースである点が重要。衝突が起きたら片方がリトライする。 すべての書き込みが同じ行を狙うワークロードには向かない。逆に衝突が稀でマルチリージョンactive-activeが本当に必要なワークロードには強力な選択肢。

2025-2026の間にDSQLは次を追加した。

  • 3リージョンクラスタの正式サポート(初期GAは2リージョン)。
  • IAM認証 + Secrets Managerとの統合。
  • CDCによるKinesis Data Streamsへの出力。
  • Aurora PostgreSQLからの移行ツール。

DSQLが得意な場所。AWS内でマルチリージョンactive-active OLTP、Postgres互換、運用自動化を重視するチーム。 苦手な場所。ホットキー書き込み、OCC衝突の多いパターン、Postgresの全拡張(特にPL/Pythonのようなサーバサイドコード)が必要な場合。

7. AlloyDB(Google) — Postgres + 分析をシングルリージョンで

AlloyDBはSpannerと同じ場所には立たない。シングルリージョン内でPostgresを速く + 分析を併せ持つ。 グローバル分散を狙わない。代わりにGoogleが内部で磨き続けてきたストレージレイヤー(Disaggregated storage)と列エンジン(Columnar engine)をPostgresと組み合わせる。

AlloyDBの差別化ポイント。

  • Postgres 100%互換。 拡張・トリガー・関数がそのまま動く。
  • Columnar engine。 同じデータをメモリ上に列形式でも保持し、集計クエリが標準Postgresの数十倍速い。
  • AlloyDB Omni。 同じエンジンをGCP外(オンプレ、他クラウド)でも動かせるコンテナデプロイ版。
  • AlloyDB AI(2024投入) — pgvector + Vertex AIエンベディングを同一トランザクション内で呼ぶ。

AlloyDBが得意な場所。シングルリージョン内でPostgres OLTP + 軽いOLAPを同居させるワークロード、すでにGCPにいてSpannerは過剰な場合。 苦手な場所。マルチリージョンactive-active、他クラウドのマネージドオプション。

8. Citus / Azure Cosmos for Postgres — シャーディングPostgresの正道

Citusは2011年に始まり、2019年にMicrosoftに買収され、2022年に Azure Cosmos DB for PostgreSQL にリネームされた。しかしOSS版(Citus extension)はApache 2.0で生き続けており、素のPostgresに CREATE EXTENSION citus を叩くだけで動く。

Citusのモデルはシンプルだ。分散テーブル(distributed table)と参照テーブル(reference table)。

-- 分散テーブル: tenant_idでシャーディング
SELECT create_distributed_table('users', 'tenant_id');

-- 参照テーブル: すべてのノードに複製される
SELECT create_reference_table('countries');

各ワーカーノードはただの普通のPostgresだ。コーディネータがクエリを受け取り、シャードキーに応じてワーカーへルーティングする。同じシャードキーの行は同じワーカーに集まるので、単一テナントのトランザクションは単一ノードのトランザクションになる — これがCitusがSaaSマルチテナントに合う理由だ。

Citusの限界もはっきりしている。シャードキーを跨ぐトランザクションは2PC(2フェーズコミット)に頼る。グローバルな自動フェイルオーバーは無い — それはホスト側の仕事。マルチリージョンactive-activeも無い。

Citusが得意な場所。SaaSマルチテナント(tenant_idで自然にシャード)、時系列データ(時間カラムでシャード)、シングルリージョン内でPostgresを100TB以上に伸ばす場合。

9. Vitess — MySQLシャーディングの標準として生き残った場所

VitessはYouTubeで始まった。2010年代半ばにCNCFに入り、MySQLを数十PBへ伸ばした実戦事例が多い — Slack、Square、GitHubの一部データセットがVitess上にある。

VitessのモデルはCitusに似ているが、MySQLを話す点が違う。

[Client] → [VTGate] → [VTTablet] → [MySQL shard]
              |           |
       (ルーター/QP)  (管理デーモン)

VTGateがSQLを受け、VSchema(シャーディング規則)に従って適切なVTTabletへ送る。各VTTabletは1つのMySQLインスタンスをラップし、バックアップ・複製・フェイルオーバーを管理する。

Vitessの強み。

  • 水平スケールするMySQL。 1クラスタで数万のシャードを運用する事例が公開されている。
  • オンラインスキーマ変更。 gh-ost / pt-online-schema-change と統合されたワークフロー。
  • CNCFガバナンス。 単一ベンダーロックインが無い。

Vitessの弱み。

  • 普通のMySQLオペレーターが初めて触ると運用の複雑さに圧倒される。
  • クロスシャードトランザクションは可能だが高い。
  • MySQL以外のワークロードには意味が無い。

10. PlanetScale — VitessからPostgres / Metalへ(2024)

PlanetScaleは2018年にVitessをマネージドサービスとして包んで始まった。2021-2023年の間に「ブランチを作って、デプロイ直前にマージする」というワークフローで開発者のマインドシェアを掴んだ。そして2024年に大きく2つを変えた。

  • 無料ティアの廃止(2024年4月)。 価格政策の変更で小さなサイドプロジェクトは他所へ流れた。これがNeon・Supabase・Turso のような代替の採用を加速した。
  • PlanetScale Postgres + Metalの発表(2024年後半)。 MySQLシャーディング専門というイメージから離れ、Postgres + ベアメタルNVMeという新たな路線を加えた。

Metalは興味深い決定だ。NVMeに直結したベアメタルインスタンス上でPostgresを走らせ、バックアップ・複製をPlanetScaleが管理する。 AWS Auroraのようにストレージを分離せず、ローカルディスクのIOPSをそのまま使う。シングルインスタンスのOLTP性能でAurora/RDSを上回るベンチマークが公開された。

PlanetScaleの2026年の座標。

  • MySQL / Vitess — 依然としてメイン製品。大型顧客はそのまま。
  • PostgreSQL / Metal — 新規顧客向けの第2トラック。シングルインスタンスで非常に速いPostgresが必要な場面で強い。
  • 開発者ワークフロー(ブランチ、deploy request) が両トラックに共通で敷かれる。

11. Neon — サーバレスPostgres + Databricks買収(2025)

NeonはPostgresを2つに分けた。コンピュート(EC2のようなステートレスPostgresプロセス)とストレージ(独自の分散ページサーバ)。 コンピュートはオンオフし、ストレージはS3にページを永続化する。

この分離の結果は3つ。

  • 0までスケールするコンピュート。 トラフィックが無ければコンピュートが止まり費用が0になる。リクエストが来ると1-2秒で復帰する。
  • 即時ブランチ。 同じページをcopy-on-writeで共有するので、100GBのデータベースのブランチが1秒以内にできる。
  • タイムトラベル。 ページ履歴が保存されるので、過去の任意時点に復元できる(point-in-time restoreが分単位ではなく秒単位)。

2025年5月に DatabricksがNeonを約10億ドルで買収した。 明示された理由はAIエージェントが自分の作業用にその場で作るデータベース — つまり「1万のエージェントが各自Postgresブランチを作る」シナリオで、Neonのブランチモデルが圧倒的だという判断だった。

買収以降、Neonは次を追加した。

  • Neon Auth。 認証/RBACのビルトイン。
  • Postgres 17サポート。
  • MCPサーバ統合。 Claude/CursorのようなAIコーディングツールから直接Neonインスタンスを作りクエリする。
  • Databricks Lakebaseとの統合 — Lakehouseデータを Postgresインターフェースで触る。

Neonが得意な場所。開発/ステージング環境のブランチ、トラフィックが波打つワークロード、AIエージェントの隔離された作業空間。 苦手な場所。マルチリージョンactive-active書き込み、1つのインスタンスを24/7フルで回す巨大OLTP(この場合は通常のAurora/RDSの方が安い)。

12. Xata — Postgres + 検索 + ファイルを1つのインターフェースで

Xataは別カテゴリに属する。Postgres + 検索(Elasticsearch互換)+ ファイル添付を1つのデータモデルにまとめたバックエンドプラットフォームだ。2024年からはホスティングPostgres自体もマネージドで提供する。

Xataの魅力は2つ。

  • REST/SDK先行。 Postgresワイヤでもアクセスできるが、第一インターフェースはTypeScript SDK。
  • 検索がファーストクラス市民。 同じテーブルに全文索引が自動生成され、fuzzy/typo-tolerantな検索がSQLと同じインターフェースで露出する。
  • ファイルカラム。 S3に保存されるがSQLカラムとして見える。

Xataが得意な場所。素早くMVPを立てるフルスタックアプリ、検索が必要なカタログ/CMS、バックエンドコードを最小化したいフロントエンドチーム。 苦手な場所。巨大OLTP、複雑なトランザクション、マルチリージョン分散。

13. Raft / Paxos / MVCC / HLC — 一行ずつの説明

ここまでのシステムを同じ語彙で比較するには4つの概念を押さえる必要がある。

1) Raft / Paxos(合意アルゴリズム)

複数のノードが同じログ順序に同意するためのプロトコル。Paxosは1989年に提案された原型で、証明が難しい。Raftは2014年に分かりやすさを優先して再設計され、その結果ほとんどのNewSQLがRaftを使う(CockroachDB、TiDBのTiKV、YugabyteDBのDocDB)。SpannerはMulti-Paxosの変種を使う。

一行要約。データをキー範囲で切り、各範囲ごとに3-5個のレプリカがRaftグループを成してリーダーを選びログを合意する。

2) MVCC(Multi-Version Concurrency Control)

読み書きが互いをロックで阻まないように、すべての行が複数バージョンを同時に持つモデル。トランザクションは開始時点のタイムスタンプ以前のバージョンしか見ない。Postgresが1990年代から使ってきたモデルで、CockroachDB/Spanner/TiDBもMVCCをやっている。

3) HLC(Hybrid Logical Clock)

物理クロックと論理クロックを合わせたクロック。ノード間でクロックが少しずれても、因果関係のあるイベント順序を保証する。CockroachDBとYugabyteDBはトランザクションのタイムスタンプ決定にHLCを使う。SpannerはHLCの代わりにTrueTimeを使う — 物理クロックの不確実性区間を直接推定する。

4) Online Schema Change

素のPostgres/MySQLで巨大テーブルにカラムを追加するのは、ロックを取って全行を再書き込みする高価な操作だ。分散SQLは通常 二重書き込み + 段階的バックフィル パターンでこれを解く — TiDBの ALTER TABLE は同期ロック無しで完了し、CockroachDBも同様、Vitessの gh-ost 統合も同じ発想。

14. 誰が何を選ぶべきか — 4つの用途

ここまで12のシステムを扱った。最後の章では 4つの用途別に最有力候補が誰なのか を整理する。正解は無い、最有力候補があるだけだ。

A) グローバルSaaS / マルチリージョンactive-active OLTP

  • 第一候補。Google Spanner(GCPなら)、Aurora DSQL(AWSなら)、CockroachDB(クラウド中立)。
  • 加点。外部一貫性がビジネス要件ならSpanner。
  • 注意。すべて高い。トラフィックが軽いのにマルチリージョンが必要に見えるなら、もう一度疑え。

B) SaaSマルチテナント(tenant_idで自然にシャード)

  • 第一候補。Citus / Azure Cosmos for Postgres、PlanetScale(Vitess/MySQLまたはMetal/Postgres)。
  • 加点。Postgres拡張を多用するならCitus、MySQL生態系に慣れているならVitess/PlanetScale。
  • 代替。TiDBもあり。シングルノード + 読み取りレプリカで始めるのが意外と長く十分である点を忘れるな。

C) HTAP(OLTP + 軽いOLAPを同じインターフェースで)

  • 第一候補。TiDB(TiKV + TiFlash)、AlloyDB(列エンジン)。
  • 加点。MySQL互換ならTiDB、Postgres互換ならAlloyDB。
  • 代替。重い分析はSnowflake/BigQuery/Databricksを別に持つのが標準 — HTAP1つに全部押し込むな。

D) サーバレス / ブランチ / 開発環境

  • 第一候補。Neon(Databricks陣営)、Aurora Serverless v2(AWS)、Xata(フルスタックバックエンド)。
  • 加点。AIエージェントインフラならNeonのブランチが圧倒的、AWS内で自動スケーリングが核ならAurora Serverless v2。
  • 代替。Supabase、Turso(SQLiteベース)も同じ枠の候補。ワークロードが本当にPostgresを必要としているかを先に問え。

最後に一行。分散SQLは答えではなく選択肢だ。 単一ノードPostgres1台で十分回るワークロードが2026年でも最も普通だ。グローバルactive-activeが本当に必要か、ただ「水平スケール」という単語が格好良く見えただけかを一度問い直してから始めよ。

参考 / References

Discuss on Twitter • View on GitHub