Application et base de données sur le même serveur?

Oui, pour la plupart des applications. Faire tourner votre application et sa base de données sur la même machine est une configuration de production tout à fait normale, pas un raccourci dont il faut s'excuser. Elle cesse d'être le bon choix pour quelques raisons précises et nommables, et connaître ces raisons est plus utile qu'une règle générale dans un sens ou dans l'autre.

Cet article porte sur l'architecture et la latence. L'argument financier du regroupement fait l'objet d'un autre texte : héberger plusieurs projets sur un seul serveur couvre l'arithmétique de la facturation par service et le dimensionnement de la machine. Ce qui suit suppose que vous avez déjà tranché la question du coût, et demande si la conception tient la route.

Nous vendons de l'hébergement sur une seule VM, nous avons donc un intérêt dans la réponse. La liste des raisons de séparer, plus bas, est la version honnête, pas une version écourtée.

Ce que « même serveur » veut dire concrètement

Deux formes, et la distinction compte moins qu'on ne le croit.

La forme classique : PostgreSQL installé sur l'hôte, l'application s'y connectant par un socket de domaine Unix ou par 127.0.0.1. La forme moderne : l'application et la base de données tournant toutes deux comme conteneurs sur le même hôte, communiquant par un réseau Docker à l'aide du nom du conteneur.

Ni l'une ni l'autre ne place un commutateur, un routeur ou un segment de fibre entre une requête et sa réponse. Les paquets sont traités par le noyau d'une seule machine. C'est là tout le fondement technique de l'argument de latence, et il vaut la peine d'être précis : il s'agit d'une connexion locale, pas d'une absence de réseau. Un saut d'un conteneur à l'autre traverse quand même un pont virtuel et un espace de noms réseau. Il ne quitte simplement jamais la machine.

Ce que coûte réellement le saut réseau

Le trajet aller-retour d'une seule requête sur le réseau est court en valeur absolue. Les fournisseurs infonuagiques publient des chiffres à ce sujet, et ce sont de bons chiffres.

AWS décrit les zones de disponibilité d'une même région comme distantes d'au plus 60 milles, mais « assez proches pour permettre une réplication synchrone avec une latence d'un seul chiffre en millisecondes ». Microsoft publie des médianes mesurées entre ses régions Azure. Dans ses statistiques de latence aller-retour, les chiffres publiés en août 2026 situent le P50 entre Canada Central et Canada East à 13 ms, et celui entre Canada Central et East US à 18 ms. Ce sont les chiffres de Microsoft, mesurés sur son réseau, pas les nôtres.

Une latence d'un seul chiffre en millisecondes à l'intérieur d'une région, c'est un réseau bien conçu qui fait son travail, et d'énormes systèmes de production fonctionnent très bien exactement de cette façon. Un seul saut n'est pas le problème. Une requête web émet rarement une seule requête SQL.

Le chiffre d'AWS porte sur la réplication synchrone entre zones de disponibilité, pas sur l'aller-retour d'une requête applicative, et un saut à l'intérieur d'une même zone est encore plus rapide. Il donne quand même un plancher utile. Appelons-le 1 ms pour les besoins du calcul, ce qui fait des chiffres ci-dessous le scénario le plus favorable à la séparation. Une requête web qui émet 40 requêtes SQL séquentielles, chacune attendant la précédente, passe 40 ms à ne rien faire d'autre qu'attendre le réseau. Les mêmes 40 requêtes vers une base de données sur le même hôte paient une fraction de ce coût par saut, parce qu'aucun lien physique n'est traversé. Déplacez maintenant la base de données dans une autre région plutôt que dans une autre zone. À la médiane publiée par Microsoft de 18 ms entre Canada Central et East US, ces mêmes 40 requêtes séquentielles coûtent environ 720 ms d'attente pure, avant même que la base de données ait fait le moindre travail.

Rien de cela ne rend votre base de données plus rapide. La différence porte sur la pénalité associée aux schémas de requêtes déjà un peu bancals :

• Les requêtes N+1. Un ORM qui charge paresseusement un enregistrement lié à l'intérieur d'une boucle transforme une opération logique en des dizaines d'allers-retours séquentiels. C'est de loin la façon la plus courante dont une page devient limitée par la latence plutôt que par le processeur.
• Les gestionnaires de requêtes bavards. Vérification d'authentification, consultation d'un indicateur de fonctionnalité, enregistrement de l'utilisateur, permissions, puis la vraie requête. Cinq allers-retours avant que quoi que ce soit d'intéressant ne se produise.
• L'établissement de la connexion. Une poignée de main TCP suivie d'une négociation TLS représente plusieurs allers-retours avant même l'envoi de la première requête. Le regroupement de connexions amortit ce coût plutôt que de l'effacer, et les bassins de connexions s'épuisent toujours au pire moment.

La bonne façon de corriger un N+1 reste de corriger le N+1. La colocalisation ne remplace pas ce travail. Elle fait cependant qu'une erreur de ce genre dégrade une page au lieu de la casser, ce qui est une différence opérationnelle bien réelle quand vous livrez rapidement en petite équipe.

Quand la colocalisation est le bon choix

Elle convient lorsque votre application et votre base de données évoluent ensemble, ce qui décrit la majorité des applications de petite et moyenne taille :

