YugabyteDBとは？分散SQLの仕組み・YSQLのPG15系移行と採用判断を実装者目線で解説

YugabyteDBは、Google Spannerの設計に着想を得た分散SQLデータベースです。コア部分はApache License 2.0で公開され、PostgreSQL互換のYSQLとCassandra互換のYCQLという2つのAPIを持ちます。この記事では、YB-MasterとYB-TServerとDocDBの役割分担、v2025.1でPostgreSQLフォークが11.2から15.0へリベースされて変わった互換範囲、版で既定が入れ替わる分離レベル、マルチリージョン配置の8パターン、Aeonの課金構造を整理し、採用条件と見送る場面を示します。

まとめ：YugabyteDBの採用条件と単一ノードPostgreSQLに留める判断

結論から書きます。YugabyteDBを選んでよいのは、複数リージョンやマルチAZで強い整合性を保ちたい、PostgreSQLのスキーマとドライバ資産をそのまま持ち込みたい、Apache 2.0であることが調達要件に入っている、この3つが同時に成立する案件だけです。1つでも外れるなら単一ノードのPostgreSQLかマネージドRDBのほうが総保有コストで勝ちます。

見送る場面も明確です。単一AZで完結する社内システム、データ量が数百GB以下で書き込みが秒間数百件に届かない規模、排他制約やGiST索引に依存した既存スキーマの移行案件。この3つでは分散化の利得より、ノード数の増加と非対応機能の回避コストが上回ります。

版の選び方も先に置きます。2026年8月時点で新規に本番採用するなら、PostgreSQL 15系を土台とし保守が2027年12月11日まで続くv2025.2（LTS）が基準線です。

YB-MasterとYB-TServerとDocDBに分かれる内部構造の役割分担

プロセスは2種類しかありません。クラスタ全体の状態を管理するYB-Masterと、クエリを処理してデータを持つYB-TServerです。

YB-Masterがメタデータを管理しRaftで3台に固定される理由

YB-Masterが持つのは、テーブル定義、tabletの配置、ノードの生死といったメタデータです。この情報自体もRaftで複製されるため、複製係数（RF）が3の構成ではノード数が10台でも50台でもYB-Masterは3インスタンスだけ。増えるのはYB-TServerだけです。YB-Masterが全滅するとスキーマ変更やtabletの再配置は止まりますが、既存のtabletリーダーが生きていれば読み書きは継続します。

YB-TServerのクエリ層とストレージ層に分かれる処理経路

YB-TServerは内部で2層に分かれます。上のクエリ層がYSQLとYCQLの両方を受け付け、下のストレージ層でDocDBという分散ドキュメントストアがtabletを保持します。

YSQLのクエリ層は、PostgreSQLのソースをフォークした実体そのもの。パーサ、プランナ、実行器はPostgreSQL由来のコードが動き、ストレージアクセスだけがDocDBへ差し替わっています。互換性の広さと索引まわりの非対応が同居するのは、この構造が理由です。

tabletへの自動分割とRF3のリーダーとフォロワーの構成設計

テーブルは作成時にtabletへ自動分割され、各ノードへ配られます。同じtabletの複製同士はtablet peerと呼ばれ、1つのリーダーと複数のフォロワーでRaftグループを構成。読み書きは原則としてリーダーへ向かいます。

分割の考え方は一般的な水平分割と同じ枠組みで、シャードキー設計と水平分割の勘所を押さえると当たりがつきます。YugabyteDBが引き受けるのは分割の実行と再配置までで、どの列で分けるかの判断は利用者側に残ります。

リーダー障害時に約3秒で自動昇格するフェイルオーバの前提と限界

リーダーが落ちると、同じRaftグループのフォロワーが自動的に昇格します。公式ドキュメントが示す所要時間は約3秒。複製が同期方式のため、コミット済みデータが失われることはありません。

