小規模チーム向け：マネージド vs セルフホスト PostgreSQL のトレードオフ

本当に選んでいるのは何か

「マネージド PostgreSQL」と言うと、多くの場合はクラウドサービスが PostgreSQL を運用し、日常の作業を代行してくれることを指します。一方「セルフホスト PostgreSQL」は VM、ベアメタル、コンテナなどで自分たちで動かし、周辺の運用もチームが全部持つことを意味します。

最大の違いは PostgreSQL 本体ではありません。運用上の仕事、そして夜中の 2 時に何かが壊れたときに誰が対処するかです。小規模チームにとって、その運用ギャップがリスクを左右します。誰も深いデータベース運用の経験がないと、同じ問題が「面倒」から「本番障害」に短時間で変わることがあります。

マネージドとセルフホストの選択は、実際には所有権に関する決断です。

• バックアップと復元（そしてそれが機能することの検証）
• アップグレードとセキュリティパッチの適用
• パフォーマンス、ストレージ増加、接続上限の監視
• レイテンシが悪化したときやデータベースが立ち上がらないときのオンコール責任

最後の点は劇的に聞こえますが、実務的です。マネージドならプロバイダが多くの作業を自動化し、サポートや運用手順を持っていることが多いです。セルフホストでは自由度は高まりますが、ディスクの枯渇、設定ミス、失敗したアップグレード、ノイジーな隣接 VM、忘れられたアラートなど、あらゆる角にぶつかります。

間違った選択は予測しやすい形で現れます。多くのチームは誰も練習した復元手順を持っていないために避けられる障害で何時間も失い、あるいはチューニングの時間がなくて遅いクエリを放置します。マネージドはストレージや I/O の増加、複製の追加で請求が驚くほど増えることがあります。セルフホストは安く見えても、常時の見守りコストを数えると高くつくことがよくあります。

例：4人チームが AppMaster のようなノーコードプラットフォーム上で社内向けオペスアプリを作り、データモデルに PostgreSQL を使っているとします。機能開発に集中したければ、マネージド DB は月当たりの「運用日数」を減らしてくれることが多いです。厳密な制御（カスタム拡張、特殊なネットワーク、厳格なコスト上限）が必要ならセルフホストが合うこともありますが、その場合は誰かが本当にエンドツーエンドで所有していることが前提です。

バックアップと復元：人がテストを忘れがちな部分

バックアップはチェックボックスではなく、約束です。ミスや障害のあとに十分に新しく、かつ十分速くデータを戻せることが求められます。マネージドとセルフホストの比較で、小規模チームが最も差を感じるのはここです。

ほとんどのチームは三層を必要とします：

• ベースラインの安全のためのスケジュールされた自動バックアップ
• スキーマ更新などのリスクの高い変更前の手動スナップショット
• 誤って行われた DELETE の直前など、特定の時点に戻せるポイントインタイムリカバリ（PITR）

二つの用語で期待値を整理します。

RPO（Recovery Point Objective）はどれだけのデータを失えるかです。RPO を 15 分とするなら、最大 15 分分のデータ損失で復旧できるバックアップとログが必要です。

RTO（Recovery Time Objective）はどれくらいの時間ダウンしてもよいかです。RTO が 1 時間なら、復元手順は練習済みで予測可能でなければなりません。

復元テストは省略されがちです。多くのチームはバックアップは存在するが不完全、復元が遅すぎる、あるいは正しい鍵や権限がなくて使えないことを遅れて発見します。

セルフホストでは隠れた作業がすぐに現れます：保持期間ルール（何日分残すか）、保存時と転送時の暗号化、アクセス制御、資格情報と鍵の保管場所。マネージドサービスはデフォルトを提供することが多いですが、それが自分たちの RPO／RTO／コンプライアンスに合っているかは確認が必要です。

選ぶ前にこれらに答えられるようにしてください：

• フルリストアはどう行い、通常どのくらい時間がかかるか？
• PITR はサポートされるか、復元の最小単位は何か？
• デフォルトの保持・暗号化設定は何か、変更できるか？
• 誰がバックアップにアクセスし、復元操作を行えるか、監査はどうなっているか？
• 本番を止めずに定期的に復元をテストする方法は？

簡単な習慣：四半期ごとに一度、一時環境への復元ドリルを予定してください。AppMaster のようなツールでアプリを作っていても、PostgreSQL が裏にあるなら、このドリルが「バックアップがある」状態を本物の自信に変えます。

アップグレードとパッチ適用：誰が運用負荷を負うか

