CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説

CockroachDBは、PostgreSQL互換のインターフェースを持つ分散SQLデータベースです。3台以上のノードにデータをレンジ単位で分割して複製し、Raftの合意で強い一貫性を保ったまま、ノードやリージョンの障害を越えて動き続けます。この記事ではv26.2（2026年4月27日GA）時点の一次情報をもとに、5層アーキテクチャの内部動作、マルチリージョンの生存目標とテーブルロカリティ、pgwireで持ち込める資産と書き換えが要る非互換点、2024年11月のライセンス変更で何が有償・無償になったのかを整理し、採用してよい条件と見送る場面を実装者の目線で示します。

まとめ：CockroachDBの立ち位置と採用可否を分ける3条件

CockroachDBは「PostgreSQLの顔をした分散データベース」です。アプリ側から見れば接続方法もSQLもPostgreSQLに近く、内部は複数ノードにレンジを配ってRaftで合意を取る分散システム。単一プライマリの垂直スケールで詰まる書き込みを、ノード追加で水平に伸ばせる点が既存RDBMSとの差分です。

採用可否は3条件で決まります。第一に、書き込みを分散させたい規模か、リージョン単位の障害を越えて動く必要があること。第二に、データの所在地要件を行単位で制御したい要件があること。第三に、合意のぶんだけ増える書き込みレイテンシと、SERIALIZABLE既定に伴う再試行の実装コストを、アプリ側が引き受けられること。

3つ目を軽く見た案件が一番こじれます。分水嶺は、複数リージョンで同じデータを読み書きする要件が最初から立っているかどうか。立っていないなら、増えるのは運用ノードの台数だけです。

CockroachDBの定義と現行v26.2｜PostgreSQL互換の分散SQL設計

ゴキブリの名を冠した設計思想と、Spanner系譜の分散SQLという位置づけ

CockroachDBは、2015年設立のCockroach Labsが開発する分散SQLデータベースです。製品名は「踏んでも生き残る」耐障害性の比喩から来ています。設計の系譜は明確で、Google Spannerの論文が示した「地理分散しても強い一貫性を捨てないリレーショナルDB」を、特定クラウドに縛られない形で実装したものと捉えると位置づけを掴めます。

ただしSpannerとは前提が1つ違います。原子時計とGPSに支えられたTrueTimeで時刻の不確実性を極小化するSpannerに対し、CockroachDBが立つのは汎用サーバのNTP同期です。クロック誤差の上限（--max-offset、既定500ms）を宣言し、その区間を不確実性として扱う。設計思想の差はCloud Spannerの仕組みとTrueTimeと並べて読むと掴めます。誤差上限を超えるずれを検知したノードは自らクラスタから離脱するため、NTPの構成ミスがそのままノード停止として現れます。

v26.2とv25.4 LTS｜四半期リリースで変わる版選びの判断基準

リリースは四半期ごとで、種別が3つあります。現行の最新GAはv26.2（2026年4月27日、Regular）。ひとつ前のv26.1（2026年2月2日）はInnovation、v25.4（2025年11月3日）はRegularかつLTSに昇格した版です。

種別でサポート期間が違います。RegularはMaintenance 1年とAssistance 6か月、LTSは初回LTSパッチ以降Maintenance 1年とAssistance 1年、InnovationはMaintenance 6か月のみでLTSへ昇格しません。v26.1のMaintenanceは2026年8月2日で終わります。Innovation版を本番に置けば半年で強制的な版上げが来る。受託案件で数年運用する前提なら、選ぶのはLTS版（現時点ではv25.4系）です。

5層アーキテクチャとRaft｜レンジ分割から合意形成までの内部動作

SQL層からストレージ層まで、SQLをKVへ落とし込む5層の役割分担

内部は5層に整理されています。SQL層がSQLをKV操作へ変換し、トランザクション層が複数KVへの変更を原子的にまとめ、分散層が複製されたレンジを1つの論理データとして見せ、複製層がRaftで同期複製し、ストレージ層がディスクへ読み書きします。

ここから実務上の帰結が出ます。全ノードが対等で、どのノードに接続してもSQLを受け付ける。読み書きを振り分けるプロキシ層をアプリ側に持たなくてよい代わりに、接続先ノードが担当外のレンジを触るときはノード間ホップが1回増えます。レイテンシの読み違いは、たいていここです。

既定512MiBのレンジ分割と3レプリカが決める書き込み遅延の下限

データはキー順の連続区間である「レンジ」に分けて保持されます。レンジは既定で512MiB相当まで育つと2つに分割され、容量に余裕のあるノードへ自動で再配置される。各レンジは既定3レプリカで、うち1つがRaftリーダーとして書き込みを調停します。

