Base de données externe

Par défaut, la pile Compose exécute son propre conteneur Postgres. Vous pouvez, à la place, exécuter la même pile sur un Postgres managé. Le conteneur postgres ne démarre alors jamais. L'authentification, l'API de données, le stockage et le runner de migration se connectent à votre base de données.

Tested à chaque version : un Postgres 16 standard avec pgvector, dans le replay d'intégration continue de l'ensemble de la chaîne de migration.

Expected to work, extrait de la documentation du fournisseur :

• Azure Database for PostgreSQL Flexible Server
• Amazon RDS for PostgreSQL et Amazon Aurora PostgreSQL
• Google Cloud SQL pour PostgreSQL et AlloyDB
• Neon

Tout autre Postgres répondant aux exigences ci-dessous fonctionne également. Signalez votre résultat sur le suivi des tickets afin que la liste puisse faire passer un fournisseur à l'état tested.

Prérequis

Connecter la pile

Transmettez la chaîne de connexion administrateur au script de bootstrap :

./deploy/bootstrap.sh --database-url postgresql://admin:password@host:5432/dbname

Le script écrit les paramètres EXTERNAL_DB_* et la superposition docker-compose.external-db.yml dans deploy/.env. Il crée un seul mot de passe pour les trois identifiants de connexion aux services. Il vérifie ensuite la base de données avant de démarrer un conteneur : la version de Postgres, les deux extensions, les privilèges admin, la limite de connexions et TLS. Chaque vérification échouée affiche une ligne qui vous indique ce qu'il faut modifier.

Le script refuse un nom d'hôte de pooler, un projet Supabase hébergé, sslmode=disable, ainsi qu'un mot de passe contenant des caractères qu'une chaîne de connexion ne peut pas prendre en charge. Encodez ces caractères en pourcentage ou définissez un mot de passe administrateur plus simple.

Au démarrage, un service provision exécuté une seule fois prépare la base de données en tant qu'administrateur. Il crée les rôles, les schémas auth, storage et extensions, les fonctions d'aide à l'authentification, les privilèges par défaut et les deux extensions. Le service s'exécute à nouveau à chaque démarrage et ne modifie rien lorsque la base de données est prête.

L'option --database-url se combine avec --images, --workers et --tls. Exécutez à nouveau le script avec une nouvelle chaîne de connexion pour faire pointer la pile vers une autre base de données. Le mot de passe du service est conservé.

Vérifier le certificat

Les fournisseurs disposant d'une autorité de certification privée ont besoin du bundle pour une vérification complète :

./deploy/bootstrap.sh --database-url postgresql://admin:password@host:5432/dbname --db-ca ./bundle.pem

Le script copie le bundle dans deploy/external-db/db-ca.pem et définit sslmode=verify-full. Chaque service vérifie ensuite le serveur par rapport à ce bundle.

Remarques du fournisseur

Neon

Créez le projet dans une région de l'UE sur Postgres 16 ou une version ultérieure. Copiez la chaîne de connexion direct, et non celle -pooler. L'offre Free suspend les ressources de calcul après cinq minutes d'inactivité. La première requête après une pause prend quelques secondes, le temps que les services se reconnectent.

Azure Database for PostgreSQL Flexible Server

Créez le serveur sur Postgres 16 ou une version ultérieure. Ajoutez vector,pg_trgm au paramètre de serveur azure.extensions avant d'exécuter le script de bootstrap. Utilisez l'identifiant administrateur que vous avez défini lors de la création. Ajoutez l'adresse IP de votre hôte aux règles du pare-feu.

Amazon RDS et Aurora

Utilisez l'utilisateur master. Téléchargez le paquet de certificats et transmettez-le avec --db-ca. Autorisez votre hôte dans le groupe de sécurité. Les versions d'Aurora antérieures à la version 17 n'imposent pas l'utilisation de TLS. La pile utilise toujours TLS.

Google Cloud SQL et AlloyDB

Utilisez l'utilisateur postgres. Sélectionnez au moins le niveau db-g1-small sur Cloud SQL. Téléchargez server-ca.pem depuis l'instance et transmettez-le avec --db-ca. Ajoutez l'adresse IP publique de votre hôte aux réseaux autorisés.

Supabase hébergé

Un projet Supabase hébergé ne peut pas être la base de données utilisée par ces conteneurs. Ses rôles de service existent avec des mots de passe que vous ne détenez pas, et ses propres services sont propriétaires des schémas auth et storage. Faites plutôt pointer l'application vers ce projet et n'exécutez pas le profil db.

Sauvegardes

Le fournisseur conserve les sauvegardes de la base de données. Les fichiers importés restent dans le volume storage-data sur votre hôte. Sauvegardez le volume en même temps que la base de données. Restaurez les deux au même point dans le temps. Consultez Database pour les commandes relatives aux volumes.

Mise à niveau

Les mises à niveau fonctionnent comme décrit dans Upgrade. Le service migrate applique les migrations en attente à votre base de données. Le service provision s'exécute en premier et confirme les rôles et les schémas.