マネージドサービスとは？自前運用との違いをPostgreSQLで実測

この記事で実際に動かしたもの：自前の PostgreSQL 16.15（127.0.0.1 だけで待ち受け）の構築・TLS・WAL アーカイブ・ベースバックアップ・時点復元・レプリカ・昇格・クラッシュ後の再起動。クラウドには接続していません。

同じ PostgreSQL でも、自分で動かすと「入れる・設定する・守る・壊れたときに戻す」がすべて自分の仕事になります。マネージドの DB では、その下半分を提供側が持ちます。

flowchart TD
    A[データベースを使いたい] --> B{誰が運用する?}
    B -->|自分| C[自前運用<br>OS・DB・更新・<br>バックアップ・冗長化]
    B -->|提供側| D[マネージド<br>更新・バックアップ・<br>冗長化を任せる]
    C --> E[残る: 設計・SQL・権限・データ]
    D --> E

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（2 CPU・メモリ 8GB）の上で、Ubuntu のパッケージにある PostgreSQL 16.15 を root ではなく postgres ユーザーで、作業用のフォルダーに initdb して起動しました。待ち受けは 127.0.0.1 のポート 54239（主）・54240（復元先）・54241（レプリカ）だけで、外には出していません。作業場所の容量の都合で WAL のセグメントを 1MB（initdb --wal-segsize=1）にし、テスト用のデータは pgbench（スケール1、10万行）で作りました。TLS は openssl 3 で作った自己署名の証明書、バックアップは pg_basebackup・pg_dump、復元は restore_command と recovery_target_time、冗長化はレプリケーションスロット付きのストリーミングレプリケーションと pg_ctl promote で行い、時間は bash の time で測りました。ログは行頭の日時を省き、本文中の日付は「2026-10-xx」と伏せています。マネージドの DB（Amazon RDS・Cloud SQL・Azure Database for PostgreSQL）は接続もアカウント作成もしておらず、各社の公式ドキュメントと料金ページで確かめた範囲だけを書いています。図は mermaid で描画を確かめました（確認日 2026年10月29日）。

マネージドサービスとは（意味と場面別の使い分け）

この節では、マネージドサービスという言葉の意味と、使われる場面ごとの違いが分かります。

マネージドサービスとは、ある IT サービスを使うのに必要な機器やソフトウェアの導入・管理・運用までを、提供する側がまとめて引き受ける形のサービスです。利用者は「動かし続けるための作業」を任せ、自分はその上で作りたいものに時間を使います。任せる分の費用は利用料金に含まれます。

英語の managed は「管理された」という意味で、ふだんの言葉としては「誰かが面倒を見てくれている」状態です。IT ではこれが「運用をサービスの一部として提供する」という意味になります。ただし、同じ言葉が次のように少し違う場面で使われます。

この記事では、検索する人がいちばん迷いやすい「クラウドのマネージド製品」を中心に、データベース（DB）を例にして自分で運用する場合と比べます。運用代行としての意味は後半の節で扱います。

マネージドサービスと自分で運用する場合の違い（一覧）

この節では、マネージドサービスと自前運用の違いを、作業ごとの担当で比べられます。

違いは「どの作業を誰が持つか」です。Amazon RDS のユーザーガイドには、オンプレミス（自社の機械）・EC2（クラウドの仮想サーバーに自分で DB を入れる）・RDS（マネージドの DB）で、作業ごとに誰が担当するかの表が載っています。それを日本語にしたものが次の表です。

同じページで、RDS はクエリのチューニング（SQL を速くする調整）を「利用者の責任」とし、監視とチューニングは DB ごとに個別性が高い作業だと説明しています。表の「スケーリング」も、インスタンスの大きさをいつ変えるかを決めるのは利用者です。

自前でPostgreSQLを立てて分かった作業（実測）

この節では、自分で PostgreSQL を立てるとどんな作業があり、機械の時間がどれくらいかかったかが分かります。