ただし3秒は「無停止」ではありません。切り替え中に該当tabletへ向かったトランザクションは失敗し、アプリ側にリトライがなければそのままエラー応答として利用者へ届きます。同期と非同期の差は同期複製と非同期複製の違いと遅延の設計で整理しています。

YSQLのPostgreSQL 15系リベースと互換性の実際の線引き

YugabyteDBの評価が数年前の記事と食い違う最大の原因が、この節です。YSQLの土台となるPostgreSQLの版が最近になって大きく動きました。

v2025.1でPG11.2からPG15.0へ移行したフォークの系譜

YSQLは長らくPostgreSQL 11.2のフォークでした。これがPostgreSQL 15.0へリベースされ、その最初の安定版がv2025.1（STS・2025年7月23日）です。生成列（stored generated columns）、パーティション表への外部キー、一意索引におけるNULLの非DISTINCT扱いなど、11から15の間に入った機能がYSQLでも通るようになりました。

版跨ぎの更新はオンラインで行えます。v2024.2（PG11系）からv2025.1以降（PG15系）へ上げる場合は追加手順が要るものの、作業中も読み書きは維持される設計。裏を返すと、PG11系の情報だけを見て判断すると、2026年時点では古い前提で設計することになります。

排他制約やGiST索引など非対応となる機能の具体と回避策の判断

互換といっても全機能ではありません。移行前の検査で引っかかりやすい非対応機能を影響順に並べます。

• 排他制約（EXCLUDE）と遅延制約（DEFERRABLE）
• GiST索引、および複数列のGIN索引
• LISTEN/NOTIFY（v2025.2.3.0でEarly Access扱い）
• INET、CITEXT、JSONB、配列といった型への索引
• UNLOGGEDテーブル、制約トリガ、トリガのREFERENCING句
• XML関数、および一部のALTER TYPE・ALTER TABLEの構文

実務で詰まるのは上の2つです。期間の重なりを排他制約で防ぐ予約系スキーマは、アプリ側の直列化かSerializable分離レベルでの検査へ置き換えないと移行できません。GiST索引に依存した地理空間検索も同様で、代替索引がないなら移行対象から外します。

Cassandra互換APIのYCQLを併設するかどうかの判断基準

YCQLは同じクラスタ上でYSQLと併存できますが、1つのデータを両方から触ることはできず、所属はテーブル単位で決まります。併設が効くのは、時系列ログのような単純キー参照の大量書き込みと業務データのリレーショナル参照を1つの基盤へまとめたい場合だけ。参照系がすべてSQLで書けるなら足す理由はありません。

3つの分離レベルと版ごとに変わる既定値が設計に及ぼす影響の範囲

分散トランザクションの挙動は、単一ノードのPostgreSQLからの移行で最も静かに壊れる部分です。名前こそPostgreSQLと揃っていますが、既定値が版で入れ替わります。

Read Committedとスナップショットと直列化の対応関係

YSQLが持つ分離レベルは、Read Committed、Snapshot、Serializableの3つ。このうちSnapshotがSQL標準のRepeatable Readに相当します。Read Uncommittedを指定しても実際にはRead Committedとして動くため、実質的な選択肢は3択です。

各レベルが何を保証するかはACID特性と分離レベルの整理と共通で、読み取りが過去版を見る仕組みは多版型同時実行制御の動きに沿います。固有なのは、これらが分散環境で成立するようRaftとハイブリッド論理クロックの上に載っている点です。

v2025.2で既定がRead Committedへ変わる前後の移行注意

既定値の扱いに版差があります。v2025.2以降はRead Committedが既定で有効。それより前の版ではRead Committedが無効なためSnapshotへフォールバックしていました。同じアプリを版違いのクラスタへ載せると、明示的にレベルを指定していない限り挙動が変わります。

移行時の注意はこうです。PostgreSQLの既定はRead Committedなので、v2024.2以前のYugabyteDBへそのまま載せるとSnapshotで動き、更新競合時にシリアライズエラーが返る頻度が上がります。移行前に接続文字列かセッション設定でレベルを明示し、版に依存しない状態を作っておくほうが安全です。

