AlloyDB Omniとは？自前環境で動かす導入手順・要件・ライセンスと採用判断を実装者目線で解説

AlloyDB Omniは、Google CloudのマネージドDBであるAlloyDBと同じエンジンを、自分のLinux環境へ置いて動かすためのダウンロード版です。マネージドサービスとしてのAlloyDBの構成や料金の数え方はAlloyDBとは？PostgreSQL互換マネージドDBの構成・カラム型エンジン・料金と採用判断を実装者目線で解説にまとめてあります。この記事では、そこから提供形態だけを切り出し、動かすための要件・導入の手順・ライセンス条件・マネージド版との設定差を、実装者が着手前に確かめる順序で整理しました。

まとめ｜自前環境へ置く選択は、評価は無償・本番はvCPU課金という前提で決まる

• AlloyDB Omniはダウンロード版のデータベースソフトウェアで、マネージド版と中核部品を共有しながら、ストレージ層だけはPostgreSQL標準のファイルシステムインタフェースに置き換わっています。
• 提供形態はコンテナ単体とKubernetesオペレータの2系統です。単一インスタンスで足りるならコンテナ単体、HAやクロスリージョンDRや読み取りプールが要るならオペレータ側を選びます。
• 最小要件はAVX2対応CPU・RAM 2GB・ディスク10GB・cgroups v2有効という組み合わせで、CPU命令セットの条件が既存サーバでの評価を止める一番の要因になります。
• 列ストアの既定割り当ては1024MBで、マネージド版がインスタンスメモリの30%を充てるのとは初期値が違います。評価時に性能が伸びない場合、まずここを疑ってください。
• 費用はライセンス条項に定義された評価目的なら無償で、本番配置には製品ライセンスのサブスクリプションが必要です。製品ページには月額 $40/vCPU という水準が示されています（2026年8月時点）。

AlloyDB Omniとは何か｜ダウンロード版として自前環境へ置ける範囲

AlloyDB Omniは、AlloyDB for PostgreSQLを単体インスタンスとして自環境へ配置できるよう整えたデータベースソフトウェアパッケージです。公式ドキュメントは「マネージドサービスと中核部品を共有しつつ、AlloyDBのクラウドネイティブなストレージ層ではなく、PostgreSQLが使う標準のファイルシステムインタフェースを用いる」と説明しています。つまりエンジンの性格は引き継ぎ、下回りだけを自前のディスクに載せ替えた形と考えると理解しやすいでしょう。

マネージド版との構造差｜ストレージ層が標準ファイルシステムになる

マネージド版のAlloyDBは、計算レイヤとストレージレイヤを分離し、ストレージ側をGoogleが運用します。Omniではその層が手元のファイルシステムに置き換わるため、耐久性・バックアップ・容量拡張の責務は運用側へ戻ってきます。性能面では標準PostgreSQL比でトランザクション処理2倍以上・分析クエリ最大100倍という数字がGoogleから公表されていますが、これは公称値であり自社実測ではありません。手元のディスク性能に強く引きずられる点は、評価計画に先に織り込んでおきたいところです。

提供形態の2択｜単一コンテナ構成とKubernetesオペレータ構成

ドキュメントはコンテナ版とコンテナオーケストレータ版に分かれています。コンテナ版が想定するのは、単一インスタンスで足りるケース、開発とテスト、Kubernetesを使わない環境、ネットワークから切断された状態でも動き続ける運用、利用者の近くへ置いて応答時間を詰めたい配置です。逆にHAの調整・クロスリージョンDR・読み取りプールの伸縮が要件に入ると、オペレータ版が前提になります。どちらの形態でも、保存データを透過的に暗号化するTDE有効クラスタを作成できます。

版の数え方｜18.3系という表記とPostgreSQL側のメジャー版

ドキュメントの版セレクタは18.3.0をCurrentとして表示し、18.1系・17系・16系・15系が過去版として並びます（2026年8月時点、当該ページの最終更新は2026-07-29 UTC）。版番号の先頭はPostgreSQLのメジャー版に対応しており、どの互換版を使うかは選ぶイメージタグで決まります。なお、PostgreSQL 18対応やOmni単体UIといった一部機能は、公式が案内する申込みフォーム経由で解放される扱いになっている点も押さえておいてください。

動作要件の確かめ方｜CPU命令とカーネルとcgroups v2の前提