機械が動く時間は、どの作業も1秒未満でした。時間がかかるのは、設定の意味を調べて決めること、失敗の原因を探すこと、そして動き続けているかを見張ることです。データが小さい（約37MB）ので、本番の大きさでは数値が変わります。

作業ごとの手数と時間

主の postgresql.conf に足したのは次の16行です。1行ごとに「何のためか」を決める必要がありました。

listen_addresses = '127.0.0.1'
port = 54239
unix_socket_directories = '/srv/s4/r17/t239/pg/sock'
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /dev/shm/t239/archive/%f && cp %p /dev/shm/t239/archive/%f'
archive_timeout = 60
ssl = on
logging_collector = on
log_directory = 'log'
log_min_duration_statement = 500
log_checkpoints = on
log_connections = on
min_wal_size = 4MB
max_wal_size = 16MB

起動して TLS で接続し、版と暗号化の状態を確かめた結果です。

$ psql "host=127.0.0.1 port=54239 user=postgres sslmode=require" -c "select version();"
 PostgreSQL 16.15 (Ubuntu 16.15-0ubuntu0.24.04.1) on x86_64-pc-linux-gnu, compiled by gcc ...

$ psql "... sslmode=require" -c "select ssl, version, cipher from pg_stat_ssl where pid=pg_backend_pid();"
 ssl | version |         cipher
-----+---------+------------------------
 t   | TLSv1.3 | TLS_AES_256_GCM_SHA384

最初の起動でつまずいた原文

証明書の鍵ファイルを root でコピーしたところ、最初の起動は失敗しました。ログの原文です。

FATAL:  could not load private key file "server.key": Permission denied
LOG:  database system is shut down

鍵の持ち主を postgres にし、権限を 600 にすると起動しました。マネージドの DB では、サーバー証明書の用意や入れ替えは提供側の作業です（RDS のメンテナンスの種類には server-certificate-rotation があると公式に書かれています）。

自分で確かめる（いまの接続が暗号化されているか）

自前でもマネージドでも、PostgreSQL ならターミナルで次の1行を打つと、いまの接続が TLS かどうかが分かります。t と TLS の版が出れば暗号化されています。

select ssl, version from pg_stat_ssl where pid = pg_backend_pid();

バックアップと時点復元を自前でやった記録

この節では、「誤って全件削除した直前に戻す」作業を自前で行うと、何が要るかが分かります。

時点復元（PITR）には、ベースバックアップと、その後の WAL（変更の記録）がすべて残っていることが必要です。マネージドの DB では、これが「保持期間内の任意の時点に復元できる」という機能になります。RDS のユーザーガイドは「バックアップ保持期間内の任意の時点に DB インスタンスを復元できる」と説明しています。

バックアップと検証の出力です。

$ pg_basebackup -d "host=127.0.0.1 port=54239 user=postgres sslmode=require" -D /dev/shm/t239/backup/base -Fp -Xstream -c fast -P
46154/46154 kB (100%), 1/1 tablespace
TIME 0.142 s

$ pg_verifybackup -n /dev/shm/t239/backup/base
backup successfully verified

$ psql ... -At -c "select archived_count, last_archived_wal, failed_count from pg_stat_archiver;"
49|000000010000000000000037.00000028.backup|0

復元先に足した設定は次の5行です（ポートは主とぶつからないよう変えています）。

port = 54240
archive_mode = off
restore_command = 'cp /dev/shm/t239/archive/%f %p'
recovery_target_time = '2026-10-xx 02:32:22+00'
recovery_target_action = 'promote'

起動すると、アーカイブから WAL を20個読み込み、削除の直前で止まりました。ログの抜粋です。

LOG:  starting point-in-time recovery to 2026-10-xx 02:32:22+00
LOG:  restored log file "000000010000000000000037" from archive
LOG:  restored log file "000000010000000000000038" from archive
  ...（20個）