アップグレードは触るものが多いので単純そうに見えてそうではありません：DB エンジン、拡張、クライアントドライバ、バックアップ、監視、場合によってはアプリケーションコードです。専任 DBA がいないチームにとって重要なのは「アップグレードできるか」ではなく「誰が安全に実行し、失敗したら誰に通知されるか」です。

マイナーとメジャーの違い（感じ方が違う理由）

マイナーアップデート（例：16.1 → 16.2）は主にバグ修正やセキュリティパッチです。通常リスクは低いですが再起動が必要で、拡張の動作に依存していると壊れることがあります。

メジャーアップグレード（例：15 → 16）はクエリプランが変わったり機能が廃止されたりし、移行手順が必要になることがあります。アップグレードツールが動いても性能検証や拡張・ORM との互換性チェックを行う時間が欲しいです。

セキュリティパッチ：緊急性とスケジュール

重大な Postgres や OpenSSL の脆弱性が出たら、パッチは待ってくれません。マネージドならパッチ適用は多くの場合プロバイダが扱ってくれますが、タイミングの細かい制御は限られることがあります。メンテナンスウィンドウを選べるプロバイダもあれば、急にアップデートされることもあります。

セルフホストでは完全にスケジュールを管理しますが、その代わりにアドバイザリの監視、重要度判断、ダウンタイムの計画、プライマリとレプリカ全体への適用確認を誰かが実行しなければなりません。

セルフホストで安全にアップグレードするにはいくつかの必須事項があります：本番に近いステージング環境、データを考慮したロールバック計画、拡張やドライバの互換性チェック、現実的なドライランで想定ダウンタイムを見積もること。終了後の短い検証チェックリストも必要です：レプリケーション、バックアップ、クエリ性能の確認。

業務時間とリリースに合わせた計画

ユーザが気づかないのが最も安全なアップグレードです。小規模チームでは、データベース作業をリリースリズムに合わせることが重要です。主要な機能リリースと同じ日にアップグレードするのは避け、サポート負荷が低い時間帯を選び、作業後に誰かがメトリクスを監視できるようにしてください。

実践例：PostgreSQL を使う内部ツール（たとえば AppMaster で生成・ホストされたアプリ）の場合、メジャーアップグレードは単なる「DB 作業」ではありません。API クエリの挙動が負荷下で変わることがあります。静かなウィンドウで、プロダクションに近い複製でテストし、ライブに触る前に明確な続行／停止の判断点を設けてください。

マネージドは手間を減らし、セルフホストはハンドルを握る感覚です。実際の差は運用負荷です。

パフォーマンスチューニングと制御：自由度 vs ガードレール

パフォーマンスはマネージドとセルフホストで最も違いを感じやすい領域です。マネージドでは安全なデフォルトやダッシュボード、いくつかの調整項目が提供されます。セルフホストではほぼ全てを変更できますが、悪影響も自分で引き受けます。

変更できることとできないこと

多くのマネージドプロバイダはスーパーユーザ権限や一部のサーバーフラグ、低レベルのファイル設定を制限します。一般的なパラメータ（メモリ、接続上限、ログ）は調整できることが多いですが、すべてではありません。拡張も分かれ目になります：人気のある拡張は提供されますが、ニッチな拡張やカスタムビルドが必要ならセルフホストが普通は唯一の選択です。

ほとんどの小規模チームは特殊なフラグを必要としません。必要なのは基本を健康に保つことです：適切なインデックス、安定した autovacuum、予測可能な接続数。

実際に効くチューニング作業

多くの PostgreSQL のパフォーマンス向上は地味で再現性のある作業です：

• 毎日使うクエリ（特にフィルタや結合）にインデックスを張る
• autovacuum とテーブルの膨張を放置して障害にする前に監視する
• 現実的な接続上限を設定し、必要ならプーリングを使う
• メモリを適切に割り当て、大きな不要なスキャンを避ける
• リリースごとにスロークエリをレビューする（ユーザ苦情が出てからでは遅い）

「完全なコントロール」は、誰も変更が負荷下で何をするか知らないと罠になります。接続数を上げすぎたり安全設定を外したりして、ランダムなタイムアウトやクラッシュを招きやすいです。マネージドはガードレールを提供します：自由度を一部手放しますが、壊す方法が減ります。

チューニングを管理しやすくするために、定期メンテナンスとして扱ってください。最低限、CPU とメモリの圧力、ディスク I/O とストレージ増加、接続数と待ち/ロック、スロークエリの頻度、エラー率（タイムアウトやデッドロック）が見えるべきです。

