Héberger plusieurs instances de base de données sur un seul serveur
La promesse de l'auto-hébergement des bases de données
Les bases de données gérées dans le cloud sont pratiques — jusqu'à ce que la facture arrive. Pour les équipes qui gèrent plusieurs projets, chacun nécessitant sa propre instance Postgres, l'arithmétique des coûts change radicalement dès que l'on dépasse trois ou quatre bases de données.
Mais en réalité, entasser plusieurs instances de bases de données sur une seule machine n'est pas simplement une question de faire tourner plus de conteneurs. La contention mémoire, les conflits d'I/O disque et l'orchestration des sauvegardes deviennent des préoccupations importantes que les services gérés traitent discrètement pour vous.
Notre configuration : plusieurs stacks Supabase sur un seul serveur
Nous faisons tourner plusieurs stacks Supabase complets — chacun comprenant Postgres, GoTrue, PostgREST, Realtime et Storage — sur un seul serveur dédié. Le serveur est une machine à 16 vCPU et 32 Go de RAM dans un data center européen, orchestrée entièrement via Docker Compose.
Chaque stack dispose de son propre fichier compose, de son propre espace réseau et de son propre volume de données. La décision architecturale clé : pas de cluster Postgres partagé. Chaque projet dispose d'une instance de base de données entièrement isolée. La surcharge liée à l'exécution de plusieurs processus Postgres est réelle — environ 200 à 400 Mo par instance inactive — mais la simplicité opérationnelle d'un isolement complet l'emporte sur le coût en ressources.
Les limites de ressources qui comptent vraiment
services:
db:
image: supabase/postgres:15.6
deploy:
resources:
limits:
memory: 2G
cpus: '2.0'
reservations:
memory: 512M
cpus: '0.5'Les limites de ressources Docker constituent la première ligne de défense. Sans elles, une seule requête incontrôlée peut affamer toutes les autres bases de données de la machine. La réservation garantit que chaque instance dispose toujours d'une allocation minimale, même en cas de contention.
Orchestration des sauvegardes sur plusieurs instances
Le problème avec plusieurs bases de données n'est pas de les sauvegarder — pg_dump s'en charge de manière fiable. Le problème est d'orchestrer les sauvegardes de façon à ce qu'elles ne s'exécutent pas toutes simultanément et ne saturent pas l'I/O disque.
Nous décalons les sauvegardes à l'aide d'un planning cron simple avec des décalages horaires. L'instance A sauvegarde à 02h00, l'instance B à 02h15, l'instance C à 02h30. Chaque sauvegarde passe par gzip et est téléversée vers un stockage objet. Durée totale de la fenêtre de sauvegarde pour toutes les instances : moins de 45 minutes.
Supervision sans pile de monitoring
Un piège courant : déployer Prometheus, Grafana et AlertManager pour surveiller un serveur — en consommant ainsi les ressources que l'on cherche à protéger. À notre échelle, une approche légère fonctionne mieux.
Un script shell s'exécute toutes les cinq minutes via cron, vérifie chaque instance Postgres avec pg_isready, mesure l'utilisation du disque par volume et envoie un résumé à un endpoint de notification si un seuil est dépassé. Coût total en ressources : négligeable.
Quand arrêter l'auto-hébergement
Héberger plusieurs bases de données soi-même a du sens lorsque l'équipe maîtrise les opérations Postgres, que les charges de travail sont prévisibles et que les économies réalisées justifient la surcharge opérationnelle. Dès que l'une de ces conditions change — exigences de mise à l'échelle rapide, obligations de conformité pour les services gérés ou renouvellement de l'équipe — le calcul penche à nouveau vers les offres gérées.
Les meilleures décisions en matière d'infrastructure sont réversibles. Les volumes Docker peuvent être exportés, les fichiers pg_dump peuvent être restaurés n'importe où, et la couche applicative ne devrait pas se soucier de l'emplacement de sa base de données. Cette portabilité est la vraie valeur de l'approche conteneurisée — pas les économies de coûts.