LOG:  consistent recovery state reached at 0/3700100
LOG:  recovery stopping before commit of transaction 760, time 2026-10-xx 02:32:23.004536+00
LOG:  redo done at 0/4A19730 system usage: CPU: user: 0.03 s, system: 0.01 s, elapsed: 0.12 s
LOG:  selected new timeline ID: 2
LOG:  archive recovery complete

$ psql "host=127.0.0.1 port=54240 ..." -At -c "select count(*) from pgbench_accounts;"
100000

削除した10万行が戻りました。ただし、これが成り立ったのは「WAL が1つも欠けていない」「ベースバックアップが削除より前にある」「戻す時刻を控えていた」からです。どれか1つでも欠けると戻せません。自前では、この3つを毎日守る仕組み（アーカイブの失敗の通知、バックアップの定期実行、復元の練習）を作ることになります。

pg_dump での論理バックアップの使い方は、関連記事「pg_dump/pg_restoreの使い方｜バックアップとリストアの実行例」で扱っています。どこまで戻せればよいか（RPO）と、どれくらいで戻せればよいか（RTO）の決め方は、関連記事「バックアップ設計の書き方｜RPO・RTOの決め方と世代管理の計算例」で扱っています。

フェイルオーバーを自前でやった記録（スプリットブレインまで）

この節では、待機系（レプリカ）を作って主が止まったときに切り替える作業と、自前で起きやすい事故が分かります。

切り替えのコマンド自体は0.106秒で終わりましたが、「主が本当に止まったと判断する」「元の主を二度と書き込ませない」は自分で作る必要がありました。今回は元の主をそのまま起動し直し、両方が書き込みを受け付ける状態（スプリットブレイン）を実際に起こしています。

レプリカを作って同期を確かめる

$ pg_basebackup -d "host=127.0.0.1 port=54239 user=repl sslmode=require" -D /dev/shm/t239/replica -Xstream -R -S replica1 -c fast
TIME 0.137 s

$ psql （主） -x -c "select client_addr, state, sync_state, sent_lsn, replay_lsn, replay_lag from pg_stat_replication;"
client_addr | 127.0.0.1
state       | streaming
sync_state  | async
sent_lsn    | 0/5C00000
replay_lsn  | 0/5C00000
replay_lag  | 00:00:00.000098

レプリカに書き込もうとすると、次のエラーになります。読むだけの DB に接続していることが分かる原文です。

ERROR:  cannot execute INSERT in a read-only transaction

主を止めて、レプリカを昇格させる

アプリ側の接続文字列には、2台を並べて「書き込める方につなぐ」指定（target_session_attrs=read-write）を入れました。主を強制停止すると、どちらにもつながらなくなります。

$ pg_ctl -D primary -m immediate stop
$ psql "host=127.0.0.1,127.0.0.1 port=54239,54241 ... target_session_attrs=read-write" -c "select inet_server_port();"
psql: error: connection to server at "127.0.0.1", port 54239 failed: Connection refused
	Is the server running on that host and accepting TCP/IP connections?
connection to server at "127.0.0.1", port 54241 failed: session is read-only

$ pg_ctl -D replica -w promote
server promoted
PROMOTE 0.106 s

$ psql （同じ接続文字列） -At -c "select inet_server_port(), pg_is_in_recovery();"
54241|f

レプリカ側のログには、主との接続が切れたことと昇格が残りました。

FATAL:  could not receive data from WAL stream: SSL SYSCALL error: EOF detected
FATAL:  could not connect to the primary server: connection to server at "127.0.0.1", port 54239 failed: server closed the connection unexpectedly
LOG:  received promote request
LOG:  selected new timeline ID: 2
LOG:  database system is ready to accept connections

元の主を起動し直すと、2台とも書き込める

止めた元の主を、何も変えずに起動し直しました。強制停止のあとなので、まず自動の回復が走ります。