マルチリージョン配置の8パターンと同期・非同期複製の選び分け方

YugabyteDBを選ぶ動機の大半は地理分散にあります。公式ドキュメントは配置パターンを8種類に整理しており、「同期か非同期か」「RPOがゼロか否か」の2軸で並べ直すと選定が速く進みます。

Global Databaseの同期複製が求めるリージョン間の距離

Global Databaseは、1つのデータベースを複数リージョンへ同期複製で広げる構成です。リージョン障害時はフォロワーが昇格し、データ損失は生じません。RPOはゼロ。

代償は書き込みレイテンシです。コミットには過半数のリージョンからの応答が要るため、往復時間がそのまま書き込み遅延へ乗ります。東京と大阪のように往復10ミリ秒台なら実用範囲。東京と米国東部をまたぐと1コミットあたり100ミリ秒超を見込む必要があり、この場合は地理分割か非同期構成へ倒します。

地理分割2種によるレイテンシ短縮とデータ所在地要件への対応方法

地理分割（geo-partitioning）は、テーブルをパーティション分割し、パーティションごとに配置先リージョンを固定する方式です。用途は2つに分かれます。

両者は排他ではありません。日本の利用者データを東京へ置けば、応答時間と国内保管の両方を満たせます。分割列は後から変えにくいため、テナントIDか国コードのどちらを軸にするかは設計初日に決めます。

フォロワー読み取りとRead Replicaで読みだけ寄せる構成

書き込みを1リージョンへ集約したまま読み取りだけ近くで済ませたい場合、選択肢は2つ。フォロワー読み取りは既存のRaftフォロワーから多少古いデータを読み、Read Replicaは投票に参加しないフォロワー専用クラスタを別に立てます。後者は投票に加わらないため、遠隔地に置いてもコミット遅延へ響きません。

Active-Active Multi-MasterでRPO非ゼロを許容する条件

両系で書き込みを受けるActive-Active Multi-Masterは非同期複製です。フェイルオーバは手動で、数秒ぶんのデータ損失が起こりえます。それでも選ぶ理由は書き込みレイテンシで、各リージョンがローカルにコミットするため地理的距離が応答時間へ乗りません。許容できるのは後追いで整合を取れる業務だけ。在庫引当のように二重確定が事故になるデータは載せません。

Apache 2.0のコア版とAeon課金から積み上げる費用の数え方

費用はライセンスと課金を分けて考えます。コアはOSSで無償、マネージドは従量の2階建てです。

コア機能がApache 2.0である前提と商用版との機能境界の線

コアデータベース部分はApache License 2.0で公開されており、自前のサーバへ何ノード立てても追加費用は発生しません。競合製品ではセルフホスト版のライセンス条件が見直された例もあり、その経緯はCockroachDBのライセンス変更と採用判断で扱っています。商用側は運用の自動化と保守を買う位置づけで、Anywhereが自社クラウド上での管理を、Aeonがフルマネージドを担います。

Aeonのティア別vCPU単価とストレージ・転送料金の加算構造

Aeonの費用はvCPU単価を土台に積み上がります。2026年8月時点の公開単価は次のとおりです。

見積もりで抜けやすいのが複製係数です。RF3ならノードは3の倍数で並ぶため、4vCPUのノード3台でも12vCPU分が課金対象。Standardなら月1,500ドルが下限の目安です。Enterprise SecurityとBusiness Continuity／DRは各25ドル／vCPU／月のアドオンで、Professionalに両方付けると実質217ドル／vCPU／月まで上がります。

LTSとSTSの系列とサポート期限から決める版の据え置き判断

