AlloyDBとは？PostgreSQL互換マネージドDBの構成・カラム型エンジン・料金と採用判断を実装者目線で解説

AlloyDBとは、Google Cloudが提供するPostgreSQL互換のフルマネージドデータベースです。既存のPostgreSQL向けドライバやSQLをそのまま持ち込めるうえ、行指向のトランザクション処理と列指向の分析クエリを1つのデータベースで受けられます。マネージドRDBという枠組み自体はCloud SQLとは？GCPのマネージドRDBの仕組みと採用判断で整理しているため、この記事はAlloyDB固有の構造と判断に絞ります。どんなノード構成で組み、列ストアがどのクエリに効き、費用がどう積み上がり、どの条件でCloud SQLではなくこちらを選ぶのか、です。

まとめ｜行と列を1つのDBで回す選択で、費用はノード構成で決まる

先に結論を置きます。AlloyDBが売っているのは「PostgreSQLの互換性を保ったまま、分析クエリを別基盤へ運ばずに済むこと」と「読み取り負荷をノード追加で逃がせること」の二つ。支払うのは、計算資源の時間課金にストレージと通信が積み上がる従量費用と、PostgreSQLそのものより高い最低ラインの費用です。

構成は、費用よりも先に可用性タイプで切ると迷いません。SLAの対象はHA（複数ゾーン）構成のみで、基本（単一ゾーン）構成と1 vCPU形状は外れます。つまり「本番＝HA構成でノードが2つ分課金される」が出発点です。読み取り負荷はプライマリを大きくするのではなく読み取りプールを足して逃がしますが、ノード数はクラスタ全体で20が上限になります。

分析クエリの高速化を狙うなら、カラム型エンジンの性質を先に押さえてください。列ストアは既定でインスタンスメモリの30%を使い、有効化には再起動を伴います。効くのは広い範囲を舐めて集計する形のクエリだけで、「重い集計だけが別経路を得る」と理解しておくと期待値がずれません。

AlloyDBとは何か｜PostgreSQL互換のマネージドDBとして代行される範囲

Cloud SQLとの位置づけの差｜同じ互換DBでも売っているものが違う

どちらもGoogle Cloud上のマネージドPostgreSQLですが、狙いが違います。Cloud SQLはMySQL・PostgreSQL・SQL Serverを揃えた汎用のマネージドRDBで、既存DBをそのまま持ち上げる置き換え先という性格が強い。対してAlloyDBはPostgreSQL互換に一本化し、計算とストレージを分離した独自基盤へ載せて列指向の処理経路を足しています。

Google公式のパフォーマンステストでは、標準のPostgreSQLと比べてトランザクション処理で4倍以上、分析クエリで最大100倍という数字が示されています。ただしこれは提供元の測定条件下の値で、効き方はクエリの形に依存します。桁感の参考に留め、採用前には自分たちの重いクエリを持ち込んで実測してください。

対応バージョンと拡張サポート｜既定は17系で、EOL版は追加費用の対象

2026年8月時点の公式ドキュメントでは、PostgreSQL 18・17・16・15・14に対応し、新規クラスタでメジャー版を指定しない場合の既定は17系です。

版を据え置く判断で効いてくるのが拡張サポートの扱いでしょう。コミュニティのEOLを迎えたメジャー版を動かすインスタンスは拡張サポートへ自動的に登録され、追加費用が生じます。14系は2027年2月1日から拡張サポート、2030年2月1日で廃止。以降15系・16系・17系が1年ずつ後ろへずれます。「移行が済むまで古い版で粘る」という選択に価格が付く前提で、更新計画を先に引いておいてください。

利用側に残る責務｜スキーマと索引と接続経路の設計は代行されない

自動化されるのは、ノードの払い出し、冗長構成の維持、障害時の切り替え、ストレージの拡張、パッチ適用、そしてバキュームのパラメータ調整あたりです。Index Advisorが索引の候補を提案し、適応型自動バキュームがワークロードに合わせて設定値を動かします。