導入で最初に止まるのは要件の確認です。ここは実機で先に潰しておくと、後工程の手戻りが減ります。

ハードウェア側の下限｜AVX2対応CPUと2GB RAMと10GBの空き

ArmはプレビューとしてLinux側に記載されています。ここで注意したいのは、古い物理サーバやCPU機能を絞った仮想マシンではAVX2が使えず、要件を満たせない場合がある点でしょう。また公式は「Linux上で直接動作するようコンパイルされており、macOSのDockerでは互換レイヤを経由して性能が落ちる」と明記しています。手元のMacで動かした結果をそのまま本番の見込み値に使わないでください。

ソフトウェア側の下限｜cgroups v2とDockerとPodmanの版

OSはDebian系（Ubuntuなど）またはRHEL 8か9、Linuxカーネルは5.3以上、そしてcgroups v2が有効であることが条件です。cgroups v2の有無は次のコマンドで確かめられます。出力に nodev cgroupsv2 の行があれば有効です。

grep cgroup /proc/filesystems

コンテナランタイムはDocker Engine 20.10以上、またはPodman 4.2.0以上が求められます。インストール自体にroot権限は不要と明記されており、権限申請の段取りは想像より軽く済む要件です。入手経路はDockerHubのほか、Google Cloud・AWS・AzureのMarketplace、Red Hat環境向けにはRed Hat Ecosystem CatalogのUBIイメージとRed Hat Marketplaceが案内されています。

コンテナで起動する手順｜docker runからpsql接続までの流れ

要件が揃えば起動そのものは短い工程です。ただし既定値のまま進めると評価データを失う踏み方があるため、そこだけ先に潰します。

起動コマンドの組み立て方｜パスワード変数とイメージタグの固定手順

コンテナ名とpostgresユーザーのパスワード、そしてイメージタグを与えて起動します。Podmanを使う場合も docker を podman に置き換えるだけで同じ形です。

docker run --name my-omni \
  -e POSTGRES_PASSWORD=YOUR_PASSWORD \
  -d google/alloydbomni:IMAGE_TAG

タグは latest のような可変指定ではなく、検証した版で固定してください。ドキュメント本文のサンプルに書かれたタグと、ページ上部が示すCurrentの版番号がずれている場面があり、公式の版一覧を見て明示的に選ぶほうが安全です。起動後の接続はコンテナ内のpsqlを呼び出します。

docker exec -it my-omni psql -h localhost -U postgres

データの置き場所の注意点｜コンテナ削除で消える既定の挙動と回避

既定ではデータをホストのファイルシステムではなくコンテナ側に保存する仕様で、コンテナを削除するとデータディレクトリも消えます。評価環境でも投入したデータセットを作り直す手間は無視できません。ホスト側のディレクトリをマウントする設定は公式のカスタマイズ手順に用意されているので、最初の起動から当てておくことをおすすめします。バックアップの設計も、この時点で置き場所と取得方法を決めておくと後がぶれません。

Kubernetesで動かす場合｜オペレータとDBClusterの役割分担

もう一方の形態は、専用オペレータをKubernetesクラスタへ導入する方式です。Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説で扱った基本構造の上に、データベース固有の運用がカスタムリソースとして載る形になります。配置先はGKE・EKS・AKS・OpenShift・オンプレミスが挙げられており、特定クラウドへ縛られない点が持ち味です。

オペレータが引き受ける範囲｜作成と冗長化と復旧の自動化の線引き

操作の入口はDBClusterなどのカスタムリソースで、kubectlから宣言的に扱います。オペレータが自動化するのは、仕様に沿ったプロビジョニング、フェイルオーバーと複数ゾーンへの分散と読み取りプールの伸縮、スタンバイを使ったクロスリージョンDR、スタンバイからのバックアップ取得、そして停止時間を抑えた更新です。カスタムポートやサイドカーコンテナの統合も仕様の中で指定できます。

コンテナ単体との使い分け｜HAと読み取り拡張が要るかで切り分ける

選択の境目ははっきりしています。API駆動のライフサイクル管理、細かく詰めたいHA、監視やバックアップの既存エージェントをサイドカーで載せる要件、可変の読み取りプール、PgBouncerによる接続プールと負荷分散、クロスリージョンDR。これらのどれかが要件に入るならオペレータ版です。逆に単一インスタンスで完結し、Kubernetesの運用体制を持たないなら、コンテナ単体のほうが総手間は小さくなります。