LOG:  database system was interrupted; last known up at 2026-10-xx 02:32:46 UTC
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at 0/5B000D8
LOG:  redo done at 0/5C47D78 ...
LOG:  database system is ready to accept connections

そして、元の主と新しい主の両方に書き込みが通りました。

元の主(54239): INSERT 0 1   pg_is_in_recovery = f   → 5|old-primary
新しい主(54241): INSERT 0 1  pg_is_in_recovery = f   → 4|after-failover, 6|new-primary

エラーは1つも出ません。2台のデータは別々に進み、あとから1つにまとめるのは手作業になります。自前で冗長化するときは、元の主を自動で起動させない、切り替え役（Patroni などのクラスタ管理）を置く、pg_rewind か作り直しで元の主をレプリカに戻す、といった仕組みまで作ります。マネージドの DB では、待機系の用意と障害の検出・切り替えを提供側が受け持ちます（RDS は「自動の障害検出と回復」、Azure はゾーンをまたいだ待機サーバーの自動用意と同期レプリケーションを公式に記載）。

レプリカの遅れと読み取りの振り分けは、関連記事「リードレプリカ設計の注意点｜レプリケーション遅延の対策と確認SQL」で扱っています。

自分で確かめる（いまつないでいるのは主か、読むだけの DB か）

ターミナルで次の1行を打ちます。f なら書き込める主、t ならレプリカ（読むだけ）です。マネージドの DB でも、読み取り用の接続先を使っているかを確かめるときに使えます。

select pg_is_in_recovery();

DB が応答しているかだけを見るなら、pg_isready が使えます。今回の結果は次のとおりで、止まっている方は終了コード 2 になりました。

$ pg_isready -h 127.0.0.1 -p 54241
127.0.0.1:54241 - accepting connections
$ pg_isready -h 127.0.0.1 -p 54239
127.0.0.1:54239 - no response
$ echo $?
2

マネージドDBで要らなくなる作業の対応表（AWS・Google Cloud・Azure公式）

この節では、自前で行った作業が、主なクラウドのマネージド DB ではどう扱われるかが分かります。

OS と DB の導入・更新、自動バックアップ、待機系と切り替えは、3社とも提供側の機能として公式ドキュメントに書かれています。細かな条件（保持期間・停止時間・対象の版）は製品と設定で変わるため、表は2026年10月29日時点の公式ドキュメントの記載の範囲です。

更新については、提供側がすべて決めるわけではありません。RDS は、ステータスが next window の更新は延期でき、required の更新は延期できず適用日を過ぎると適用される、と説明しています。Cloud SQL はハードウェアの更新を稼働を止めずに行い、OS と DB の更新は短時間の再起動を伴うと書いています。Azure も、パッチ適用中にサーバーが再起動する場合があり、時間帯を自分で指定できるとしています。

RDS の起動・停止・スナップショットをコマンドで操作する方法は、関連記事「AWS CLIでRDSを操作｜起動・停止・スナップショット・接続先取得」で扱っています。

マネージドサービスでも利用者に残る作業（責任共有モデル）

この節では、マネージドサービスを使っても任せられない作業と、責任共有モデルの考え方が分かります。

責任共有モデルとは、クラウドの安全を「提供側が守る部分」と「利用者が守る部分」に分けて考える枠組みです。AWS は、提供側の責任を「クラウドのセキュリティ（Security of the Cloud）」、利用者の責任を「クラウドにおけるセキュリティ（Security in the Cloud）」と呼び、利用者の範囲は選んだサービスによって変わると説明しています。仮想サーバーのように自由度の高いサービスほど利用者の範囲が広く、マネージドになるほど狭くなります。ただし、ゼロにはなりません。

