単一サーバーで複数のデータベースインスタンスをセルフホスティングする

データベースのセルフホスティングという選択

クラウドマネージドデータベースは便利です — 請求書が届くまでは。複数プロジェクトを運営するチームにとって、それぞれ独自の Postgres インスタンスが必要な場合、データベースが 3〜4 つを超えた時点でコスト計算が大きく変わります。

しかし現実には、複数のデータベースインスタンスを 1 台のマシンに詰め込むことは、単にコンテナを増やせばよいという話ではありません。メモリの競合、ディスク I/O の衝突、バックアップのオーケストレーションはすべて、マネージドサービスが静かに処理してくれていた重要な課題となります。

構成：1 台のサーバーで複数の Supabase スタックを運用

私たちは、Postgres、GoTrue、PostgREST、Realtime、Storage から成る完全な Supabase スタックを複数、1 台の専用サーバーで稼働させています。このサーバーは欧州のデータセンターにある 16 vCPU・32 GB のマシンで、すべて Docker Compose で管理されています。

各スタックはそれぞれ独自の compose ファイル、独自のネットワーク名前空間、独自のデータボリュームを持ちます。重要なアーキテクチャ上の決定は：Postgres クラスターを共有しないこと。各プロジェクトは完全に分離されたデータベースインスタンスを持ちます。複数の Postgres プロセスを実行するオーバーヘッドは現実に存在し — アイドル状態のインスタンスあたり約 200〜400 MB — ですが、完全分離によるオペレーションの簡素さがリソースコストを上回ります。

実際に意味のあるリソース制限

services:
  db:
    image: supabase/postgres:15.6
    deploy:
      resources:
        limits:
          memory: 2G
          cpus: '2.0'
        reservations:
          memory: 512M
          cpus: '0.5'

Docker のリソース制限は最初の防衛線です。これがなければ、暴走したクエリ 1 つがマシン上の他のすべてのデータベースを枯渇させる可能性があります。リザーベーションにより、競合状態でも各インスタンスが常に最小限のリソースを確保できます。

インスタンス間のバックアップオーケストレーション

複数データベースの問題はバックアップそのものではありません — pg_dump は信頼性高く対応します。問題は、すべてが同時実行されてディスク I/O が飽和しないようにバックアップをオーケストレーションすることです。

シンプルなオフセット付き cron スケジュールを使ってバックアップを分散させています。インスタンス A は 02:00 にバックアップ、インスタンス B は 02:15、インスタンス C は 02:30。各バックアップは gzip を通じてオブジェクトストレージにアップロードされます。全インスタンスのバックアップ所要時間は 45 分以内です。

モニタリングスタックなしの監視

よくある落とし穴：サーバーを監視するために Prometheus、Grafana、AlertManager をデプロイしてしまい、守ろうとしているリソースを消費してしまうことです。私たちのスケールでは、軽量なアプローチの方が効果的です。

シェルスクリプトが cron で 5 分ごとに実行され、pg_isready で各 Postgres インスタンスを確認し、ボリュームごとのディスク使用量を測定し、いずれかの閾値を超えた場合は通知エンドポイントにサマリーを送信します。総リソースコストはごくわずかです。

セルフホスティングをやめるべき時

複数データベースのセルフホスティングは、チームが Postgres の運用を理解しており、ワークロードが予測可能で、コスト削減が運用オーバーヘッドを正当化できる場合に有効です。これらの条件のいずれかが変わった瞬間 — 急速なスケーリング要件、マネージドサービスへのコンプライアンス要求、またはチームの入れ替わり — コスト計算はマネージドオファリングに戻ります。

最良のインフラ上の決定は可逆的です。Docker ボリュームはエクスポートでき、pg_dump ファイルはどこでもリストアでき、アプリケーション層はデータベースがどこにあるかを気にすべきではありません。そのポータビリティこそがコンテナ化アプローチの真の価値であり — コスト削減ではありません。