列ストアとAI拡張の設定｜既定1024MBという割り当ての起点

AlloyDBの持ち味である列指向の処理はOmniでも使えますが、初期値がマネージド版と違います。ここを知らないまま比較すると、分析クエリの数字が伸びずに評価を打ち切ってしまいがちです。マネージド版側の挙動はAlloyDBとは？PostgreSQL互換マネージドDBの構成・カラム型エンジン・料金と採用判断を実装者目線で解説に整理してあります。

列ストアの割り当て変更｜ALTER SYSTEMと再起動が要る点

列ストアを使うには google_columnar_engine.enabled を on にします。割り当てサイズを決める google_columnar_engine.memory_size_in_mb の既定は1024MBで、マネージド版がインスタンスメモリの30%を充てる設定とは異なる出発点です。コンテナ版ではALTER SYSTEMで設定し、反映にはコンテナの再起動が要ります。

ALTER SYSTEM SET google_columnar_engine.memory_size_in_mb = 8192;

Kubernetes版では同じ値をDBClusterマニフェストの primarySpec に parameters として書きます。宣言的に管理する以上、手元のALTER SYSTEMと二重管理にならないよう、どちらを正とするかを先に決めておいてください。

ディスクキャッシュの上限｜既定5%と50%という頭打ちの読み方

ディスクキャッシュ側は既定で5%が列ストアへ割り当てられます。上限は「総ディスクキャッシュの50%」と「1000×memory_size_in_mb」の小さい方に頭打ちされる決まりです。メモリ側の値を上げないままディスク側だけ広げようとしても、後者の条件で頭打ちになるため効きません。ベクトル検索を同居させる設計を検討しているなら、pgvectorの基本概要とPostgreSQLにおけるベクトル検索で扱った索引のメモリ消費と合算して見積もってください。

ライセンスと費用の考え方｜評価は無償で本番はvCPU単位の課金

Omniの費用構造は、マネージド版の従量課金とはまったく別物です。ここを取り違えると、PoCが通った後の稟議で止まります。

無償で使える範囲の線引き｜評価目的という条件を読み違えない確認

公式は「ライセンス条項に定義された評価目的については無償で提供する」と記載しています。裏を返せば、本番配置は製品ライセンスのサブスクリプションが前提です。社内の常用ツールを支えるDBとして継続稼働させる時点で評価の範囲を超えます。無償のまま本番投入する運用は、契約上もサポート上も成り立たないと考えてください。

本番移行時の費用の数え方｜vCPU数から月額を積み上げる順序

購入導線はGoogle Cloudコンソールの Clusters ページにあり、Purchase AlloyDB Omni からvCPU数を入力する形です。製品ページには月額サブスクリプションとして $40/vCPU という水準と、月単位で切り替えられる旨が示されています（2026年8月時点・実際の適用条件は見積り時に確認してください）。見積りの順序は単純で、まずピーク時に必要なvCPU数を決め、それを台数分だけ積み上げます。加えて、自前で持つことになるサーバ・ストレージ・バックアップ領域・運用工数を足したものが、マネージド版と比べる際の総額です。

独自章｜評価環境から本番へ持ち上げる前に決め切る5つの設定項目

Omniは起動が簡単な分、評価環境の設定がそのまま本番へ流れ込みやすい構成です。後から変えにくいものから順に決めると、作り直しが減ります。

後から変えにくい順に固める｜配置とストレージと版番号を決める順序

最初に決めるのは配置先です。データセンターか、別クラウドのVM上か、Kubernetesクラスタ上か。次にストレージで、SSDを前提とした容量とIOPSの見込み、そしてホスト側マウントの方式を固めます。3番目が版番号で、PostgreSQLのメジャー版と紐づくため後から動かすと移行作業になります。この3つを先に確定させてから、可変の設定に入るのが順序として無理がありません。

決め切る5項目の中身｜監視と接続経路とバックアップの初期値の置き方

1. 配置先とデプロイ形態（コンテナ単体かオペレータか）
2. ストレージ構成とホスト側マウント、そして容量の伸ばし方
3. PostgreSQLメジャー版とイメージタグの固定方針
4. 接続経路と認証（パスワード管理・ネットワーク到達範囲・接続プールの有無）
5. 列ストアの初期割り当てとバックアップの取得先および保持期間

