Addon de base de données ou serveur de base de données : la différence qui compte vraiment
Par défaut, la base de données d’une nouvelle application tourne comme un addon sur le serveur de l’application elle-même — bon marché, rapide, et exactement ce qu’il faut pour démarrer. Ce qui mérite d’être compris avant que ça compte vraiment en production : si ce serveur est perdu, les données de l’addon n’ont que vos sauvegardes comme filet. Un serveur de base de données est l’autre option — un de vos propres serveurs qui contient des données et rien d’autre, avec une histoire de défaillance significativement différente.
Ce qu’un serveur de base de données change vraiment
Déplacer les données vers un serveur de base de données n’est pas juste une machine plus grosse. Ça change ce qui protège les données :
- Il n’a pas de proxy web ni d’outils de build, et aucune application n’y est jamais déployée — il existe pour exactement un seul travail.
- Ses ports de datastore ne sont ouverts qu’aux serveurs d’applications qui l’utilisent réellement, pas accessibles de façon générale.
- Sauvegardes, vérifiées. Chaque base de données d’application sur un serveur de base de données reçoit une sauvegarde quotidienne, et chacune est vérifiée en la restaurant réellement — pas supposée bonne parce que la tâche a rapporté un succès.
- Un serveur de secours, sur Pro et Team. Also create a standby provisionne un second serveur de base de données de même taille qui garde une copie en direct de Postgres, MySQL et Redis, vérifiée toutes les 5 minutes.
- Basculement automatique. Si le serveur principal cesse de répondre pendant 3 minutes et que le serveur de secours a lui aussi, indépendamment, perdu le contact — le serveur de secours prend le relais sur les ports habituels, chaque application qui l’utilisait se redéploie contre lui, et vous recevez une notification qui liste exactement ce qui a bougé.
Un addon sur le serveur de l’application n’a rien de tout ça par construction — il n’a jamais été pensé pour être la couche de durabilité, juste le défaut pratique.
Migrer une application existante
Settings → Resources → Move data to a database server sur l’application, qui liste exactement ce qui sera copié et ce qui démarre vide avant que vous n’appuyiez sur le bouton :
- L’application s’arrête.
- Postgres et MySQL sont dumpés et restaurés sur le serveur de base de données.
- Redis, MongoDB, le stockage d’objets, les définitions RabbitMQ et ClickHouse sont copiés aussi — un Elasticsearch utilisé seulement par cette application vient avec.
- L’application se redéploie.
Si une étape échoue, l’application revient à ses anciennes données — en lecture seule, jamais écrasées — pour qu’une migration échouée ne risque pas la chose qu’elle essayait de protéger.
Quand le réglage par défaut est encore le bon choix
Toutes les applications n’ont pas besoin de ça dès le premier jour. Un outil interne à faible enjeu, un environnement de staging, tout ce où perdre une journée de données à restaurer depuis une sauvegarde est un haussement d’épaules plutôt qu’un incident — le réglage par défaut de l’addon est correctement dimensionné pour ça, et migrer est à une page de réglages de distance dès que le calcul change. Le point n’est pas « utilisez toujours un serveur de base de données ». C’est de savoir lequel vous faites vraiment tourner avant qu’une panne ne soit le moment où vous l’apprenez.
Référence complète, y compris le pooling de connexions et les mises à niveau Postgres : Serveurs de base de données.