• 1データそのものと、その分類何を保存するか、個人情報をどう扱うかは利用者が決める
• 2権限（誰が何をできるか）DB のユーザーとロール、クラウドの IAM。Cloud SQL もユーザーやデータベースの作成・削除は利用者と説明
• 3ネットワークの設計どこから接続できるか。インターネットに直接公開しない構成を選ぶ
• 4SQL と性能遅いクエリ、インデックス、接続数。RDS はクエリのチューニングを利用者の責任と明記
• 5容量と大きさの判断ストレージの伸びとインスタンスの大きさをいつ変えるか
• 6設定の選択保持期間・待機系の有無・メンテナンスの時間帯。選ばなければ既定値になる
• 7アプリ側の備え切り替えや更新のときの再接続、リトライ

今回の自前の DB では、遅いクエリを見つけるために log_min_duration_statement = 500 を入れていました。0.6秒待つ SQL を流すと、次の行がログに残ります。マネージドでも「どの SQL が遅いか」を見て直すのは利用者の仕事です。

LOG:  duration: 602.229 ms  statement: select pg_sleep(0.6);

どこまでを提供側が約束するかは、サービスレベル契約（SLA）で決まります。SLA の項目の読み方は、関連記事「SLAの項目例と目標値一覧 SLO・SLIとの違いと合意書ひな形」で扱っています。

IaaS・PaaS・SaaS・サーバーレスとマネージドサービスの関係

この節では、マネージドサービスがクラウドの分類のどこに当たるかが分かります。

マネージドサービスは分類の名前ではなく、「運用を誰が持つか」の度合いを表す言葉です。IaaS（仮想サーバー）は利用者の範囲が広く、PaaS や SaaS に近づくほど提供側の範囲が広がります。マネージドの DB は PaaS に近い位置にあります。

1. 1オンプレミス：すべて自分建物・電源・機械・OS・DB・データ
2. 2IaaS（仮想サーバーに自分で DB）：OS から上が自分今回の自前の PostgreSQL はここに近い
3. 3マネージドの DB（PaaS に近い）：DB の中身と設定の選択が自分OS・DB の更新、バックアップ、待機系は提供側
4. 4サーバーレスの DB：大きさの判断もほぼ提供側使った分の課金。インスタンスを選ばない形が多い
5. 5SaaS：使うだけデータと利用者の管理が残る

AWS の責任共有モデルのページは、Amazon S3 や DynamoDB のような「抽象化されたサービス」では、AWS がインフラ・OS・プラットフォームを運用し、利用者はデータの管理（暗号化の選択を含む）・資産の分類・IAM の権限に責任を持つ、と説明しています。どの段でも、データと権限は利用者に残ります。

MSP（運用代行）としてのマネージドサービス

この節では、「マネージドサービス」が運用の外部委託を指す場合の意味と、確かめる点が分かります。

MSP（マネージド・サービス・プロバイダー）とは、他社の機器やクラウドの監視・保守・障害対応などを、契約で決めた範囲で代わりに行う事業者です。クラウドの製品は「その製品の運用」を受け持ちますが、MSP は複数の製品や社内の機器をまとめて運用することがあります。料金は月額の定額で、SLA に沿って対応するのが一般的です。

対応の仕方には、壊れたときに直す「都度対応（Break/Fix）」と、更新や予防保守を先回りして行う「予防型」があります。どちらの形かで、費用と止まる時間の考え方が変わります。

委託するときに確かめる点は、次の5つにまとめられます。

• 範囲：どの作業を任せ、どの作業が自社に残るか（今回の対応表のような表を作る）
• 連絡：障害時に誰が誰へ、何分以内に連絡するか
• セキュリティと決まりごと：権限の渡し方、ログの保管、社内規程との整合
• SLA と監視：稼働率・対応時間の約束と、それを確かめる方法
• 費用と効果：安さだけで選ぶと、必要な対応が契約に含まれないことがある

マネージドサービスの費用の考え方

この節では、マネージドサービスと自前運用の費用を、同じ物差しで比べる方法が分かります。

マネージドの DB は同じ大きさの仮想サーバーより単価が高くなりますが、比べるべきは「サーバー代＋人の時間＋当番」です。今回の自前の作業は機械の時間が1秒未満でも、設定の意味を調べる時間、失敗の切り分け、夜間に止まったときの対応は、毎月かかり続けます。