一方で残り続けるものが四つあります。テーブル設計、索引の設計、権限とロールの設計、そしてクエリの書き方です。特に索引は「遅いからノードを増やす」で誤魔化しやすく、vCPUを倍にして直ったように見えても原因は残ります。過去版の滞留や長時間トランザクションが絡む遅さなら、MVCCとは？多版型同時実行制御の仕組みと過去版の回収を先に当たってください。

クラスタとインスタンスの構成｜プライマリと読み取りプールの分け方

クラスタという単位｜リージョン内のVPCへ置くまとまりとノードの内訳

AlloyDBはクラスタという単位でリソースをまとめます。単一リージョン内に作られ、指定したVPCの中へ配置される点が起点です。作成前にAlloyDB APIの有効化、VPCピアリングの設定、AlloyDB Admin相当のIAMロールが要ります。

クラスタの中身は、プライマリインスタンスと読み取りプールインスタンスに分かれます。プライマリは1クラスタに1つで、HA型なら2ノード、基本型なら1ノード。読み書きを受け付けるのはここだけです。

gcloud alloydb instances create INSTANCE_ID \
    --instance-type=PRIMARY \
    --availability-type=REGIONAL \
    --region=REGION_ID \
    --cluster=CLUSTER_ID \
    --cpu-count=CPU_COUNT \
    --project=PROJECT_ID

--availability-type に REGIONAL を渡せばHA構成、ZONAL なら基本構成です。この一語がSLAの対象可否を分けるため、環境ごとにテンプレートを分けておくと事故が減るでしょう。マシンシリーズはC4A・N2（既定）・C4・Z3の4系列から選べ、vCPUの刻みと上限は系列ごとに違います。C4Aで選べる1 vCPU構成がSLAの対象外である点だけ先に押さえ、迷ったら既定のN2で始めて実測してから寄せてください。

読み取りプール｜クラスタ全体で20ノードという上限の中での増やし方

参照系の負荷は、プライマリを大きくするのではなく読み取りプールを足して逃がします。1つの読み取りプールインスタンスに1〜20のノード数を指定でき、クラスタ全体を通じて20ノードを超えることはできません。

gcloud alloydb instances create INSTANCE_ID \
    --instance-type=READ_POOL \
    --read-pool-node-count=NODE_COUNT \
    --region=REGION_ID \
    --cluster=CLUSTER_ID \
    --cpu-count=CPU_COUNT \
    --machine-type=MACHINE_TYPE \
    --project=PROJECT_ID

設計上の含意は二つあります。第一に、読み取りプールへ流すのは参照だけなので、アプリ側で接続先を書き込み用と参照用に分けておく必要がある。ORMの読み取りレプリカ設定を後付けするのは面倒なので、最初から二系統で持ってください。第二に、上限20は「際限なくスケールアウトできる仕組みではない」という意味です。遅延の性質そのものは一般的なレプリケーションと同型で、データベースレプリケーションとは？同期・非同期の違いとレプリカ遅延の設計で整理した注意点が当てはまります。

なお計算レイヤとストレージレイヤは分かれており、それぞれを別々に伸縮できます。ストレージはGoogleが構築したクラウドベースのファイルシステム上に置かれ、容量の事前確保という作業自体がありません。「ディスクを増やすためにインスタンス種別を上げる」という従来の連動が切れている点は、運用計画の立て方を変えるでしょう。

カラム型エンジンの仕組み｜メモリ30%の列ストアと自動列指向化の挙動

列ストアの置き方｜既定30%の割り当てと有効化に再起動が要る点

カラム型エンジンは、特定の列をメモリ上に列指向の形で保持し、集計系のクエリをそちらの経路で処理する仕組みです。既定ではインスタンスメモリの30%が列ストアへ割り当てられ、割合は動かせます。有効化は一度きりの操作ですが、再起動を伴う点は計画に織り込んでください。

この30%という既定値には裏面があります。列ストアへ回したぶん、通常のバッファキャッシュに使えるメモリが減る点です。トランザクション処理がメモリに収まりきっている状態で有効にすると、分析クエリは速くなったのに通常処理のヒット率が落ちて全体では損をする、という結果もあり得ます。有効化の前後で両方の応答時間を測り、割合を動かして落としどころを探ってください。

効くクエリと効かないクエリ｜スキャンと集計と内部ハッシュ結合の線引き

