- Postgresのセルフホスティングは複雑でも危険でもなく、マネージドサービスより安価で、性能調整の自由度が高い方法である
- ほとんどのクラウドデータベースサービスは、オープンソースのPostgresを少し改変した形で運用されており、実質的な違いは運用自動化の水準にある
- 実運用の事例では、セルフホストしたPostgresが数千人のユーザーと数千万件のクエリを安定して処理しており、保守時間もごくわずかで済む
- AWS RDSなどのマネージドサービスの価格上昇により、同じ費用で、はるかに高性能なサーバーを自前で運用できるようになっている
- インフラ管理がそれほど複雑ではない中規模チームにとって、セルフホスティングはコスト効率と性能の両面で現実的な代替案になる
クラウド中心の物語の変化
- 以前は、ほとんどの企業が自社サーバー上でデータベースを直接運用しており、これはネットワーク遅延が少なく高速な構成だった
- 1980〜2000年代には、アプリケーションサーバーとデータベースサーバーが同じ物理マシン上に置かれることも多かった
- Amazon RDS(2009) の登場は、バックアップ、パッチ適用、監視を自動化してくれる魅力的な提案として受け止められた
- 当初は専用サーバーと同程度の価格で、運用負担を減らせた
- 2015年以降、クラウド導入が加速するにつれ、インフラを自分で管理する行為は非効率だという認識が広がった
- AWSがインフラを代わりに管理し、開発者はアプリケーションロジックに集中するという構図が標準として定着した
- 2025年現在、RDSの価格は大きく上昇しており、同じ費用で、はるかに高性能な専用サーバーを借りられる状況になっている
- 例: db.r6g.xlargeインスタンス(4 vCPU, 32GB RAM)は月額$328で、32コア・256GB RAMのサーバーを借りられる
マネージドサービスの実際の構成
- AWS RDSは基本的に、標準的なPostgresにAWS独自の監視・バックアップシステムを追加した構成である
- EBSスナップショットベースのバックアップ、Chef/Puppet/Ansibleによる構成管理、PgBouncerのコネクションプーリング、CloudWatch監視、自動フェイルオーバースクリプトを含む
- こうした構成は技術的に特別複雑ではなく、運用自動化と初期デプロイのしやすさが主な価値である
- 同一スペックのサーバーでRDSからセルフホスティングへ移行した結果、性能は同等か、むしろ改善した
- RDSでは制限されていたパラメータを直接調整できるようになり、性能最適化が可能になった
セルフホスティングの運用複雑性
- DigitalOceanの16 vCPU / 32GB RAM / 400GBディスクのサーバーへの移行には約4時間を要し、その後も安定運用が確認された
- 高可用性プロダクト群では月30分ほどの管理時間が必要だが、トラフィックの少ないサービスなら完全自動化も可能
- 定期的な管理サイクル
- 週次(10分) : バックアップ検証、遅いクエリログの確認、ディスク容量のチェック
- 月次(30分) : セキュリティアップデート、バックアップ保持ポリシーの点検、容量計画
- 四半期ごと(2時間) : 監視ダッシュボードの更新、設定最適化、復旧テスト
- 障害対応は自分で責任を負う必要があるが、RDSでも障害は発生し、結局は開発者が対応しなければならない
- 自前運用では、アップデートのタイミングやリスクの高い時間帯を自分で調整できるため、安定性を確保しやすい
セルフホスティングが不向きなケース
- 初期段階の開発者が素早くプロトタイプを作る場合は、マネージドサービスのほうが手軽である
- 大企業では、専任のデータベースエンジニアを置くか、人件費削減のためにクラウドへ委託するほうが効率的な場合がある
- 規制産業(PCI-DSS, HIPAAなど) では、認証済みのマネージドプラットフォームの利用が求められることがある
主な設定ポイント
- メモリ設定: ハードウェアに合わせて
shared_buffers, effective_cache_size, work_mem, maintenance_work_mem などを調整する必要がある
- 例:
shared_buffers はRAMの25%、effective_cache_size は75%に設定
- 接続管理:
pgbouncer を使ってコネクションプーリングを構成し、Python asyncio環境で効率よく動作させる
max_connections = 200, log_connections = on など基本設定の例を提示
- ストレージチューニング: NVMe SSD環境では
random_page_cost = 1.1, effective_io_concurrency = 200 などに調整
- ランダムリード速度が向上し、クエリプランの最適化につながる
- WAL設定: 耐久性と性能のために
wal_level = replica, max_wal_size = 2GB, checkpoint_completion_target = 0.9 などを調整
結論
- すべてのインフラを自前で運用する必要はないが、Postgresはセルフホスティングが合理的な領域に属する
- 月$200以上をRDSに支払っているなら、非中核のデータベースをテスト用サーバーへ移してみる価値がある
- 今後のインフラは、マネージドサービスとセルフホスティングを組み合わせたハイブリッド型へ進んでいく可能性がある
- Postgresは費用対効果の高いセルフホスティング候補として評価できる
4件のコメント
ストレージも11ナインを保証してくれるなら、クラウドを使うのと同じようなものですし、運用が難しいからクラウドを使うんですよね（笑）
実際には、3ノードクラスターの運用はそれほど簡単ではないでしょう。
Hacker Newsのコメント
私は self-hosting を責任の問題として見ている
いくつかのSaaS製品を自前でホスティングしているが、AWSよりはるかに安く、しかも性能もずっと良い
ただしクライアント案件ではAWSの費用を払うよう説得している。ハードウェア可用性の責任を他所に移せるからだ
予算が限られている場合、RDSの費用は負担が重い。Hetznerの3ノード Galeraクラスタ を数ドルで運用するほうがずっと経済的だ
とはいえCloudflareやSQSのような マネージドサービス でも時々障害は起きる。結局、完全な安定性などどこにもない
AWS Aurora Serverless
クラウドSQLはむしろ コスト構造が複雑 で、バックアップ設定も一度しておけば終わりだ
私はself-hostingが大半の人に向く選択だという主張には同意しない
むしろ 予算が厳しい か、あるいは 専任エンジニアを置けるほどの規模 のときにだけ、自前ホスティングが合理的だと思う
小規模企業はクラウドに任せるほうが現実的だ。セットアップ後は月30〜120分の管理で十分という計算になる
HerokuやRenderのようなPaaSなら一般的な開発者でも扱えるが、はるかに高い
結局、アプリケーション復旧の自動化ができていなければ、午前3時に起こされるのは同じだ
内部ツールならDockerにPostgresを1つ追加するのに5分もあれば十分だ
「マネージドデータベース」の定義があいまいだ
私にとっての基本要件は 自動バックアップ、インデックス最適化、マルチデータセンター障害切り替え、ポイントインタイムリカバリ、スロークエリ解析、ストレージ予測 だ
こうしたものを月額料金で提供してくれるなら、self-hosting論争は意味を失う
結局は2人置くことになり、仕事が退屈なので不要な改善に手を出して6か月を無駄にすることすらある
マネージドDBは VPSに比べて高すぎる
利便性に対するプレミアムはある程度想定していたが、実際には何倍も高い。だから大規模プロジェクト以外では使わない
記事で触れられていた 高可用性(HA) の部分が不十分だ。WAL設定だけでは説明にならない。レプリケーションにはコストがかかる
なぜPostgresがHNで過大評価されているのか分からない
MongoDBのように 自動フェイルオーバーするHAクラスタ を簡単に構成する方法がない。実運用ではどう解決しているのか気になる
関連議論: PostgreSQLメーリングリスト
実際にはすべての接続が切れ、キャッシュが初期化され、アップグレード時にはサービス停止が必須だ
Oracle RAC だけが例外で、PostgreSQLはそういう構造ではない。YugabyteDB が一応の代替になる
ほとんどのアプリは数時間のダウンタイムを受け入れる。複雑な自動化を担えるのは大企業だけだ
Kubernetes環境なら CloudNativePG も良い。
pg_auto_failover はシンプルだが制約がある
Autobase を見ると、self-hosting時に必要な作業を自動で処理してくれる
15年間Postgresを 常にself-hosted で使ってきたが、問題に遭遇したことはほとんどない
唯一の悩みは、ORMのアップグレードに合わせて PGバージョンのマイグレーション をしなければならないときだった。慎重な システム管理 で解決できた
Fly.ioで 非管理のPostgres を自分で動かしていたが、本当に大変だった
ノードが頻繁に落ちて、そのたびに手動で repmgr を使って復旧しなければならず、結局は社内Wikiに手順をまとめた
クラスタの目的は高可用性のはずなのに、なぜ ゾンビプライマリ を自動で処理しないのか理解できなかった
結局 マネージドPostgres に移行し、障害時に他の誰かが対処してくれるのは本当に楽だ
このスレッドの多くのコメントは、規模、ワークロード、人員、時間、ビジネス段階、スケーラビリティ要件 といった現実的な要素を無視している
self-hostingが合う場合も合わない場合もあるのに、議論が単純化されすぎている
開発者たちの悩みとしては、ああいうものをセルフホスティングするときに、そうした要素がきちんと評価されるのかも重要そうです。クラウド費用のほうが多くかかっても、セルフホスティングによるコスト削減が認められないなら、結局はクラウドサービスを使ってカバーし、担当領域を減らすほうが気楽です。