Azure Database for PostgreSQLは、Microsoftがバックアップ・修正プログラムの適用・フェールオーバーを引き受けた形でPostgreSQLを動かすマネージドサービスです。素のPostgreSQLと同じSQLが通り、拡張機能もそのまま入る一方で、可用性の組み方・認証方式・ネットワークの引き回しはAzure側の作法に従います。とくにネットワークと階層の選択は作成時にほぼ確定してしまうため、設計の順番を間違えると作り直しが発生します。
この記事では、Azure上のもう一方のマネージドDBであるAzure SQL Databaseとは？仕組み・購入モデルとサービス階層と、AWS側で同じエンジンを動かすAmazon RDS for PostgreSQLとは？マルチAZ構成と拡張機能の統制には各サービス固有の話を譲り、Azure上のPostgreSQLに固有の構成と運用へ絞って扱います。データベースの種類そのものを整理したい場合はデータベースとは？種類・DBMS・RDBとNoSQLの選び方から読み進めてください。数値は2026年8月時点のMicrosoft公式ドキュメントで実測しています。
まとめ：導入前に決め切る4点
- デプロイの型：単一サーバーは2025年3月28日に廃止済みで、選べるのはフレキシブルサーバーだけです。水平シャーディングが要るならエラスティック クラスターという別枠に進みます
- 階層の選択：バースト可能はMicrosoft自身が非運用環境向けと明記しており、クレジットが枯れるとサーバーへ到達できなくなる可能性があります。本番は汎用以上から選びます
- 可用性の型：ゾーン冗長は約99.99%、同一ゾーンは約99.95%のSLAです。ただしどちらもスタンバイは読めず、読み取り分散にはなりません
- ネットワーク：仮想ネットワーク統合を選ぶと、後から別の仮想ネットワークやサブネットへ移せません。サブネットのアドレス空間も広げられないため、設計は一発勝負になります
単一サーバー廃止後に残った構成の選択肢と対応バージョンを整理する
このサービスには長らく単一サーバーとフレキシブルサーバーという2つのデプロイ方式があり、解説記事の多くがその対比を軸に書かれてきました。その前提はすでに崩れています。単一サーバーは2025年3月28日に廃止され、移行期限を過ぎたインスタンスは停止されました。2026年8月時点で新規に作れるのはフレキシブルサーバーだけです。
フレキシブルサーバーへ収束した現在の対応バージョンを確認する
公式ドキュメントが現在サポートすると示しているメジャーバージョンは18・17・16・15・14で、13・12・11は延長サポートの扱いです。新しいサーバーはそれぞれの最新マイナーで作成され、2026年8月時点では18系が18.4、17系が17.10、16系が16.14となっています。マイナーリリースは毎月のデプロイで自動的に当たるため、パッチ当ての運用そのものは持たなくて済みます。
最新版へ寄せるときに注意したいのが、18系には一部の拡張機能が未対応という制限が付いている点です。非同期入出力のio_method = io_uringも選べません。使いたい拡張が決まっているなら、版を決める前に対応表を引いてください。エンジンそのものの性格やMySQLとの違いを踏まえて選び直したい場合はPostgreSQLとMySQLの違いを徹底比較｜性能・データ型・移行と使い分けが参考になります。
エラスティック クラスターで水平方向へ広げる適用条件を見極める
1台の縦方向のスケールで足りない規模になった場合、エラスティック クラスターという選択肢があります。実体はCitus拡張のマネージド提供で、複数のフレキシブルサーバーがノードとして相互接続し、シェアードナッシング構成のクラスターを組みます。行ベースとスキーマベースという2つのシャーディングモデルから選ぶ形です。
実装面で押さえておく差は2つあります。まず、既定ではテーブルもスキーマも自動では分散されません。どちらのモデルで分散するかを設計者が決めて明示的に配る必要があります。次に、DML操作はどのノードへ接続しても通る一方、DDL操作とクラスター全体の操作はコーディネーターの役割を持つノードに限られ、ポート5432へ接続して実行します。ノードを足したあとの再調整はオンライン操作で、動いているワークロードを止めません。
コンピューティング階層とストレージ種別で決まる費用の見積もり方
料金はvCore・ストレージ・バックアップの3つの軸で積み上がります。まず階層を決め、次にディスクの種類を決めるという順番になります。
バースト可能階層を本番へ置いたときに起きる運用リスクを把握する
階層はバースト可能・汎用・Memory Optimizedの3つです。バースト可能はBシリーズで1〜20 vCore、汎用はDdsv6系などで2〜192 vCore、Memory OptimizedはEdsv6系などでvCoreあたり6.75〜9.5 GiBのメモリが付きます。ストレージはどの階層でも32 GiBから64 TiBまで、自動バックアップの保持期間は7〜35日、長期保持は最大10年です。
費用だけ見るとバースト可能が魅力に映るでしょう。ただしMicrosoftはこの階層についてかなり踏み込んだ注意書きを置いており、CPUがベースライン付近で長時間動くとクレジットが枯渇し、サーバーへ到達できなくなる可能性があると明記しています。さらに、主に開発・ステージング・テストなど非運用環境向けの設計であり、24時間365日のサポートを受けられず根本原因分析が提供されない場合があるとも書かれています。検証環境をこの階層で組むのは理にかなっていますが、本番を載せる判断は取れません。
Premium SSDとPremium SSD v2でIOPS課金の形が変わる
ディスクはPremium SSDとPremium SSD v2の2種類です。v2は容量を1 GiB刻みで決められ、IOPSとスループットを容量と切り離して調整できます。従来のPremium SSDが容量に応じてIOPSが決まる階段状の設計だったのに対し、v2は必要な分だけ買える形になりました。
| 観点 | Premium SSD | Premium SSD v2 |
|---|---|---|
| 最大ディスクサイズ | 32,767 GiB | 65,536 GiB |
| 最大IOPS | 20,000 | 80,000 |
| 最大スループット | 900 MB/秒 | 1,200 MB/秒 |
| 容量の刻み | 既定のサイズから選ぶ | 1 GiB刻みで自由 |
v2には既定のクォータがあり、サブスクリプションとリージョンの組み合わせごとに32 TiBまでです。それを超える構成を組むなら、クォータの引き上げ申請を工程へ入れておいてください。無償のベースラインスループットは399 GiBまでが125 MB/秒、400 GiB超が500 MB/秒で、これを超える分は追加料金になります。
ディスク枯渇の挙動も設計へ織り込む対象です。使用率が95%に達するか空き容量が5 GiBを切ると、サーバーは自動的に読み取り専用へ切り替わります。ストレージは拡張しかできず縮小できないため、監視でstorage_percentageを追い、余裕のあるうちに広げる運用が前提になります。
ゾーン冗長HAと同一ゾーンHAの構成差とSLAの読み方を比較する
高可用性は、物理的に分離したプライマリとスタンバイを立てる形で提供されます。スタンバイを別の可用性ゾーンへ置くゾーン冗長と、同じゾーン内へ置く同一ゾーンの2つがあり、SLAはそれぞれ約99.99%と約99.95%です。ゾーン冗長はバースト可能階層では使えず、可用性ゾーンが単一のリージョンでも選べません。
同期コミットとWALレプリカが支えるクォーラムの構造を理解する
プライマリとスタンバイの間は同期レプリケーションです。アプリケーションの書き込みはプライマリのWALへ記録され、Postgresのストリーミングプロトコルでスタンバイへ送られます。スタンバイ側のストレージがログを保持した時点でプライマリが完了を確認し、そこで初めてコミットが返る流れです。この往復ぶんの待ち時間が書き込みに乗るため、遅延の増加はゾーン冗長を選ぶ代償として見積もっておきます。読み取りクエリには影響しません。
見落とされやすいのが、スタンバイとは別にWALレプリカサーバーがもう1つ、さらに別の可用性ゾーンへ置かれている点です。スタンバイが一時的に使えない状況では、プライマリとWALレプリカの間でトランザクションをコミットして永続性を保ちます。このWALレプリカが昇格することはなく、あくまでコミットのクォーラムを維持する役回りです。ゾーン障害が起きた場合、ゾーン冗長なら60〜120秒でデータ損失なくフェールオーバーします。
高可用性を入れても解けない読み取り分散と論理エラーを区別する
ここは判断を分ける箇所なので言い切ります。スタンバイHAサーバーは読み取りクエリに使えません。追加のスタンバイを構成することもできません。つまり高可用性を有効にしても読み取り性能は1台ぶんのままで、参照系を逃がしたいなら読み取りレプリカを別途立てる設計になります。可用性の費用と読み取り拡張の費用は別勘定です。
もう1つ、テーブルの誤削除や不適切な更新といった論理エラーはスタンバイへそのまま複製されます。スタンバイはこの種の事故から復旧する手段になりません。復旧はバックアップからのポイントインタイムリストアで行い、復元先は単一ゾーンのフレキシブルサーバーとして新しく立ち上がります。ワークロードの復旧目標を書くときは、この2段構えを分けて記述してください。
論理レプリケーションをフェールオーバーへ耐えさせる設定を選ぶ
論理レプリケーションを外部へ流している構成では、版ごとに作法が異なる点に注意してください。PostgreSQL 16以前ではフェールオーバー後に論理レプリケーションスロットがスタンバイへ引き継がれないため、pg_failover_slots拡張を有効にしhot_standby_feedbackをonにする必要があります。17以降はスロット同期がネイティブに入り、sync_replication_slotsとhot_standby_feedbackをonにすれば拡張なしで継続できます。
厄介なのは、pg_replication_slotsを見てもプライマリ側の状態しか映らず、スタンバイへ同期されているかを確認できない点です。プライマリでは健全に見えるのにフェールオーバー後に止まる、という形で表面化します。Azure Monitorのlogical_replication_slot_sync_statusを監視項目へ入れ、値が0のまま続く場合にアラートを上げる構成にしておきましょう。なおこの指標を出すにはmetrics.collector_database_activityをonにしておく必要があります。
Entra ID認証とネットワーク分離を作成時に決め切る設計手順
セキュリティの設計は認証とネットワークの2面です。前者は後から足せますが、後者は実質的に作成時の一発勝負になります。
三つの認証モードとトークン有効期間が生む具体的な運用差を理解する
認証モードはPostgreSQL認証のみ・Microsoft Entra認証のみ・両方の3つです。Entra認証を有効にするとPGAadAuth拡張が有効になりサーバーが再起動するため、稼働後に切り替えるなら停止枠を確保してください。Entra管理者にはユーザーのほかグループ・サービスプリンシパル・マネージドIDを指定でき、グループを充てておくとメンバーの出入りをデータベース側の権限変更なしで捌けます。
運用で効いてくるのはトークンの寿命と同一性の扱いです。ユーザートークンは最大1時間、システム割り当てマネージドIDのトークンは最大24時間有効で、Entra IDからユーザーを削除しても発行済みトークンが切れるまで最大60分はサインインできてしまいます。即時に断ちたいなら、データベース側のロールも併せて消す手順が要ります。加えて、照合はユーザー名ではなく一意のユーザーIDで行われるため、同じ名前で作り直したユーザーは別人として扱われ既存ロールへ接続できません。退職と再入社が起こる組織では、この挙動を運用手順書へ書いておく価値があります。
委任サブネットは作成後に動かせないという前提条件で設計を固める
ネットワークは、仮想ネットワーク統合によるプライベートアクセスか、許可IPによるパブリックアクセスとプライベートエンドポイントの組み合わせか、どちらかを作成時に選びます。前者を選ぶ場合、サーバーは委任サブネットへ入る必要があり、そのサブネットにはMicrosoft.DBforPostgreSQL/flexibleServersという委任を付けたうえで他のリソースを同居させられません。
アドレス設計も先に詰めます。指定できる最小のCIDRは/28で、Azureの予約を差し引くと使えるIPは11個です。高可用性を付けたサーバー1台で4アドレスを消費するため、同じサブネットに何台載せるかで枠が決まります。そしてデプロイ後は別の仮想ネットワークやサブネットへ移せず、リソースが存在するサブネットのアドレス空間を広げることもできません。
周辺にも複数の制約が伴う構成です。プライベートDNSゾーンの指定は必須で、名前は.postgres.database.azure.comで終わる必要があります。カスタムDNSを使うなら168.63.129.16のフォワーダー経由で解決させます。NSGを立てる場合は宛先ポート5432と、ログ格納先であるStorageサービスタグへの通信を許可してください。すべての送信をネットワーク仮想アプライアンスへ寄せるキャッチオールルートは非対応で、高可用性を含む中核の操作が壊れる可能性があります。仮想ネットワーク統合とプライベートエンドポイントを跨ぐ形での可用性ゾーン構成もサポート外なので、どちらかへ寄せる判断が要ります。
採用する条件と別のマネージドDBへ寄せる場面の線引きを判断する
ここまでの実測を踏まえ、判断の線を引きます。採用が素直に通るのは、アプリケーションがすでにAzure上にあり、Entra IDでの認証統合とプライベートアクセスによる閉域構成を要件として持ち、PostgreSQLの拡張機能をそのまま使いたいケースです。とくにEntra管理者にグループを充てられる点は、権限管理をAzure側へ寄せたい組織で効きます。バックアップの長期保持が最大10年まで伸ばせるため、保管年限が法令で決まる業務にも収まります。
逆に見送りを検討すべき場面もはっきりしています。読み取りの拡張が主目的なら、高可用性を足しても解決しないため、読み取りレプリカの費用まで含めて他の選択肢と比べ直してください。待機側も読み取りへ回したい要件ならAmazon RDS for PostgreSQLのマルチAZ DBクラスター配置のほうが素直に収まりますし、分析系の並列処理を寄せたいならAlloyDBとは？PostgreSQL互換マネージドDBの構成とカラム型エンジンのカラム型エンジンが候補に入ります。Babelfishのような互換レイヤーが要る場合や、AWS側で版計画を組み直したい場合はAurora PostgreSQLとは？対応バージョン・拡張機能とBabelfishを見てください。SQL Serverからの移行が主題で購入モデルの比較が要るならAzure SQL Databaseとは？購入モデルとサービス階層の違いのほうが近い位置にあります。
移行の入り口としては、Azure VMやオンプレミス、Amazon RDS、Aurora、Google Cloud SQL、AlloyDBからの経路が移行サービスとして用意されており、オフラインとオンラインの両方が選べます。停止枠を数分に収めたいならオンラインを選ぶ形です。どのクラウドへ寄せるか、可用性とネットワークをどう組むかを含めた基盤設計から相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）で要件整理から構築・移行まで引き受けています。
よくある質問
単一サーバーで動いている環境は今どうなっていますか？
2025年3月28日に廃止されており、移行期限を過ぎたインスタンスは停止されました。現在新規に作成できるのはフレキシブルサーバーだけです。単一サーバー前提で書かれた解説記事や社内手順書が残っている場合は、その時点で内容が古いと判断してかまいません。
バースト可能階層で本番を動かしてはいけませんか？
推奨されません。CPUがベースライン付近で長く走るとクレジットが枯渇し、パフォーマンス低下や接続タイムアウトに加えてサーバーへ到達できなくなる可能性があるとMicrosoftが明記しています。さらにこの階層は非運用環境向けの設計で、24時間365日のサポートや根本原因分析が提供されない場合があるとも書かれています。開発・検証で使い、本番は汎用以上へ置いてください。
ゾーン冗長にすればフェールオーバーは何秒で終わりますか？
公式には60〜120秒でデータ損失なく切り替わるとされています。ただしプライマリ側の負荷次第では、スタンバイの復旧処理に時間がかかり120秒を超える場合もあります。スタンバイのWAL復旧速度は通常40 MB/秒、大きい構成でも200 MB/秒程度なので、書き込み量がこれを上回るワークロードでは余裕を見た復旧見込みを立てておきましょう。
スタンバイを読み取り用に使って参照を逃がせますか？
使えません。高可用性のスタンバイは読み取りクエリを受け付けず、追加のスタンバイも構成できない仕様です。参照系を逃がしたい場合は読み取りレプリカを別に立てる設計になり、その費用は可用性の費用とは別に積み上がります。
作成後にネットワーク方式を変更できますか？
実質的にできないと考えてください。仮想ネットワーク統合でデプロイしたサーバーは別の仮想ネットワークやサブネットへ移せず、サブネットのアドレス空間もリソースが存在する状態では広げられません。将来の台数と高可用性の有無まで見込んだうえで、最小/28という枠に対して必要なIP数を先に計算しておく作業が要ります。