公式ドキュメントが挙げる対象は、選択的なフィルタや少数の列だけを参照するテーブルスキャン、SUM・MIN・MAX・AVG・COUNTの集計関数、結合キーが列ストアに載っている場合の内部ハッシュ結合、条件を満たす場合の ORDER BY と LIMIT です。

裏を返すと、多数の列を丸ごと引く SELECT * 型のクエリ、1行を主キーで取りに行く参照、更新や削除といった書き込みには効きません。さらに押さえたいのが、プランナが必要に応じて行ストア側を選ぶ挙動です。索引が張られた列への分析クエリでは、列ストアがあっても行ストア経由が選ばれることがあります。「有効にしたのに実行計画が変わらない」という相談の多くはこれです。EXPLAIN でどちらが選ばれているかを確かめてから、索引の側を見直してください。

自動列指向化の任せ方｜列の出し入れを任せる範囲と手動指定の線

どの列を列ストアへ載せるかは、自動列指向化に任せられます。ワークロードを分析して効果の大きい列を選び、動的に追加と削除を行う仕組みです。運用の手間という観点では、まずこれに任せてしまうのが素直でしょう。

手動指定へ切り替える判断が立つのは、月次バッチのように頻度は低いが遅延を許せない処理がある場合です。自動選定は普段のワークロードを見て動くため、月に一度しか走らない集計の対象列は載らないまま、という状況が起こり得ます。決まった時刻に重いクエリを回す運用なら、対象列を明示して固定するほうが読める挙動になります。

高可用性と復旧の設計｜HA構成だけがSLA対象という前提から逆算する

HA構成と基本構成の差｜2ノード冗長と自動切り替えの対象範囲

HA構成のプライマリは2ノードで組まれ、ゾーン障害やノード障害の際に自動で切り替わります。基本構成は1ノードで、切り替え先を持ちません。公式の説明では、多くのデータベース障害を60秒以内に検知して復旧するとされ、その所要時間はデータベースのサイズや負荷に依存しないとされています。ストレージ層が計算層から切り離されており、復旧時にデータを転送し直す工程が発生しないためです。自前でレプリケーションを組んできた場合、切り替えの自動化と再組成を持たなくてよくなる点で率直に差が出ます。

SLAの対象条件｜単一ゾーンと1 vCPU形状が外れる点の織り込み方

SLAが適用されるのはHA（複数ゾーン）構成のインスタンスのみで、1 vCPU形状は除外されます。基本構成のインスタンスは対象外です。HA構成に対しては、メンテナンスを含めて99.99%という月間稼働率が示されています（2026年8月時点・条件と除外事項は公式のSLA本文を参照してください）。

この条件から逆算すると、構成の決め方はこうなります。本番はHA構成で組み、vCPUは2以上を選ぶ。検証やCI用のクラスタは基本構成へ落として費用を抑える。そして「本番と同じ構成で検証したい」という要求には、ノードが2つ分課金される事実を添えて返す。ここを最初に握らないと、費用を抑えるつもりの基本構成がそのまま本番として動き続けます。

料金の数え方｜計算資源とストレージと通信に分解して積み上げる

課金要素の分解｜vCPUとメモリの時間課金へ何がどれだけ乗るのか

費用は従量課金で、軸は三つです。計算資源（vCPUとメモリ）の時間課金、実際に使ったストレージ量、ネットワークの通信量。加えてバックアップの保存量が乗ります。公式が明示しているのは、独自のライセンス費用とI/O課金がない点です。

この「I/O課金がない」という性質は、見積りの立てやすさに直結します。読み取り回数や書き込み回数が請求へ跳ね返らないため、クエリの本数が読めない段階でも計算資源とデータ量から上限を押さえられるわけです。単価は系列・vCPU数・リージョンで変わるので、確定額は公式の料金計算ツールに自分の構成を入れて出してください。

見積りの手順｜ピーク時の作業量から構成と読み取りプールを逆算する流れ

