Une base PostgreSQL gérée pour votre appli. Votre agent la déclare dans while.yaml, et while la crée en France, la sauvegarde chaque jour et la remet à un instant précis quand il le faut.

Vous, à votre agent : Ajoute une base PostgreSQL pour les réservations.

Ce que votre agent écrit

Votre agent l’écrit dans while.yaml, à la racine de votre appli :

while.yaml

databases:
  - name: main
    version: "17"
    size: 1Gi
    compute: S

Ce que reçoit votre appli

Votre appli reçoit ces variables d’environnement à chaque mise en ligne :

Variable	Ce qu’elle contient
`DATABASE_URL`	L’adresse de la base, par le pooler de connexions.
`DB_MAIN_URL`	La même adresse, au nom de la base (ici main) : utile quand le projet a plusieurs bases.
`DB_MAIN_USER`	L’utilisateur de la base.
`DB_MAIN_PASSWORD`	Son mot de passe, gardé par while.

Quand vous en servir

Servez-vous-en pour les données d’un projet : ses comptes, ses commandes, ses réservations. Chaque environnement a sa base, et d’autres projets peuvent la lire (Lire la base d’un autre projet).

Comment ça marche

Chaque base déclarée est une base PostgreSQL gérée, sauvegardée en continu et restaurable à un instant précis. Votre appli s’y connecte par DATABASE_URL, à travers un pooler de connexions.

Ce qu’il faut savoir

Une base démarre en taille S (0,1 vCPU, 256 Mo, jusqu’à 1 Go) avec 1 Gio de disque (size). Avec compute, elle passe en M (0,5 vCPU, 1 Go), L (1 vCPU, 4 Go) ou XL (2 vCPU, 8 Go), avec PostgreSQL et PgBouncer réglés pour chaque taille. Un changement de taille redémarre la base en une quinzaine de secondes, et plan_deploy dit ce qu’il coûte par mois avant de l’appliquer. Le champ version choisit PostgreSQL 16, 17 ou 18, 17 par défaut. Le mot de passe de la base est gardé par while, et arrive à l’appli dans ses variables.

Une base a une instance par défaut, sur le disque d’un nœud : une panne de ce nœud se répare par une restauration. Avec instances: 2, une seconde instance, sur son propre disque, est tenue à jour en continu et prend le relais d’elle-même en cas de panne. Avec l’offre Entreprise, la production a la haute disponibilité par défaut : deux instances pour une base qui n’en déclare pas, et au moins deux pour un service qui ne dort pas et n’a pas de scale.min, sauf si le while.yaml en déclare autrement. Il n’y a pas de réplique en lecture : replica: true est accepté, mais les lectures vont à l’instance principale.

Une base de production ne s’endort jamais. Une base de prévisualisation sans activité depuis 24 heures se met en veille (Mise en veille). Le journal de la base est archivé en continu, et une sauvegarde complète part chaque jour, hors du cluster ; votre agent restaure une sauvegarde ou un instant précis (Sauvegardes testées).

L’outil query_database lit la base en SQL sous le rôle PostgreSQL de votre identité, donc avec vos droits sur les données. Chaque lecture est une transaction en lecture seule de 10 secondes au plus, qui rend 200 lignes et 40 Ko par défaut (2 000 lignes au plus en format court), et chaque requête est inscrite au journal, sans ses valeurs. observe_app { view: "database" } montre les requêtes les plus fréquentes et les plus lentes (pg_stat_statements).

DATABASE_URL passe par PgBouncer en mode transaction : chaque transaction peut prendre une autre connexion au serveur, partagée avec les autres clients du pooler, qui la remet à neuf après chaque transaction. Un SET de session n’y dure donc que sa transaction : posez un réglage avec SET LOCAL, dans une transaction. Les requêtes préparées nommées marchent, car PgBouncer les suit. Ce qui tient à une session, comme LISTEN/NOTIFY, un verrou consultatif de session ou une table temporaire, ne dure pas au-delà d’une transaction.

Une appli qui a besoin de sa session, comme les migrations Liquibase (Metabase, Keycloak) ou Flyway, qui prennent un verrou consultatif de session, ou LISTEN/NOTIFY, déclare pool: session sur sa base. Le pooler garde alors une connexion au serveur par client connecté, tant qu’il reste connecté, et n’accepte pas plus de clients que la taille de la base n’a de connexions : 20 en S, 60 en M, 100 en L et 140 en XL.

Hors de l’appli, ce qui a besoin d’une vraie session, comme pg_restore, un psql d’administration ou une migration qui fait des SET, passe par une tâche (crons). Elle reçoit DB_<BASE>_DIRECT_URL, l’adresse de l’instance principale sans pooler, qui n’accepte que quelques connexions.

Prix

Ces prix sont les mêmes dans toutes les offres, hors taxes :

Ressource	Prix	Détail
Base S	5 € par base·mois	0,1 vCPU, 256 Mo
Base M	17 € par base·mois	0,5 vCPU, 1 Go
Base L	65 € par base·mois	1 vCPU, 4 Go
Base XL	150 € par base·mois	2 vCPU, 8 Go
Disque des bases	0,25 € par Gio·mois	sauvegardes comprises
Haute disponibilité des bases	+40 %	du prix de la base et de son disque

Les outils MCP de votre agent

Votre agent s’en occupe avec les outils backup_database, get_environment, observe_app et query_database.

Bases PostgreSQL