公式の料金ページで確かめた、料金の仕組みの例です（2026年10月29日時点）。

• Cloud SQL（Enterprise エディション・アイオワのリージョンの例）：vCPU が1時間 $0.0413、メモリが 1GiB・1時間 $0.007、SSD ストレージが 1GiB・1時間 $0.000232877。高可用性の構成では vCPU・メモリ・ストレージの単価がおおむね2倍。
• Amazon RDS for PostgreSQL：インスタンス時間（1秒単位・最低10分）、ストレージ、バックアップストレージ、データ転送が分かれて課金される。停止中はインスタンス時間はかからないが、ストレージとバックアップストレージはかかる。サポートが終わったメジャーバージョンには RDS Extended Support の料金がかかる。
• Azure Database for PostgreSQL：サーバーを停止すると計算の課金はすぐ止まる。停止したサーバーは7日間停止したままで、その後は起動する。

Cloud SQL の単価で計算すると、2 vCPU・メモリ 8GiB を1か月（730時間）動かした計算資源の料金は、(2 × 0.0413 ＋ 8 × 0.007) × 730 ≒ $101、高可用性にするとおおむね $202 です。SSD 100GiB は 100 × 0.000232877 × 730 ≒ $17 です。リージョンやエディションで単価が変わるため、実際の見積もりは各社の料金計算ツールで行います。

自前の側に足す「人の時間」は、次の作業を月に何時間行うかで見積もります。夜間・休日に呼び出される当番を置くなら、その分も入れます。

マネージドサービスのメリットとデメリット

この節では、マネージドサービスを使う利点と注意点が分かります。

利点は「運用の手間と事故の種類が減る」こと、注意点は「選べる範囲が提供側の範囲までになる」ことです。

移しやすさについては、PostgreSQL や MySQL などの互換のマネージド DB なら、pg_dump のような標準の道具で中身を取り出せます。今回も pg_dump で約290KB のファイルに書き出せました。提供側独自の機能を使う部分だけが、移すときの作業になります。

よくあるエラー／つまずき（自前とマネージド）

この節では、自前の PostgreSQL で実際に出た原文と、マネージドにしたときの扱いが分かります。

マネージドの DB では、OS にログインできないため、ログや状態は提供側の画面・コマンド・監視の道具で見ます。「サーバーに入って直す」という手段がない前提で、監視とアラートを先に用意しておきます。

マネージドサービスにするかどうかの判断表

この節では、自分たちの状況でマネージドと自前のどちらが向くかを判断できます。

迷ったら、まず「自前で運用するなら誰が何をするか」を、この記事の作業ごとの表に名前を入れて書き出します。名前が入らない行が多いほど、マネージドが向いています。

マネージドサービスでよくある質問

この節では、マネージドサービスについてよく聞かれる質問への答えが分かります。

Q. マネージドサービスとフルマネージドの違いは？
フルマネージドは、任せる範囲がより広い（利用者がほぼ技術的な対応をしなくてよい）ものを指す呼び方です。明確な定義はなく、提供する会社によって使い方が違います。言葉より、何が含まれるかを対応表で確かめるのが確実です。

Q. マネージドサービスにすれば、運用担当は要らなくなりますか？
手を動かす作業は減りますが、権限・ネットワーク・SQL の性能・容量の判断・設定の選択は利用者に残ります。責任共有モデルの節の7項目を受け持つ人は必要です。

Q. マネージドの DB でも、自分でバックアップを取るべきですか？
自動バックアップは保持期間内の時点に戻すためのものです。保持期間より長く残したいデータや、別の環境へ持ち出したいデータは、pg_dump などで別に取っておくと安心です。

Q. マネージドとサーバーレスの違いは？
どちらも運用を任せる形ですが、サーバーレスはインスタンスの大きさを選ばず、使った分だけ課金される形が多いです。マネージドの DB は、大きさを選んで動かし続ける形が中心です。