例：小さなチームが新しいカスタマーポータルを公開してページが遅くなったとします。基本的なスロークエリ追跡があれば、ある API コールがテーブルスキャンをしていることに気付き、1 つのインデックス追加で数分で解決できます。可視性がなければ、サーバーを拡張しても解決しないかもしれません。観測性の方が全てのノブを持つことより重要なことが多いです。

小規模チームのためのセキュリティとコンプライアンス基礎

小規模チームでは、セキュリティは派手なツールよりも基本を毎回やることが重要です。マネージドでもセルフホストでも、ほとんどの事故は単純なミスから起きます：インターネットから到達可能なデータベース、権限が大きすぎるユーザー、回転されない漏洩したパスワードなどです。

まずはハードニングから。可能ならデータベースはプライベートネットワークの背後に置くか、厳格な許可リストを設定してください。TLS を使って資格情報とデータが平文で送られないようにします。データベースのパスワードは本番シークレットとして扱い、ローテーションを計画してください。

アクセス制御では最小権限の原則が効きます。人やサービスには必要な権限だけ与え、理由を記録してください。サポートの外部担当者が注文を閲覧する必要があるならスキーマ変更権限は不要です。

よく使えるシンプルなアクセス構成：

• アプリ用ユーザーはアプリが必要とする権限だけ（スーパーユーザでない）
• マイグレーションやメンテ用の管理アカウントを分ける
• 分析やサポート用に読み取り専用アカウントを設ける
• 共有アカウントを避け、コード内に長期間有効な資格情報を置かない
• 接続や権限エラーのログを有効にする

マネージドプロバイダは安全なデフォルトを出すことが多いですが、デフォルトが何かを確認する必要があります。公開アクセスがオフになっているか、TLS が強制されるか、保存時の暗号化がどう扱われるか、監査ログや保持期間はどうかをチェックしてください。コンプライアンスでは誰が、いつ、どこからアクセスしたかの証跡が重要になります。

セルフホストは完全な制御を与えますが、足を撃ちやすくもなります。よくある失敗は 5432 ポートを世界にさらすこと、退職者の資格情報を残すこと、パッチ適用を担当者不在で先延ばしすることです。

もし AppMaster のようなプラットフォームで内部ツールを作っているなら、ルールは簡単にしてください：まずネットワークアクセスをロックダウン、次にロールを厳しくし、最後にシークレットのローテーションを自動化する。これだけで回避できるセキュリティ事故は大半です。

信頼性、フェイルオーバー、サポートの期待

信頼性は「99.9% の稼働率」だけではありません。メンテナンス中に何が起きるか、悪いデプロイからどれだけ速く回復できるか、データベースがタイムアウトし始めたときに誰が起きているかも含みます。専任 DBA がいないチームにとっては、日常の現実が見出しの数字より重要です。

マネージドとセルフホストの差は、複製、フェイルオーバーの判断、インシデント対応の「誰が持つか」に最も表れます。

マネージドは通常、ゾーン間の複製や自動フェイルオーバーを含み、単一サーバのクラッシュで落ちる可能性を下げます。しかし限界を知ることは重要です。フェイルオーバーは短時間の切断、わずかに古いデータを持つ新プライマリ、アプリ側での再接続処理が必要になる場合があります。メンテナンスウィンドウも重要で、パッチによる再起動は起き得ます。

セルフホストでは高可用性は自分で設計し、テストし、維持するものです。強い信頼性は達成できますが時間と注意を払う代償があります。誰かが複製のセットアップ、フェイルオーバー挙動の定義、システムのドリフトを防ぐ作業を続ける必要があります。

日常的な作業には通常、モニタとアラート（ディスク、メモリ、スロークエリ、レプリケーション遅延）、定期的なフェイルオーバードリル（動くことを証明する）、レプリカの健全性維持と故障ノードの置換、ランブックの文書化（インシデントが一人に依存しないように）、オンコールのカバレッジ（非公式でも）などが含まれます。

ディザスタリカバリはフェイルオーバーと別物です。フェイルオーバーはノードやゾーンの問題を扱い、ディザスタリカバリは悪いマイグレーション、データ消失、リージョン全体の障害など大規模な事象を扱います。小規模チームではマルチゾーンで十分なことが多いです。収益に直結するプロダクトならクロスリージョンを検討できますが、コストと複雑さが増し、レイテンシが上がる可能性があります。

サポートの期待も変わります。マネージドならインフラ層の責任はプロバイダにあり、チケットベースの支援が受けられることが多いです。セルフホストではサポートは自チーム：ログ、パケットドロップ、ディスク問題、カーネルアップデート、深夜のデバッグまで自分たちで対処します。プロダクトチームがそのままオペレーションチームを兼任するなら、負荷を正直に評価してください。