• Une application, une base de données, qui grandissent à peu près au même rythme.
• Une charge de travail où une machine plus grosse règle le prochain problème de capacité.
• Une équipe qui préfère bien exploiter un serveur plutôt que deux passablement.
• Une exigence de résidence des données où vous préférez vérifier un seul emplacement plutôt que deux. Si l'application et la base de données vivent sur la même VM à Toronto, il n'y a qu'une seule question de juridiction à trancher.

Quand c'est le mauvais choix

Soyons honnêtes sur ces cas, parce qu'ils ne sont pas marginaux.

Vous avez besoin de mettre à l'échelle séparément. Si votre base de données manque de processeur pendant que vos serveurs d'application sont inactifs, ou l'inverse, une seule machine vous oblige à payer pour les deux. Séparer permet à chaque partie de suivre sa propre courbe.

Vous avez besoin de haute disponibilité ou de bascule automatique. Une machine, c'est un seul domaine de panne. Si l'hôte tombe, l'application et la base de données tombent ensemble, et votre délai de rétablissement correspond à la durée d'une restauration. Les services de bases de données multinœuds existent parce que certaines charges de travail ne peuvent pas accepter cela. Si quelques heures d'interruption constituent un problème d'affaires plutôt qu'un désagrément, c'est la raison de séparer.

Votre jeu de données est réellement volumineux. Dès que la base de données réclame plus de disque, de mémoire ou d'entrées-sorties soutenues qu'une seule VM de taille raisonnable ne peut fournir, la cohabitation cesse d'être gratuite. Votre application entre alors en concurrence avec le cache disque.

Vous avez besoin de plus d'un serveur d'application. Dès qu'une deuxième instance existe, la base de données doit de toute façon être joignable hors de la machine, et l'argument de la colocalisation s'évapore.

La séparation est une exigence contractuelle ou de conformité. Certaines ententes précisent où et comment les données sont stockées, indépendamment de l'application. Si un contrat exige que la base de données soit séparée, la question d'architecture est déjà réglée.

Deux choses à bien faire si vous colocalisez

Ces deux mesures font l'essentiel de la réduction du risque.

Les sauvegardes, parce que tout se retrouve au même endroit. Perdre la machine, c'est perdre l'application et les données en même temps, alors des sauvegardes de base de données conservées hors du serveur ne sont pas facultatives. Sur MapleDeploy, la fonction de sauvegarde intégrée à Coolify écrit vers n'importe quel stockage compatible S3, selon l'horaire et le nombre de rétentions que vous fixez. Choisissez la région de ce stockage délibérément : une sauvegarde est une copie complète de vos données, donc un stockage situé aux États-Unis place cette copie sous une seconde juridiction, peu importe où se trouve la VM. Optez pour une région canadienne, ou à tout le moins non américaine, si la résidence des données est ce qui vous amène ici.

MapleDeploy prend aussi, dans la mesure du possible, des instantanés hebdomadaires de la VM complète, ainsi qu'un instantané avant toute suppression. Cet instantané de pré-suppression est conservé 30 jours après l'annulation. Les instantanés hebdomadaires, eux, disparaissent avec la VM. Considérez l'ensemble comme notre filet de sécurité, pas comme le vôtre : ils ne sont pas garantis, ils peuvent dater de jusqu'à sept jours, et ils forment une couche de reprise après sinistre plutôt qu'un outil de restauration fine. Notre guide de sauvegarde présente les étapes de configuration et les limites réelles de chaque couche. Testez une restauration, pas seulement la tâche de sauvegarde.

Les limites de ressources, parce que vos propres charges deviennent voisines les unes des autres. Une compilation qui s'emballe ou une fuite de mémoire dans l'application peut affamer la base de données sur le même hôte. Coolify expose des limites de mémoire et de processeur par ressource exactement pour cela, et les fixer une fois coûte moins cher que de diagnostiquer un arrêt pour manque de mémoire à 2 h du matin.

Comment ça fonctionne sur MapleDeploy

MapleDeploy exploite Coolify géré sur une machine virtuelle (VM) dédiée à Toronto. PostgreSQL fait partie des bases de données déployables en un clic dans Coolify, et elle tourne comme conteneur sur la même VM que votre application. Coolify vous fournit une chaîne de connexion interne qui pointe vers le conteneur de base de données par son nom, résolu par le réseau Docker de cet hôte : le trafic entre l'application et la base de données reste donc sur la machine par défaut. La base de données n'est pas exposée à Internet à moins que vous ne l'ouvriez délibérément par le proxy TCP de Coolify avec un port public.

Ce que vous n'obtenez pas en un clic, c'est la bascule multinœud, les répliques de lecture ou la restauration à un instant précis au-delà de l'horaire de sauvegarde que vous avez configuré. Vous avez l'accès root sur la VM, donc rien ne vous empêche de bâtir tout cela vous-même, mais Coolify ne le gérera pas pour vous. Si vous préférez que quelqu'un d'autre exploite la haute disponibilité de la base de données, un service géré dédié est le meilleur outil, et où héberger du PostgreSQL géré au Canada compare honnêtement les options offertes en région canadienne, y compris celles qui nous devancent sur ce point précis.

Colocalisez par défaut. Séparez quand vous pouvez nommer laquelle des raisons ci-dessus s'applique à vous.