Base de données gérée ou à soi : Postgres en production

Votre CRM, votre outil d’automatisation, votre application métier : beaucoup d’outils d’entreprise rangent leurs données dans PostgreSQL, une base de données libre. Twenty, le CRM que nous opérons depuis début 2025, en fait partie : sa documentation d’hébergement sauvegarde ses données par un export de sa base Postgres.

Vient alors une décision qu’on prend souvent sans la voir : la base tourne-t-elle chez un fournisseur qui la gère, ou sur votre propre serveur ? Ce guide de notre rubrique Infrastructure et cloud décrit ce que chaque option prend en charge, ce qu’elle laisse à l’équipe, et les critères qui tranchent. Il ne recommande aucun fournisseur : les grands clouds comme les hébergeurs européens proposent tous un Postgres géré.

Ce que « géré » veut dire, concrètement

Un service de base de données géré, c’est un Postgres que le fournisseur installe, met à jour, sauvegarde et surveille pour vous. Vous recevez une adresse de connexion ; le reste est son travail. La documentation d’Amazon RDS, le service de bases gérées d’AWS, donne une idée de ce que couvrent ses sauvegardes automatiques :

• une rétention réglable de 0 à 35 jours, de 7 jours par défaut quand la base est créée depuis la console ;
• la restauration de la base à n’importe quel instant de cette période.

Les autres offres gérées, chez les grands clouds comme chez les hébergeurs européens, ont leurs propres durées et options : elles se comparent ligne à ligne. La bascule automatique vers une copie, en cas de panne de la machine, est un point à vérifier dans chaque offre, avec son prix.

Ce qu’une base à soi demande, chaque trimestre

Faire tourner Postgres sur son propre serveur, en conteneur ou non, est parfaitement sérieux. Mais le travail que le fournisseur faisait revient à l’équipe, et il est récurrent. Le projet PostgreSQL l’écrit dans sa politique de versions : chaque version majeure reçoit des correctifs, de sécurité compris, au moins une fois tous les trois mois, et il recommande de toujours tourner sur la dernière version mineure. Chaque version majeure est maintenue cinq ans, puis abandonnée :

1. 12 novembre 2026

   Fin de support de PostgreSQL 14.

2. 11 novembre 2027

   Fin de support de PostgreSQL 15.

3. 9 novembre 2028

   Fin de support de PostgreSQL 16.

4. 8 novembre 2029

   Fin de support de PostgreSQL 17.

5. 14 novembre 2030

   Fin de support de PostgreSQL 18.

Une base installée en 2021 et jamais montée de version arrive donc en fin de support dans quelques semaines. Sur un serveur à soi, personne ne planifiera cette montée de version à votre place.

Les sauvegardes, ensuite. La documentation de PostgreSQL distingue trois approches : l’export SQL, la copie des fichiers de la base, et l’archivage continu qui permet de revenir à un instant précis. L’export suffit à beaucoup d’entreprises ; l’archivage continu se justifie quand perdre une journée de saisie coûte trop cher. Notre guide sur les sauvegardes d’un serveur à soi détaille ce qui casse en pratique.

Géré ou à soi : les critères qui tranchent

Cinq questions départagent, dans cet ordre :

1. Qui fera le travail ? Si personne dans l’équipe ou chez votre prestataire n’a le temps d’appliquer les mises à jour trimestrielles et de tester une restauration, le géré s’impose.
2. Combien de données pouvez-vous perdre, et combien de temps rester arrêté ? Ce sont les deux objectifs que fixe le plan de reprise après sinistre. Plus ils sont exigeants, plus la reprise à un instant précis et la bascule automatique pèsent.
3. Combien coûte l’écart ? Comparez le prix du service géré avec la machine et le temps d’exploitation, sur trois ans. Notre article sur les cinq postes qui gonflent une facture cloud aide à lire les options.
4. Où doivent vivre les données ? Région du fournisseur, droit applicable, contrats : notre article sur la dépendance au cloud américain pose les questions.
5. Pouvez-vous partir ? Postgres reste Postgres : un export standard permet de passer d’un fournisseur à un autre, ou du géré à votre serveur. Méfiez-vous seulement des extensions propres à un fournisseur, qui rendent ce départ plus coûteux.

Par où commencer

1. 01Listez vos bases

   Quel outil, quelle version de Postgres, où elle tourne, qui en répond.

2. 02Vérifiez les dates de fin de support

   En commençant par toute base encore en version 14.

3. 03Faites un test de restauration

   De chaque base, validé sur le contenu, et notez sa durée.

4. 04Rangez un export régulier hors du fournisseur ou du serveur

   À votre nom.

5. 05Décidez base par base

   Géré quand personne ne peut tenir l’exploitation, à soi quand l’équipe ou le prestataire le peut.

La base de données fait partie du socle d’infrastructure commun à vos projets. Le reste de la rubrique couvre les décisions voisines : serveur dédié, VPS ou cloud, Kubernetes et les PME, la supervision, NIS2 en France, n8n auto-hébergé en production, les outils à sortir du SaaS en premier, le coût d’une sortie du SaaS sur trois ans, la migration cloud sans tout casser, le gestionnaire de mots de passe d’équipe, les clés d’API volées, le matériel pour faire tourner un modèle d’IA chez soi et le choix d’une messagerie d’entreprise.

Pour des outils auto-hébergés dont les bases sont sauvegardées hors serveur avec une restauration testée, voyez notre offre de sortie du SaaS. Pour un avis sur une base existante, décrivez-nous votre installation.

Questions fréquentes

Sources

1. Twenty, documentation d’auto-hébergement avec Docker Compose (nouvel onglet)docs.twenty.com
2. AWS, Amazon RDS, Backup retention period (nouvel onglet)docs.aws.amazon.com
3. AWS, Amazon RDS, Introduction to backups (nouvel onglet)docs.aws.amazon.com
4. PostgreSQL, Versioning Policy (nouvel onglet)postgresql.org
5. PostgreSQL, Backup and Restore (nouvel onglet)postgresql.org