手順は四段階に分けると迷いません。第一に、頻繁に触るデータ量を出す。これがメモリに収まるかがvCPUとメモリの選定基準で、列ストアへ30%を回した後でも収まるかまで見ます。第二に、参照と更新の比率を出す。参照が大半なら読み取りプールが効き、更新が多いならプライマリ側を厚くするしかありません。第三に、総データ量と保持期間からストレージ費用を見積もる。第四に、アプリとデータベースのリージョンが揃っているかを確認してください。ずれていると通信費用が毎月静かに積み上がります。

なお費用比較の相手をCloud SQLに置く場合、同じvCPU数で並べても意味が薄い点に注意してください。AlloyDBはHA構成が実質の前提で、そのうえで分析クエリを別基盤へ運ばずに済ませる価値を買っています。分析用のデータウェアハウスと転送処理の運用費まで含めて並べたとき、初めて比較として成立します。

AlloyDB AIとベクトル検索｜pgvector互換の拡張とScaNN索引の置き場所

拡張の内訳｜ベクトル索引と埋め込み生成を担う拡張それぞれの役割

AlloyDBには生成AI向けの拡張がいくつか用意されています。整理すると次のとおりです。

• vector：pgvectorをAlloyDB向けに調整したもの。IVF・IVFFlat・HNSWの各索引に対応し、スカラー量子化が加わっています
• alloydb_scann：ScaNNアルゴリズムによる近傍探索の索引を提供します
• google_ml_integration：埋め込みベクトルの生成と、意味的な並べ替えをSQLから呼び出せます
• alloydb_ai_nl：自然言語からの問い合わせに関わる拡張です

連携できるモデルの提供元としては、Google・OpenAI・Anthropicなどが挙げられています。埋め込みの生成をアプリ側の処理として書かず、SQLの中で完結させられる点が実装上の差になります。

1つのDBで回す設計｜業務データと埋め込みを同居させたときの利点

PostgreSQLでベクトル検索を組むこと自体はpgvectorの基本概要とPostgreSQLにおけるベクトル検索のとおり以前から可能で、AlloyDB固有ではありません。差が出るのは索引の選択肢と、埋め込み生成をDB側へ寄せられる点です。

検索拡張生成（RAG）を組む場合、埋め込みと元の業務レコードを同じ行に持てると、検索結果から本体の属性を引き直す往復が消えます。ベクトルストアを別立てにした構成でよく起きる「IDだけ返ってきて本文を取りに戻る」処理と、両者の同期ずれを設計から外せるわけです。ここに前章のカラム型エンジンが乗れば、同じデータに対して集計と近傍探索を1か所で回せます。データが増えるほど転送と同期の設計は重くなるので、この一体化が効く場面は少なくないでしょう。

独自章｜構築初日に決める5つの設定と、後から変えにくい設定の順序

変えにくい順に決める｜リージョンとVPC設計を最初に固定する理由

後から変えやすい順に並べると、読み取りプールのノード数、列ストアの割り当て、マシンシリーズとvCPU数、可用性タイプ、メジャー版、VPCとリージョンの順です。決める順序はこの逆になります。

リージョンを動かすには実質的にデータの移送が要り、VPCピアリングの設計変更は自社ネットワーク側の調整を伴います。メジャー版の変更はアップグレード作業そのものです。対してノード数と列ストアの割合は、動かしながら詰められる設定にすぎません。この非対称を無視して「まず小さく作って後で考える」と進めると、動かしにくい部分ほど暫定値のまま本番になります。

決め切る5つの項目｜配置・版・可用性・構成・列ストアの初期値

• 配置：アプリが動くリージョンとVPCに揃える。通信費用と遅延の両方が効きます
• メジャー版：新規なら既定の17系か18系から選ぶ。移行元があるならその版に合わせ、拡張サポートの開始日を計画のリミットとして共有します
• 可用性タイプ：本番はREGIONAL（HA）でvCPUは2以上。検証はZONAL（基本）へ落として構いません
• ノード構成：プライマリは実測で決め、参照負荷は読み取りプールへ逃がす。上限20ノードを設計の制約として最初から共有しておきます
• カラム型エンジン：重い集計クエリが実在する場合のみ有効化し、既定30%の前後で通常処理の応答も一緒に測ります

独自章｜AlloyDBを選ぶ条件と、Cloud SQLや他のDBへ寄せる場面

採用してよい条件｜分析クエリの同居と読み取り負荷の逃がし先が要る時