例：小さな SaaS が週次のマーケティングローンチを行うとき、ローンチ中の 10 分の DB 障害は実際のビジネス損失になります。マルチゾーンのフェイルオーバーと接続を再試行するアプリを組み合わせたマネージドが、目標を達成する最も簡単な方法かもしれません。同じ問いは内部ツール（AppMaster を使った場合でも PostgreSQL に依存する）でも当てはまります：許容できるダウンタイムはどれくらいか、障害時に誰が直すのか？

総所有コスト（TCO）：請求書以外に何を数えるか

マネージドとセルフホストを比較するとき、多くの人は月額料金だけを比べます。より良い問いは「データベースを安全に、高速に、かつ利用可能に保ちながら製品を出し続けるのにチームにどれだけ費用がかかるか」です。

まず明白な項目から。どちらでもコンピュートとストレージに支払い、加えて I/O、バックアップ、場合によってはスナップショット復元やリージョン間移行のためのネットワーク転送（egress）があります。マネージドプランは追加ストレージ、リードレプリカ、より高い IOPS テiers、長いバックアップ保持などを加えると安く見えなくなることがあります。

次に請求書に現れないコストを足します。専任 DBA がいないなら最大のコストは人件費であることが多いです：オンコール、障害時のコンテキストスイッチ、スロークエリのデバッグに割く時間、ダウンタイムによるビジネスコスト。セルフホストは高可用性設定、監視・アラート、ログ保存、フェイルオーバー用の余剰キャパシティなどを自前で持つため、このオーバーヘッドを増やしがちです。

よくある「驚きのコスト」：

• マネージド：バースト I/O 請求、ゾーン間レプリカの費用、増え続けるストレージ、プレミアムサポート料金
• セルフホスト：HA ツールとテストのコスト、監視スタックの維持、パッチ適用の工数、フェイルオーバー用に待機する追加ノード

月次 TCO をざっくり見積もる簡単な方法は時間を明示することです：

• インフラ：コンピュート + ストレージ + バックアップ + 予想される egress
• リスクバッファ：スパイク（トラフィック、ストレージ増加、復元）に対して 10～30% 上乗せ
• 人件費：月当たりの時間（オンコール、パッチ、チューニング）× ライフコスト換算の時間単価
• 障害コスト：期待されるダウン時間（時間）× ビジネスに対する時間当たりコスト

例：3 人のプロダクトチームが小さなマネージド DB に月 $250 を使っているとします。もし毎月 6 時間をスロークエリやメンテに取られているなら（6 × $80 = $480）、実際の月次コストは障害前で $730 に近くなります。セルフホストで同じ時間が倍になれば、見かけ上「安い」選択が実は高くつくことになります。

AppMaster のようなプラットフォームでアプリを作るなら、どれだけの DB 作業が本当にカスタムかを考慮してください。配管作業にチームが割く時間が少ないほど、間接コストが目立ち、予測可能な運用の価値が高くなります。

DBA がいなくても 5 ステップで決める方法

小規模チームがマネージドとセルフホストを決める際、本質は「夜中の 2 時の問題を誰が対処するか」です。

1) 非交渉条件を書き出す

許容できる停止時間、データ成長、コンプライアンス要件、月次予算上限（ホスティングだけでなく人件費も含む）など、守れない条件を明確にします。

2) 復旧目標を一文で定義する

データ損失と停止時間の両方をカバーする一つの目標を書きます。例：「最大 15 分のデータ損失を許容し、1 時間以内にオンラインに戻す」。

3) アップグレードの実運用方法を決める

アップグレードは先延ばしにされがちです。オーナー（人名）を決め、マイナーはどれくらいの頻度で当てるか、メジャーはいつテストするか、どこでリハーサルするか、ロールバック方法はどうするかを書きましょう。自信が持てないならマネージドがリスクを下げます。

4) 本当にどれだけの制御が必要か正直になる

チームはよく「完全な制御が欲しい」と言いますが、多くは「いくつかの機能が欲しい」だけです。特定の拡張、特殊な設定、OS レベルのアクセス、本当に必要かを精査してください。「いつか必要になるかも」は優先度低に扱いましょう。

5) 運用モデルを選びオーナーを割り当てる

プロバイダ任せ（managed）、自分たちで全部（self-hosted）、あるいはハイブリッド（マネージド DB、セルフホストアプリ）のいずれかを選びます。小規模チームではハイブリッドが一般的で、重要な部分は制御しつつ DB の手間を減らせます。