監視は5項目の外に置きましたが、オペレータ版ならサイドカーで既存エージェントを載せられます。コンテナ単体の場合は監視の当て方を別途決める必要があるため、そこも同じタイミングで詰めておくと安全です。

独自章｜Omniを選ぶ条件と、マネージド版や素のPostgreSQLへ寄せる場面

ここまでの要件と費用を踏まえて、採用の可否を条件付きで言い切ります。

採用してよい条件の並べ方｜持ち出せないデータと切断環境という要件

Omniを採るべきなのは、次のいずれかが要件として先にあるときです。規制やデータ主権の都合でパブリッククラウドの管理下へデータを置けない。インターネットから切断された状態でも動き続ける必要がある。利用者や機器の近くへ配置して応答時間を詰めたい。あるいは、AlloyDBの列指向処理とAI拡張を、既存のオンプレミス資産の上で先に検証しておきたい。いずれも「マネージド版では要件そのものを満たせない」という形の理由であり、費用差を動機にした選択とは性質が違います。

見送るべき場面の見分け｜運用要員が薄い構成とマネージド版で足りる時

逆に見送る判断も明確です。ストレージ層とバックアップと監視の責務が戻ってくる以上、DBの運用要員を確保できない体制では、マネージド版のAlloyDBかCloud SQLとは？GCPのマネージドRDBの仕組み・エディションと採用判断を実装者目線で解説で扱った選択肢のほうが総保有コストは下がります。列指向の処理もAI拡張も要らず、素のPostgreSQLで足りているなら、ライセンス費を負ってまで置き換える理由は薄いでしょう。MySQL系の資産が中心の環境については、PostgreSQLとMySQLの違いを徹底比較｜性能・データ型・全文検索・移行と使い分けで扱った移行コストを先に見積もってからの判断になります。既存環境の制約を洗い出したうえで、自社に置くか預けるかの線を引き直したい場合は、データ分析基盤構築・MLOps構築支援で構成案と移行手順の設計からご相談いただけます。

よくある質問

マネージド版のAlloyDBとデータ互換はありますか？

どちらもPostgreSQL互換で、中核部品を共有しています。ただしストレージ層の作りが違うため、マネージド版のバックアップをそのままOmniへ復元するといった操作は同一手順では行えません。移行は論理的なダンプとリストアを基本に設計してください。

無償のまま社内の本番システムで使えますか？

使えません。無償で提供されるのはライセンス条項に定義された評価目的の範囲で、本番配置には製品ライセンスのサブスクリプションが必要です。Googleの技術サポートを受ける前提としても、有効なサブスクリプションが求められます。

Windowsサーバの上で動かせますか？

Linux上で直接動作するようコンパイルされたソフトウェアで、要件に挙がっているのはDebian系OSとRHEL 8/9、そして開発用途としてのmacOSです。Windows環境で試す場合はLinuxの仮想マシンを用意し、その中でコンテナランタイムを動かす構成にしてください。

列ストアを有効にすれば分析クエリはすぐ速くなりますか？

既定の割り当てが1024MBのため、対象データが収まらなければ効果は限定的です。まずmemory_size_in_mbを見直して再起動し、そのうえで対象テーブルと列を絞り込んでください。それでも伸びない場合はディスク性能側が頭打ちになっている可能性があります。

コンテナ単体で始めて後からKubernetesへ移せますか？

移せますが、単なる置き換えではありません。オペレータ版はDBClusterというカスタムリソースで宣言的に管理する方式のため、設定の持ち方そのものが変わります。将来HAやDRが要件に入る見込みがあるなら、評価段階からオペレータ版で試しておくほうが手戻りは小さく収まります。

関連記事

• AlloyDBとは？PostgreSQL互換マネージドDBの構成・カラム型エンジン・料金と採用判断を実装者目線で解説
• Cloud SQLとは？GCPのマネージドRDBの仕組み・エディションと採用判断を実装者目線で解説
• PostgreSQLとMySQLの違いを徹底比較｜性能・データ型・全文検索・移行と使い分け
• Kubernetes（クバネティス）とは？仕組み・Dockerとの違い・読み方をわかりやすく解説
• pgvectorの基本概要とPostgreSQLにおけるベクトル検索