リリースはLTS（長期サポート）とSTS（短期サポート）に分かれます。直近の系列は、v2024.2 LTS（2024年12月9日・PG11系）、v2025.1 STS（2025年7月23日・PG15系）、v2025.2 LTS（2025年12月11日）、v2026.1 STS（2026年6月29日）。本番の据え置き先はv2025.2 LTSを推します。保守が2027年12月11日まで、EOLが2028年6月11日と先が読め、かつPG15系の機能が使えるためです。新機能を試す環境だけSTSを当て、本番はLTSで揃える二本立てが運用しやすい形になります。

CockroachDBとTiDBとCloud Spannerに対する棲み分けの線

分散SQLの選定は、互換API、運用形態、ライセンスの3点でほぼ決まります。

PostgreSQL互換で並ぶCockroachDBとの分岐条件の作り方

CockroachDBもPostgreSQLワイヤプロトコル互換の分散SQLで、機能の重なりが最も大きい相手です。分岐は2点。1つはライセンスで、セルフホストを無償のOSSライセンスで通したいならYugabyteDBに寄ります。もう1つはPostgreSQL機能の再現度で、YugabyteDBはコードをフォークしているぶん拡張やプランナ挙動が本家に近い。逆にCockroachDBを選ぶのは、SQL層の独自実装を許容したうえで運用ツールとクラウドサービスの完成度を優先する場合です。

MySQL互換のTiDBとマネージド専業のSpannerとの距離

既存資産がMySQLなら比較対象はTiDBです。MySQL互換の分散SQLとHTAPの考え方を見たうえでアプリのSQL方言に合うほうを選ぶのが、手戻りの少ない順序になります。

Cloud Spannerはセルフホストという選択肢がない点で土俵が違います。Google Cloudに寄せきる前提が固まっているならTrueTimeを使う分散リレーショナルDBの構成が有力で、マルチクラウドやオンプレを残すならYugabyteDB側に分がある。単一リージョンでPostgreSQL互換の性能だけを求めるなら、分散SQLではなくPostgreSQL互換マネージドDBの構成と料金のほうが構成は単純に収まります。

Voyagerを使った既存PostgreSQLからの移行の当たり所

移行には公式のYugabyteDB Voyagerが用意されています。ただしツールが解決するのはデータとスキーマの搬送までで、前段のスキーマ検査は人の作業です。実務の順序はこうなります。まず既存スキーマから排他制約、GiST索引、UNLOGGEDテーブル、制約トリガを機械的に洗い出す。次にそれぞれを代替設計へ置き換えられるか判定する。置き換え不能な機能が業務の中核にあるなら、その時点で移行を止めます。順序を逆にすると、データを移し終えてから戻す羽目になります。

YugabyteDBを採用してよい条件と見送るべき失敗パターン

ここまでの材料をもとに、条件と結論を対で言い切ります。

YugabyteDBを採用してよい3条件と欠けた場合に取る判断

採用してよいのは次の3条件がそろう場合です。第一に、複数AZまたは複数リージョンにまたがってRPOゼロを要求される。第二に、既存のPostgreSQLスキーマとドライバをそのまま持ち込みたい。第三に、セルフホストをOSSライセンスで完結させたい、あるいはマルチクラウドとオンプレを残す必要がある。

1つでも欠けたときの代替は明快です。RPOゼロが不要ならPostgreSQLの非同期レプリカで足り、PostgreSQL資産がないならTiDBやSpannerも同列に並ぶ。単一クラウドに寄せきってよいならマネージドサービスのほうが運用工数で勝ちます。

単一AZ運用や非対応機能への依存で見送りに倒す失敗パターン3件

失敗するのは次の3パターンです。

1. 単一AZの社内システムに導入し、最低3ノードの運用負担だけが増えた
2. 排他制約やGiST索引に依存した既存スキーマを移行途中で断念した
3. PG11系のv2024.2で構築し、生成列が使えず後から版跨ぎの更新が発生した

