Self-Hosting di Istanze Database Multiple su un Singolo Server

La promessa del self-hosting dei database

I database gestiti nel cloud sono comodi — finché non arriva la fattura. Per i team che gestiscono più progetti, ciascuno con la propria istanza Postgres, il calcolo dei costi cambia drasticamente non appena si superano tre o quattro database.

In realtà, però, comprimere più istanze di database su una sola macchina non è semplicemente una questione di avviare più container. La contesa sulla memoria, i conflitti sull'I/O del disco e l'orchestrazione dei backup diventano preoccupazioni concrete che i servizi gestiti risolvono silenziosamente per te.

La nostra configurazione: più stack Supabase su un server

Gestiamo diversi stack Supabase completi — ciascuno composto da Postgres, GoTrue, PostgREST, Realtime e Storage — su un unico server dedicato. Il server è una macchina a 16 vCPU e 32 GB in un data center europeo, orchestrata interamente tramite Docker Compose.

Ogni stack ha il proprio file compose, il proprio namespace di rete e il proprio volume dati. La decisione architetturale chiave: nessun cluster Postgres condiviso. Ogni progetto ottiene un'istanza di database completamente isolata. Il costo di eseguire più processi Postgres è reale — circa 200-400 MB per istanza inattiva — ma la semplicità operativa dell'isolamento completo supera il costo delle risorse.

I limiti di risorse che contano davvero

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

I limiti di risorse di Docker sono la prima linea di difesa. Senza di essi, una singola query fuori controllo può affamare ogni altro database sulla macchina. La prenotazione garantisce che ogni istanza abbia sempre un'allocazione minima, anche in condizioni di contesa.

Orchestrazione dei backup tra istanze

Il problema con più database non è fare il backup — pg_dump lo gestisce in modo affidabile. Il problema è orchestrare i backup in modo che non vengano eseguiti tutti simultaneamente, saturando l'I/O del disco.

Scaglionamo i backup utilizzando una semplice pianificazione cron con offset. L'istanza A fa il backup alle 02:00, l'istanza B alle 02:15, l'istanza C alle 02:30. Ogni backup viene compresso con gzip e caricato su object storage. Finestra totale di backup per tutte le istanze: meno di 45 minuti.

Monitoraggio senza uno stack di monitoraggio

Una trappola comune: distribuire Prometheus, Grafana e AlertManager per monitorare un server — consumando così le risorse che stai cercando di proteggere. Alla nostra scala, un approccio leggero funziona meglio.

Uno script shell viene eseguito ogni cinque minuti tramite cron, controlla ogni istanza Postgres con pg_isready, misura l'utilizzo del disco per volume e invia un riepilogo a un endpoint di notifica se viene superata una soglia. Costo totale delle risorse: trascurabile.

Quando smettere di fare self-hosting

Il self-hosting di più database ha senso quando il team comprende le operazioni Postgres, i carichi di lavoro sono prevedibili e i risparmi sui costi giustificano il sovraccarico operativo. Nel momento in cui una di queste condizioni cambia — requisiti di scalabilità rapida, mandati di conformità per servizi gestiti o turnover del team — il calcolo si sposta di nuovo verso le offerte gestite.

Le migliori decisioni infrastrutturali sono reversibili. I volumi Docker possono essere esportati, i file pg_dump possono essere ripristinati ovunque e il livello applicativo non dovrebbe preoccuparsi di dove vive il suo database. Questa portabilità è il vero valore dell'approccio containerizzato — non i risparmi sui costi.