Q. マネージドサービスは高いですか？
単価は高くなりやすいですが、自前では更新・監視・当番・復元の練習に人の時間がかかります。費用の考え方の節の表で、人の時間を含めて比べます。

Q. メンテナンスで DB は止まりますか？
短い停止や再起動が起きることがあります。RDS は週1回のメンテナンスウィンドウ、Cloud SQL はメンテナンス更新で短時間の停止、Azure はパッチ適用中の再起動があり得ると公式に書かれています。時間帯を選べるので、利用の少ない時間にします。

Q. 別のクラウドへ移せなくなりませんか？
PostgreSQL や MySQL などの互換の製品なら、標準の道具で中身を取り出せます。提供側独自の機能や周辺のサービスに頼った部分は、移すときに作り直しが要ります。

Q. MSP と、クラウドのマネージド製品はどう違いますか？
クラウドのマネージド製品は、その製品の運用を提供側が受け持ちます。MSP は、複数の製品や社内の機器をまとめて、契約した範囲で運用する事業者です。

Q. 学習するなら、自前とマネージドのどちらがよいですか？
仕組みを知るには、手元で自前の DB を動かすのが近道です。この記事の手順のように、時点復元やフェイルオーバーを一度自分で行うと、マネージドが何を代わりにしているかが分かります。

Q. 自分の使っている DB がマネージドかどうか、どう確かめますか？
接続先のホスト名が提供側のドメインになっているか、作成した画面・コマンドがクラウドの DB 用のものかで分かります。SQL からは select version(); で版を、select pg_is_in_recovery(); で主かレプリカかを確かめられます。

まとめ

この節では、記事の要点を5つで振り返れます。

• マネージドサービスとは、導入・更新・バックアップ・障害対応などの運用を提供側が引き受けるサービス。運用代行（MSP）を指す場面もある。
• 自前の PostgreSQL では、どの作業も機械の時間は1秒未満。時間がかかるのは、設定を決めること・失敗の切り分け・見張りと当番。
• 時点復元は WAL が1つも欠けないことが条件で、フェイルオーバーでは元の主を起動し直すとスプリットブレインがエラーなしで起きた。
• マネージドの DB では、OS・DB の更新、自動バックアップ、待機系と切り替えを提供側が持つ。データ・権限・ネットワーク・SQL の性能・設定の選択は利用者に残る（責任共有モデル）。
• 費用は「サーバー代＋人の時間＋当番」で比べ、当番を置けない・冗長化の経験が少ないならマネージド、特殊な設定が必須なら自前を選ぶ。

参考・出典

確認日はいずれも 2026年10月29日です。料金と機能は変わることがあるため、各社の公式ページで最新の内容を確かめてから判断します。

• Amazon Web Services「What is Amazon Relational Database Service (Amazon RDS)?」（責任分担の表・shared responsibility model）：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html
• Amazon Web Services「Introduction to backups」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html
• Amazon Web Services「Maintaining a DB instance」：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html
• Amazon Web Services「Amazon RDS for PostgreSQL Pricing」：https://aws.amazon.com/rds/postgresql/pricing/
• Amazon Web Services「Shared Responsibility Model」：https://aws.amazon.com/compliance/shared-responsibility-model/
• Google Cloud「Cloud SQL overview｜Cloud SQL for PostgreSQL」：https://docs.cloud.google.com/sql/docs/postgres/introduction
• Google Cloud「Cloud SQL pricing」：https://cloud.google.com/sql/pricing
• Microsoft Learn「What is Azure Database for PostgreSQL flexible server?」：https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/overview
• PostgreSQL Global Development Group「PostgreSQL 16 Documentation」（Continuous Archiving and Point-in-Time Recovery・High Availability・pg_basebackup・pg_ctl）：https://www.postgresql.org/docs/16/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。