書き込みが確定するのは、Raftログについて過半数のレプリカが合意した時点です。3レプリカなら2ノードの合意で足ります。この「過半数」がレイテンシの下限を決める。同一アベイラビリティゾーンに3レプリカを置けばゾーン内RTTで済み、3リージョンに分散すれば最も近い2拠点間のRTTが毎回の書き込みに乗ります。ノードを増やしても書き込みは速くなりません。増えるのは同時に捌ける書き込み量です。

SERIALIZABLE既定とREAD COMMITTED｜再試行実装が要る前提

分離レベルはSERIALIZABLEが既定です。PostgreSQLやMySQLの既定（READ COMMITTED、REPEATABLE READ）から移すと、ここが最初の落とし穴になります。競合したトランザクションはエラーコード40001で中断され、アプリ側が再実行する責任を負います。

対処は2択です。1つはクライアント側に再試行ループを実装すること。公式ドライバやORMのラッパに再試行機構が用意された言語もあります。もう1つがREAD COMMITTEDの選択で、書き込み競合をサーバ側で吸収するため移植には向きます。ただし直列化異常は防げません。整合性が金額に直結する処理には、SERIALIZABLEと再試行の組み合わせを残してください。

マルチリージョン設計｜生存目標とテーブルロカリティの選び分け

ZONE生存とREGION生存｜3リージョン以上を要求する可用性設計

マルチリージョン構成では、まず「どこまでの障害を生き延びるか」を生存目標として宣言します。既定はZONE生存で、1つのアベイラビリティゾーンが落ちてもデータベースは動き続ける。REGION生存を選べば、リージョン1つが丸ごと落ちても動きます。

REGION生存には3リージョン以上が要ります。2リージョン構成では、片方が落ちた時点で残りが過半数を取れないためで、ここは設計努力で埋められません。予算の都合で2リージョンに絞るなら、生存目標はZONEに留め、リージョン障害時は手動フェイルオーバーとRPO/RTOの合意を先に取る線引きが現実的です。REGION生存は合意範囲を広げるぶん、書き込みレイテンシもZONE生存より増えます。

REGIONAL BY ROWとGLOBALの使い分けとデータ所在地要件への対応

テーブル単位では3つのロカリティから選びます。1リージョンに寄せるREGIONAL BY TABLE、行ごとに所属リージョンを持たせるREGIONAL BY ROW、全リージョンへ複製して読み取りを速くするGLOBALです。

実務で効くのはREGIONAL BY ROWです。ユーザーの行を居住国のリージョンに置けば、日本のユーザーは東京リージョンで完結して読み書きでき、「個人データは国内に置く」という所在地要件も、アプリ側のシャーディング実装なしにスキーマ定義で満たせます。GLOBALは読み取りが速い代わりに書き込みが重く、公式ドキュメントは新規クラスタで--max-offsetを250msへ下げる運用を推奨。頻繁に更新する台帳をGLOBALにするのは避けてください。

PostgreSQL互換の実像｜移植できる範囲と書き換えが要る非互換点

pgwire 3.0で動くドライバ資産と、CREATE DOMAIN等の非対応機能

CockroachDBはPostgreSQLワイヤプロトコル3.0（pgwire）を実装しています。psql、psycopg、pgx、JDBCのPostgreSQLドライバ、各種ORM、BIツールの接続設定がそのまま通り、接続レベルの障壁はほとんどありません。

詰まるのはSQLの機能面です。v26.2時点で非対応と明記されているものに、CREATE DOMAIN、範囲型、イベントトリガー、主キーの削除、XML関数、列単位の権限、XA構文、テンプレートからのDB作成、外部データラッパ（FDW）、アドバイザリロック関数があります。行レベルのトリガーはCREATE TRIGGERで書けるため、非対応はイベントトリガーのほうです。

移行で実際に刺さるのはアドバイザリロックと主キー削除です。pg_advisory_lockでジョブの二重起動を防ぐ実装は書き換えが要り、主キーなしのログテーブルを持ち込む計画も組み直しになります。

整数除算とINT 64bit固定｜移行時に静かに壊れる挙動差の実例

エラーで落ちる非互換より厄介なのが、動くけれど結果が変わる挙動差です。代表的なものを挙げます。

• 整数同士の除算が小数を返す（PostgreSQLは切り捨て整数。同じ結果が要るならスラッシュ2つの切り捨て除算演算子を使う）
• INTが常に64bit（PostgreSQLのINTは32bit相当）
• 浮動小数点の溢れがエラーではなくInfinityを返す
• ビット演算子の優先順位が異なる（&が最も高く|が最も低い。単項~も高優先度）
• サブクエリの列名が既定で?column?になる