短いシナリオ：4 人チームが内部管理ツールを最初はセルフホストで運用し、忙しい週にディスクが満杯になって後悔することがあります。AppMaster でアプリを生成してクラウドにデプロイしているなら、マネージド PostgreSQL を組み合わせることで機能に集中しやすくなり、要件が変われば後で移行もできます。

適切な決定とは、オンコール負荷がチーム規模と一致し、復旧目標が現実的に書き出され、担当者がいることです。

後で痛くなるよくあるミス

多くのチームはマネージドとセルフホストの選択で燃え尽きるのではなく、地味な部分を勝手に処理してくれると思い込むことで痛い目に遭います。

典型例：カスタマーポータルを出して自動バックアップを有効にして安心する。数か月後、深夜の修正でテーブルを削除してしまう。バックアップは存在するが復元手順を誰も知らず、復元にどれだけかかるか、どのデータが欠けるかが未確認だった。

最悪のタイミングで露呈するミス：

• バックアップを「オンにしている」だけにして検証していない。 定期的に復元ドリルを実行し、所要時間を計り、主要レコードを検証してください。PITR を使うならそれもテストする。
• 本番で直接アップグレードする。 マイナーでさえ拡張や設定変更、スロークエリを引き起こすことがあります。プロダクションに近いステージングでリハーサルし、ロールバック手順を文書化する。
• 順序を間違えた早すぎるチューニング。 大きな効果はまずスロークエリ修正、適切なインデックス、チャッティなクエリ削減で得られます。深い設定をいじるのは後回し。
• 接続管理を無視する。 モダンなアプリは多くの短い接続を作ります。プーリングなしでは接続上限に達し、負荷時にランダムなタイムアウトが起きます。
• 所有権が不明確。 「みんなが DB を見ている」ことは多くの場合「誰も対応しない」ことを意味します。承認プロセスもなく、ランブックが更新されない。

事故を防ぐ習慣として一つ挙げるなら、次の三つを文書化しておくことです：誰が DB のオンコールか、別インスタンスへの復元手順、DB アップグレード計画（誰が承認するかを含む）。

AppMaster のようなプラットフォームで作っていても、これらのミスは変わりません。アプリが本番対応であっても、検証済みの復元、落ち着いたアップグレード手順、接続管理と明確な責任が必要です。

クイックチェック、現実的な例、次のステップ

決定は 15 分で答えられるいくつかのチェックでグラウンドするのが良いです。データベースの専門家がいなくてもリスクがすぐ分かります。

今日できるクイックチェック

バックアップとアクセス制御から始め、チーム全員が見られる場所に答えを書いておきます。

• 最後に復元テストをしたのはいつで、別環境へ正常に復元できたか？
• 保持期間は何日か（例：7、30、90 日）、それはニーズに合っているか？
• 誰がバックアップを削除したり保持を変更できるか、そのアクセスは制限されているか？
• バックアップはどこに保管されており、暗号化されているか？
• 目標の RPO／RTO は何か？（どれだけのデータを失え、どれだけ早く戻る必要があるか）

次にアップグレードと監視を見ます。小規模チームは「あとでやる」が最もダメージを招きます。

• アップグレード頻度（毎月のパッチ、四半期ごとのレビュー等）は？誰が担当か？
• ビジネスが受け入れるメンテナンスウィンドウはあるか？
• 現在の Postgres バージョンとサポート終了日をはっきり見られるか？
• ディスク増加、CPU スパイク、失敗バックアップのアラートはあるか？
• スロークエリを把握できるか（簡単な「上位 5 件」のビューでも良い）？

もう一つの習慣チェック：ストレージが月 10% 増えるなら、いつ上限に達するか知っていますか？手遅れになる前にカレンダーにリマインダを入れてください。

現実的な 5 人チームの例

5 人チームがサポート向けの内部ツールを作り、数ヶ月でテーブルや添付、監査ログ、日次インポートでデータベースが 5 倍に成長したとします。ある月曜、スキーマ変更で主要画面が遅くなり、ロールバックできるかと問われます。バックアップは存在するが復元を一度も試したことがなく、所要時間が不明でした。

次のステップ

RPO／RTO とチームが毎週運用できる能力を満たす最もシンプルな選択を選んでください。「いつか」はなく、後で動かせるようにスタックを柔軟にしておくとよいです。

AppMaster で構築しているなら、アプリの配信とデータベース運用を分けると便利です：PostgreSQL にデータをモデリングして、本番対応のバックエンドやウェブ・モバイルアプリを生成し、AppMaster Cloud や主要クラウドにデプロイできます。これにより「Postgres をどこで動かすか」は再構築ではなく運用上の判断になります。最後に、AppMaster とその提供情報は appmaster.io として表示されています。