次の条件のうち二つ以上が当てはまるなら、AlloyDBを採用して差し支えありません。第一に、PostgreSQLで組んだ業務システムがあり、互換性を崩さずに移したい。第二に、同じデータに対して重い集計クエリを回しており、分析用の基盤へ転送する処理を持ちたくない。第三に、参照系の負荷が伸びていて、ノードを足して逃がす仕組みが要る。第四に、業務データと埋め込みベクトルを同じ場所に置いて検索まで回したい。特に第二と第四は汎用のマネージドRDBでは代替しにくく、逆にこの二つが不要ならAlloyDBである必然性は下がります。

見送るべき場面｜負荷が小さい構成やMySQL系、分散書き込みが要る場合

負荷が軽く、HA構成の常時稼働ぶんの費用が見合わないなら、無理に寄せる理由はありません。Cloud SQLで足りますし、MySQLやSQL Serverを使うならそもそも対象外です。開発環境を大量に立てたい、使っていない時間の費用を落としたいという要求が強いなら、Neonのようなサーバーレス型のPostgresが噛み合うでしょう。

時系列データの保持と圧縮が主題ならTimescaleDBが、書き込みを地理的に分散させたい、単一リージョンでは可用性が足りないという要件ならCockroachDBのような分散SQLが候補です。AlloyDBのクラスタが単一リージョンに閉じる点は押さえてください。なお自前のLinux環境で動かせるAlloyDB Omniという提供形態もあり、オンプレミスや別のクラウドへ同じエンジンを置く道も残されています。

どの構成で組み、既存のPostgreSQLからどう移し、分析用の処理をどこまで同居させるかを含めて相談したい場合は、データ分析基盤構築・MLOps構築支援で要件の整理から構築・移行まで承っています。

よくある質問

既存のPostgreSQLからそのまま移せますか？

PostgreSQL互換のため、ドライバと接続文字列の差し替えを中心に移せる場合が大半です。ただし互換範囲は拡張に依存するので、使っている拡張がAlloyDB側にあるかを事前に確かめてください。移行元のメジャー版に合わせてクラスタを作り、後からアップグレードする段取りが安全でしょう。

カラム型エンジンを有効にすれば全部のクエリが速くなりますか？

なりません。効くのは広い範囲を舐めて集計する形のクエリで、主キーでの単一行取得や書き込みには効きません。索引が張られた列に対する分析クエリでは、プランナが行ストア側を選ぶこともあります。EXPLAIN でどちらの経路が選ばれているかを確かめたうえで判断してください。

読み取りプールを増やせば書き込み性能も上がりますか？

上がりません。読み書きを受けるのはプライマリインスタンスだけで、読み取りプールは参照専用です。書き込みが詰まっているならプライマリのvCPUとメモリか、更新処理そのものの設計を見直す必要があります。

基本構成のまま本番で使ってもよいですか？

推奨できません。基本構成は1ノードで切り替え先を持たず、SLAの対象からも外れます。本番はREGIONAL（HA）かつvCPU2以上、という線を最初に引いてください。

バキュームの調整は自分でやらなくてよいのですか？

適応型自動バキュームがワークロードに合わせてパラメータを動かすため、既定のまま任せられる場面は増えます。ただし長時間トランザクションが過去版の回収を止める構造は変わりません。膨張が観測されたときの当たり方はMVCCの仕組みと過去版の回収を参照してください。

関連記事

• Cloud SQLとは？GCPのマネージドRDBの仕組み・エディションと採用判断を実装者目線で解説
• Neonとは？サーバーレスPostgresの構成・料金と採用判断を実装目線で解説
• TimescaleDBとは？PostgreSQL拡張の仕組みと採用可否の判断基準
• CockroachDBとは？分散SQLの仕組み・ライセンス変更と採用判断を実装者目線で解説
• TiDBとは？MySQL互換の分散SQLの仕組みとHTAP・採用判断を解説
• pgvectorの基本概要とPostgreSQLにおけるベクトル検索
• データベースレプリケーションとは？同期・非同期の違いとレプリカ遅延の設計
• MVCCとは？多版型同時実行制御の仕組みと過去版の回収を実装目線で解説