3件とも事前調査で防げます。1つ目は要件のRPO・RTOを数値で確認するだけ、2つ目は移行前のスキーマ検査だけ、3つ目は構築時にLTSの系列とPostgreSQL版の対応を見るだけ。時間を使うべきなのは性能検証ではなく、この3点の事前確認です。

導入初日に決めるシャードキーと配置と版に関する設計5項目の順序

後戻りしない項目を、決める順に並べます。第一にシャードキー（テナントIDか国コードか業務キーか）。第二に配置パターン（Global Databaseか地理分割か非同期構成か）。第三に複製係数とAZ配置。第四に採用する版の系列（LTSかSTSか）。第五に分離レベルの明示指定。

この5つは相互に依存します。配置パターンを決めないとシャードキーが選べず、版を決めないと使える機能が確定しません。DBそのものの選定に迷う段階なら、RDBとNoSQLの選び分けから戻ったほうが早く着地します。要件整理から配置設計、移行の実装までを外部と組んで進めるなら、データ分析基盤構築・MLOps構築支援で分散DBを含むデータ基盤の設計と構築を承っています。

よくある質問

実際に検索されている質問へ、判断材料の形で答えます。

YugabyteDBはPostgreSQLとどこまで互換ですか？

YSQLはPostgreSQLのソースをフォークした実装で、v2025.1以降はPostgreSQL 15.0が土台です。生成列やパーティション表への外部キーも使えます。一方で排他制約、遅延制約、GiST索引、複数列GIN索引、UNLOGGEDテーブル、XML関数などは非対応。ドライバはワイヤプロトコル互換でそのまま接続できますが、スキーマは移行前に非対応機能の有無を検査してください。

YugabyteDBは無料で使えますか？

コアデータベース部分はApache License 2.0で公開されており、自前のサーバへ何ノード立てても追加費用はかかりません。有償になるのはマネージドのYugabyteDB Aeonと、自社クラウドでの管理を担うAnywhereです。Aeonの公開単価はStandardが125ドル／vCPU／月、Professionalが167ドル／vCPU／月。これにストレージ0.10ドル／GB／月やデータ転送料が加算されます。

YugabyteDBとCockroachDBはどちらを選ぶべきですか？

ライセンス条件とPostgreSQL機能の再現度を優先するならYugabyteDBです。コアがApache 2.0のままで、SQL層がPostgreSQLのフォークであるため既存資産との相性が良くなります。運用ツールの成熟度を優先する場合はCockroachDBも候補に残る。機能表で比べるより、手元のスキーマとクエリを両方へ流して通るかを見たほうが速く決まります。

単一リージョンでYugabyteDBを使う意味はありますか？

マルチAZ構成で自動フェイルオーバを求めるなら意味があります。RF3でAZをまたいで配置すれば、AZ障害時も約3秒でリーダーが昇格し、データ損失なく継続します。逆に単一AZで完結する構成では利得がほとんどなく、最低3ノードの運用が要るぶん単一ノードのPostgreSQLのほうが総保有コストで有利です。

既存のPostgreSQLからどう移行しますか？

公式のYugabyteDB Voyagerがスキーマとデータの搬送を担います。ただし作業順序が結果を左右します。搬送より先に、既存スキーマから排他制約、GiST索引、UNLOGGEDテーブル、制約トリガを洗い出し、代替設計へ置き換えられるかを判定してください。置き換え不能な機能が業務の中核にあるなら、その時点で移行を止めるのが安全です。

関連記事

• CockroachDBとは？分散SQLの仕組みとライセンス変更：最も比較対象になる分散SQLです
• TiDBとは？MySQL互換の分散SQLとHTAP：既存資産がMySQLの場合の比較先です
• Cloud Spannerとは？TrueTimeと採用判断：マネージド専業との距離を測れます
• AlloyDBとは？構成・カラム型エンジン・料金：単一リージョンで済む場合の代替です
• Neonとは？サーバーレスPostgresの構成と料金：PostgreSQL互換の別方向の選択肢です