整数除算とINT幅の2つは、テストが通ってしまう類の差分です。金額計算や件数の按分で小数が混ざり、丸め位置が変わってから発覚する。移行時はスキーマ変換ツールの結果を鵜呑みにせず、除算を含むクエリとINT列の定義を全文検索でリストアップし、期待値テストを先に書いてください。方言そのものの前提はPostgreSQLとMySQLの違いの比較で整理しています。

2024年11月のライセンス変更｜Enterprise Free枠と無償条件の線引き

Core廃止からEnterprise Free｜年商1,000万ドル未満の無償条件

日本語の解説記事で最も情報が古いのがここです。CockroachDBはApache 2.0で始まり、2019年にBSL（Business Source License）へ移行し、無償版「Core」と有償Enterpriseに分かれていました。この構造は2024年11月に廃止されています。

現行のライセンスは4種類です。有償のEnterprise、無償のEnterprise Free、30日のEnterprise Trial、営業経由のEvaluation。Enterprise Freeは機能面でEnterpriseと同等で、条件は「親会社・関連会社を合算した年間売上が1,000万ドル未満であること」。サポートはコミュニティレベルで、年次更新が要ります。適用範囲はv24.3.0のリリース日以降の全バージョンです。

受託開発では、この線引きを顧客の売上規模で判定する必要があります。年商1,000万ドル（おおむね15億円前後）を超える事業会社の基幹システムに入れるなら、無償枠は使えません。「OSSだから無料」の前提で見積もりを組むと、稼働直前にライセンス費用が乗る。要件定義の段階で顧客の連結売上を確認し、有償前提かFree前提かを見積書に明記してください。

テレメトリ7日途絶と失効後のスロットリングが業務に及ぼす影響

Enterprise FreeとTrialには、テレメトリ送信という運用条件が付きます。クラスタが7日間テレメトリを送れない状態が続くとスロットリングが掛かる。閉域網に置く社内システムでは、この一点だけで採用可否がひっくり返ります。

スロットリングの中身は、同時実行SQLトランザクションが5本に制限されるというものです。停止ではなく極端な性能低下として現れるため、CPUやディスクを見ていると原因に辿り着けません。失効後の挙動も種別で違い、Enterpriseは失効してもスロットリングされず、Freeは失効30日後、Trialは7日後に制限が始まります。

対処は2つです。ライセンス有効期限とテレメトリ送信状況を監視項目に入れること。閉域要件がある案件では、アウトバウンドのテレメトリ経路を確保できるかをネットワーク設計の初期に確認すること。ここが通らないなら、有償Enterpriseか別製品へ振り替える判断になります。

Cloud 3プランと自己ホスト｜費用構造から見た現実的な選択肢

Basic・Standard・Advancedの課金単位と無償枠の比較

マネージド版のCockroachDB Cloudは3プラン。課金単位が違うため、負荷特性で選び分けます。

検証段階はBasicの無償枠で足ります。毎月5,000万RUと10GiBは、PoCや社内ツール程度なら課金に届きません。本番は負荷の形で分かれ、トラフィックが読めないうちはBasic、常時稼働のOLTPならStandardのプロビジョニング課金のほうが単価は安定します。マルチリージョンのStandardでは、単価が最も高いリージョンを基準に全体費用が算出される点も見積もりに効きます。

自己ホストの3ノード最小構成で背負う運用コストと社内要員の条件

自己ホストの最小構成は3ノードです。1ノードでも起動しますが、レプリカが1つしかないため障害時にデータを失います。検証用途に限る前提と考えてください。

3ノードに増えた時点で、単一DBサーバとは運用の質が変わります。ノード間クロック同期（NTP／chrony）の常時監視、ローリングアップグレード時の版差管理、レンジのリバランス状況の把握、ノード撤去時のデコミッション手順。これらを引き受ける要員が社内にいるかが分岐点です。当社ではデータ分析基盤構築・MLOps構築支援としてDB選定から移行・運用設計までを受託しています。

採用してよい案件と見送る案件｜Spanner・TiDBとの選び分け基準

採用してよい3条件と、単一リージョンOLTPで過剰になる理由

採用してよいのは、次の3条件のどれかに当てはまる案件です。第一に、リージョン障害を越えてサービスを継続する要件が契約上定まっていること。第二に、複数国のユーザーデータを扱い、行単位で所在地を制御したいこと。第三に、書き込みスループットが単一プライマリの上限に実際に当たっていること。

