L'équipe migre vers Postgres managé pour « ne plus gérer la base ». Premier incident : connexions épuisées parce que chaque worker serverless ouvre dix pools — le fournisseur limite à cent connexions sur le tier d'entrée. Deuxième surprise : restauration possible à la journée, pas à la minute — un RPO incompatible avec une boutique en ligne.
PostgreSQL managé délègue l'exploitation machine : système d'exploitation, moteur, sauvegardes infrastructure, parfois bascule automatique. Il ne délègue ni la conception du schéma, ni les requêtes lentes, ni les migrations mal testées. Lisez le contrat comme un DBA minimaliste — pas comme une promesse de sérénité totale.
Ce que le fournisseur prend en charge (en principe)
| Tâche | Souvent inclus | À vérifier |
|---|---|---|
| Patch OS + Postgres mineur | Oui | Fenêtre de maintenance, montée de version majeure |
| Sauvegardes automatiques | Oui | Rétention, PITR, restauration testée |
| Bascule haute disponibilité | Selon l'offre | RTO annoncé, réplication synchrone ou asynchrone |
| Monitoring infrastructure | CPU, disque, connexions | Alertes configurables |
| Chiffrement au repos | Souvent | Clés gérées par le client ? |
| Montée en charge verticale | Via console | Coupure ou bascule en ligne |
Ce qui reste chez vous
Même avec la meilleure offre managée, plusieurs responsabilités ne quittent jamais votre équipe :
- Schéma et migrations — DDL, stratégie de rollback, compatibilité N/N+1 entre versions applicatives.
- Performance des requêtes — EXPLAIN, index, réglage du vacuum parfois limité selon l'hébergeur.
- Connexions — pooler (PgBouncer, Supavisor) côté application ou add-on managé.
- Sécurité logique — rôles, GRANT, configuration row-level security.
- Données sensibles — chiffrement applicatif, anonymisation, conformité RGPD.
- Exercice de restauration — le bouton existe dans la console ; savoir cliquer sous stress, non.
Si votre stack hérite encore de MySQL, comparez avec MySQL pour un site dynamique avant de basculer.
Lire une offre sans se faire avoir
Avant de signer, posez ces questions — et exigez des réponses documentées, pas des formulations marketing :
- RPO et RTO pour une restauration — pas un vague « sauvegardes quotidiennes ».
- Extensions requises disponibles sur votre tier ?
- Limite de connexions par rapport à votre architecture (Redis, fonctions serverless, workers multiples).
- Sortie réseau si l'application tourne dans une autre région ou un autre cloud.
- Verrouillage — export pg_dump, format standard, délai de sortie.
- Région UE et DPA conforme (RGPD et choix d'hébergeur).
| Signal faible | Signal fort |
|---|---|
| « Sauvegarde incluse » sans rétention | PITR 7–35 jours documenté |
| Pas de pooler proposé | Pooler managé ou documentation PgBouncer |
| Version Postgres figée depuis des années | Politique de montée de version publiée |
Postgres managé vs VPS auto-administré
Le managé gagne si vous n'avez pas de DBA, si la haute disponibilité est requise, si les audits exigent des sauvegardes prouvées, ou si personne ne souhaite patcher à trois heures du matin.
Le VPS gagne si vous avez besoin d'extensions exotiques, d'un réglage kernel fin, d'un coût fixe minimal, ou d'une compétence Postgres interne solide.
Un hybride fréquent : production managée + restauration locale mensuelle pour l'exercice de reprise.
Le sommet : le bouton restore n'est pas un plan de reprise
Exigez un exercice de restauration trimestriel — même sur un tier managé. Le jour de l'incident, vous remercierez d'avoir chronométré la procédure à froid.
Décider et avancer sans angle mort
Avant de choisir une offre Postgres managée, alignez le contrat sur votre usage réel :
- Fixez les RPO et RTO métier — combien de minutes de données perdues et combien d'heures d'indisponibilité sont acceptables.
- Comparez deux ou trois offres européennes sur les extensions, les connexions et la restauration à un instant précis.
- Ajoutez un pooler dès le premier déploiement, pas après la première saturation de connexions.
- Automatisez les migrations dans votre pipeline d'intégration continue, avec revue et rollback documenté.
- Planifiez un exercice de restauration trimestriel et consignez le délai réel obtenu.
Parcourez notre annuaire et le comparateur pour filtrer les hébergeurs proposant une base managée adaptée à votre région.
Questions fréquentes
Postgres managé inclut-il les migrations applicatives ?
Non. Le fournisseur maintient l'instance ; vous gérez le DDL et les migrations via votre code. Une migration foireuse reste votre responsabilité.
Les backups automatiques suffisent-ils ?
Seulement si les RPO/RTO du contrat correspondent à vos besoins et si vous avez testé une restauration réelle — voir tester une restauration.
Les extensions PostgreSQL sont-elles toujours disponibles ?
Non. Chaque hébergeur publie une liste blanche. Vérifiez PostGIS, pgvector ou TimescaleDB avant de verrouiller une fonctionnalité.
RDS vs Scaleway vs OVH ?
Périmètres différents — comparez pooler, régions, sortie réseau et interface sur un scénario identique.
PostgreSQL managé : vous déléguez le datacenter de la base — pas la responsabilité sur vos données ni sur vos requêtes.