# 分散 PostgreSQL ## 定義 分散 PostgreSQL は、PostgreSQL の SQL・トランザクション・DDL・エコシステム互換性を保ちつつ、複数ノードへデータとクエリ処理を分散するデータベースシステム設計である。中心課題は、単一プライマリ PostgreSQL の書き込みスループット、ストレージ容量、接続数の限界を超えながら、アプリケーション側シャーディングの負荷を減らし、強い整合性と PostgreSQL 的な操作感をどこまで維持できるかにある。([[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) ## 横断的知見 - **分散 PostgreSQL は「既存 RDBMS のオーバーヘッド除去」ではなく「互換性を残したまま分散化する」方向で OLTP アーキテクチャ問題へ答える**: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]] は、伝統的 RDBMS のバッファ管理・ロック・ログ・ラッチを削る専用設計を示した。一方 [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] は、PostgreSQL の豊富な機能と既存アプリケーション資産を前提に、ルータ/シャード分離、時刻ベース MVCC、2PC、pushdown で水平スケールを加える。両者は「OLTP を速くする」同じ問題に対し、再設計と互換拡張という異なる制約条件を置いている。(Source: [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]], [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) - **長寿命データシステムは、中核モデルを維持しながら周辺層で分散化・運用化を進める**: Bigtable 20 年史では多次元疎マップとタブレットという中核を保ったまま SQL、CDC、レプリケーション、オートサイジング、SRE 運用を追加した。Aurora Limitless では PostgreSQL 互換性と Aurora ストレージを残したまま、ルータ、シャード、Time Sync、Serverless V2、シャード分割を追加する。どちらも、利用者が依存する中核抽象を保ち、周辺機構で規模と運用性を伸ばすパターンである。(Source: [[@2026__SIGMOD Companion__Twenty Years of Bigtable]], [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) - **分散 DB のスケーリングはデータ分割だけでなく、時刻・DDL・バックアップ・クエリ最適化を含む全体設計になる**: Aurora Limitless は、shard key と table slice による分割だけでなく、Time Sync によるスナップショット、lead shard 付き 2PC、DDL のクラスタ全体原子可視化、時刻付きバックアップ、predicate/join/aggregation pushdown を合わせて設計する。これは「シャードを増やす」だけでは PostgreSQL 互換の分散 OLTP にならないことを示す。(Source: [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]]) ## 未解決の問い - shard key 選択が一方向の設計判断になりやすいとき、既存 PostgreSQL アプリケーションのスキーマとクエリをどこまで自動分析して移行支援できるか。 - Time Sync のような高精度時刻サービスを使えるクラウド環境と、一般的なオンプレミス/マルチクラウド環境では、外部整合性とレイテンシのトレードオフはどう変わるか。 - PostgreSQL の schema evolution、commit order、visibility order など、単一ノード由来の意味論を分散環境へ持ち込むとき、どの振る舞いを維持し、どれを近代化すべきか。 - serializability を要求するワークロードでは、Aurora Limitless 型の snapshot isolation + external consistency と、Spanner/CockroachDB/YugabyteDB 型の強い分離レベルの差は実アプリケーションでどう現れるか。 ## 関連 - ソース: [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] - システム: [[Aurora Limitless Database]] - 隣接 concept: [[OLTPシステムアーキテクチャ]] / [[分散ストレージ]] / [[データベース O&M]] / [[専用データベースシステム]] ## 出典 - [[@2026__SIGMOD Companion__Aurora PostgreSQL Limitless Database - Building a Highly Scalable OLTP Database]] - [[@2008__SIGMOD__OLTP through the looking glass, and what we found there]] - [[@2026__SIGMOD Companion__Twenty Years of Bigtable]]