逆に、見送るべき場面ははっきりしています。単一リージョンで完結し、書き込みが1台のマネージドRDBで捌けている業務システムには持ち込まないでください。書き込みが合意のぶん遅くなり、再試行実装が加わり、運用対象は3ノードになる。得られるのは「将来スケールできる」選択肢だけで、その将来が来ない案件のほうが多いのが実情です。この条件ならAmazon AuroraやマネージドPostgreSQLで足ります。

もう1つの見送り条件が、前章のライセンスとテレメトリです。年商1,000万ドル以上の顧客で有償Enterpriseの予算が取れない、あるいは閉域でテレメトリを出せない。どちらかに当たった時点で、技術的な適合性とは無関係に候補から外れます。

Spanner・TiDB・Aurora DSQLとの機能差と選定の分岐点

決め手になるのは性能値よりも配置制約とSQL方言です。

選定はこう分岐します。インフラがGoogle Cloudに固定されているならCloud Spanner、AWSに固定されPostgreSQL互換で足りるならAmazon Aurora DSQLが第一候補。既存アプリがMySQL方言で書かれているならTiDBのほうが移植コストは小さくなります。CockroachDBが勝つのは、クラウドを跨ぐ、あるいはオンプレとクラウドを跨ぐ配置が要件に入っている案件です。単一クラウドに閉じるなら、可搬性は費用を払うだけの価値になりません。

CockroachDBの採用検討でよくある質問と実装上の注意点

導入の相談でよく挙がる質問を、公式ドキュメントの記載から整理しました。

CockroachDBは無料で使えますか？

条件付きで無料です。親会社・関連会社を合算した年間売上が1,000万ドル未満の組織は、Enterprise Freeライセンスで全機能を無償で使えます。サポートはコミュニティレベルで、年次更新とテレメトリ送信が条件。この体系は2024年11月の変更でv24.3.0以降に適用され、無償版「Core」は廃止されました。売上条件を満たさないなら有償Enterpriseです。検証だけならCloud Basicの無償枠でも始められます。

CockroachDBとPostgreSQLの違いは何ですか？

接続プロトコルとSQLの大半は共通ですが、実体は別物です。PostgreSQLが単一プライマリで書き込みを受けるのに対し、CockroachDBはデータをレンジに分けて複数ノードへ複製し、Raftの過半数合意で確定します。ノード追加で書き込みを水平にスケールでき、ノードやリージョンが落ちても継続する。代わりに合意のラウンドトリップが乗り、既定のSERIALIZABLEでは再試行の実装が要ります。

CockroachDBはどのバージョンを選べばよいですか？

数年運用する本番システムならLTS版を選びます。2026年8月時点ではv25.4系がLTSで、初回LTSパッチからMaintenance 1年とAssistance 1年が確保されます。最新機能が要るならRegular最新のv26.2（2026年4月27日GA）。Innovation版はMaintenanceが6か月でLTSへ昇格しないため、検証以外での採用は避けてください。

最小構成は何ノードから必要ですか？

本番は3ノードからです。既定のレプリカ数が3で、Raftの過半数（2つ）が生きていれば書き込みを継続できます。1ノードでも起動しますが複製が効かず、障害時にデータを失うため検証専用と考えてください。REGION生存目標を選ぶ場合は、さらにリージョンが3つ以上必要になります。

既存のPostgreSQLアプリはそのまま動きますか？

ドライバとORMは基本的にそのまま動きますが、SQLとトランザクション処理には手が入ります。確認すべきは3点。pg_advisory_lockなど未対応関数の使用箇所、整数除算とINT幅（常に64bit）による計算結果の変化、SERIALIZABLE既定でエラーコード40001が返る前提の再試行実装です。主キーを持たないテーブルも作れないため、スキーマの見直しが要る場合もあります。移行前に除算を含むクエリと排他制御の実装を洗い出すと、手戻りが減ります。

関連記事

• Cloud Spannerとは？分散リレーショナルDBの仕組み・TrueTimeと採用判断を実装者目線で解説：設計の系譜が同じGoogle Cloud側の分散SQLです。
• Amazon Aurora DSQLの概要と基本概念についての説明：AWSに固定された案件で第一候補になるPostgreSQL互換の分散SQLです。
• TiDB Serverlessとは｜TiDB Cloud Starterへの改称・料金・オートスケールの仕組み：既存アプリがMySQL方言の場合の対になる候補です。
• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説：単一リージョンで足りる場合の現実的な代替候補です。
• TimescaleDBとは？PostgreSQL拡張の仕組みと採用可否の判断基準：PostgreSQL資産を保ったまま別方向へ拡張する設計の例です。