Où exécuter une base PostgreSQL gérée au Canada

Pour exécuter une base PostgreSQL gérée au Canada, vous avez de vraies options : AWS, Azure et Google Cloud offrent tous du PostgreSQL géré dans des régions canadiennes, tout comme des fournisseurs indépendants comme DigitalOcean et OVHcloud. Vous pouvez aussi vous passer complètement de la couche gérée et exploiter PostgreSQL vous-même sur une machine virtuelle (VM) canadienne.

La question la plus difficile est celle que la plupart des guides oublient : où votre application s'exécute-t-elle par rapport à la base de données? Une instance PostgreSQL gérée à Montréal ne signifie pas automatiquement que votre application est aussi à Montréal. Le calcul et la base de données sont habituellement des services distincts, parfois facturés séparément, parfois dans des régions différentes à moins que vous ne les fassiez correspondre. Cet écart vaut la peine d'être vérifié avant de choisir quoi que ce soit.

Options de PostgreSQL géré avec des régions canadiennes

AWS, Azure et Google Cloud dans des régions canadiennes

Les trois géants du cloud exploitent du PostgreSQL géré au Canada. AWS RDS et Aurora PostgreSQL sont tous deux offerts dans la région Canada (Central), basée à Montréal, ainsi que dans Canada West (Calgary), ouverte en décembre 2023. Azure Database for PostgreSQL Flexible Server fonctionne dans Canada Central (Toronto) et Canada East (Ville de Québec). Google Cloud SQL for PostgreSQL couvre à la fois Montréal (northamerica-northeast1) et Toronto (northamerica-northeast2).

Si votre application tourne déjà sur EC2, Azure App Service ou Cloud Run dans la région canadienne correspondante, c'est la voie la plus simple : même compte cloud, même région, même facturation. Ce qui mérite d'être vérifié, c'est justement cette correspondance de région. Il est facile de provisionner une base de données dans Canada Central pendant que votre calcul se trouve dans East US ou une tout autre région, surtout dans une équipe où les choix d'infrastructure se font dans des tickets distincts par des personnes différentes. Le trafic entre régions, entre votre application et votre base de données, entraîne aussi généralement ses propres frais de transfert de données.

DigitalOcean, OVHcloud et Supabase

Le PostgreSQL géré de DigitalOcean est offert à Toronto (TOR1), aux côtés des autres services de DigitalOcean dans cette région, de sorte qu'un droplet ou un déploiement App Platform à Toronto peut cohabiter avec une base de données à Toronto. OVHcloud exploite son offre Public Cloud Databases, incluant PostgreSQL, à partir de Beauharnois, au Québec, et OVHcloud a son siège social en France, ce qui la place hors de la juridiction américaine si cela compte pour vous. Supabase vous permet de choisir Canada (Central) comme région de base de données pour votre projet, mais l'hébergement de Supabase couvre la base de données et les outils qui l'entourent. La plupart des projets Supabase déploient leur code applicatif ailleurs, souvent sur Vercel ou Netlify, des plateformes américaines sur une infrastructure américaine.

Exécuter PostgreSQL vous-même sur une VM canadienne

L'option que la plupart des listes de ce genre sous-estiment : louez une VM chez un fournisseur canadien, qu'il soit détenu ou simplement hébergé au Canada, et exploitez PostgreSQL directement dessus, soit avec apt install postgresql, soit dans un conteneur Docker. Vous obtenez un contrôle complet sur la configuration, les extensions et la version, et la base de données réside là où réside la VM. Le coût est opérationnel : les correctifs, les sauvegardes, la surveillance et l'appel à 2 h du matin en cas de problème vous reviennent.

C'est aussi la catégorie dans laquelle se situe MapleDeploy, avec une couche de gestion en plus. Plus de détails ci-dessous.

Pourquoi exécuter la base de données sur la même VM que votre application compte

Avec toutes les options ci-dessus, sauf les deux dernières, l'application et la base de données sont des services distincts. C'est normal, et pour beaucoup d'équipes, c'est exactement ce qu'elles veulent : une mise à l'échelle indépendante, une base de données qui peut survivre à n'importe quel serveur d'application, une couche gérée avec sa propre entente de niveau de service. Mais cela signifie aussi que la juridiction est une question à laquelle vous répondez deux fois, une fois pour l'endroit où tourne votre calcul, une fois pour l'endroit où réside votre base de données, et rien ne garantit que les deux réponses concordent à moins que quelqu'un ne le vérifie.

Exécuter PostgreSQL sur la même VM canadienne que votre application élimine toute cette catégorie de questions. Il n'y a aucun saut entre régions entre votre application et votre base de données, puisqu'il n'y a pas de deuxième région. Il n'y a aucuns frais de sortie séparés pour le trafic entre les deux, puisqu'il ne quitte jamais la machine. Et il n'y a exactement qu'une seule chose à vérifier pour la résidence des données, pas deux.

Ce n'est pas une solution universelle. Si votre base de données doit évoluer indépendamment de votre application, si vous voulez des répliques de lecture plus près des utilisateurs dans d'autres régions, ou si vous voulez précisément la couche opérationnelle qu'offre un service de base de données géré dédié, comme la bascule automatique multi-nœuds, une instance PostgreSQL gérée séparément est le meilleur choix, et plusieurs des options canadiennes ci-dessus le feront bien. Le cohébergement est le bon compromis lorsque votre application et votre base de données évoluent ensemble, ce qui décrit la plupart des applications de petite et moyenne taille.

Ce que le PostgreSQL géré de MapleDeploy offre (et n'offre pas)

MapleDeploy exploite Coolify géré sur une VM dédiée à Toronto pour chaque client. PostgreSQL est l'une des bases de données en un clic de Coolify, avec MySQL, MariaDB, MongoDB, Redis, KeyDB, Dragonfly et ClickHouse. Provisionner une base de données prend un clic depuis le tableau de bord Coolify, et elle s'exécute comme un conteneur sur la même VM que votre application, avec les détails de connexion prêts à copier dans les variables d'environnement de votre application.

Voici, clairement, ce que cela comprend et ce que cela ne comprend pas.

Inclus :

• Provisionnement PostgreSQL en un clic, sans inscription ni relation de facturation distincte avec un fournisseur de base de données.
• Les sauvegardes de base de données intégrées à Coolify, vers un stockage local ou tout compartiment compatible S3, selon un horaire et un nombre de conservations que vous définissez depuis le tableau de bord.
• Des instantanés hebdomadaires de l'ensemble de la VM, système d'exploitation, Coolify, conteneurs et bases de données compris, ainsi qu'un instantané final pris avant la résiliation et conservé 30 jours après l'annulation, comme couche distincte de reprise après sinistre.
• La base de données et l'application sur la même VM, la même région, un prix mensuel fixe sans frais de base de données par service.

Non inclus comme fonctionnalités en un clic :

• Bascule automatique entre plusieurs nœuds de base de données.
• Répliques de lecture.
• Récupération à un point dans le temps au-delà de ce que capture votre horaire de sauvegarde configuré. Les sauvegardes PostgreSQL de Coolify sont des instantanés pg_dump selon l'horaire que vous choisissez, pas un archivage continu des journaux de transactions.

Il vaut la peine d'être précis sur le sens de cette seconde liste, parce qu'elle porte sur l'outillage en un clic et non sur le serveur. Vous avez un accès root sur une machine virtuelle dédiée qui exécute Docker, alors rien ne vous empêche de monter une topologie PostgreSQL répliquée, un gestionnaire de connexions ou un archivage des journaux vers votre propre stockage objet. C'est à vous de le mettre en place et de l'entretenir, et Coolify ne le gérera pas pour vous.

La distinction honnête est donc celle-ci. Si vous voulez que quelqu'un d'autre exploite la haute disponibilité de votre base de données, un service PostgreSQL géré dédié est le bon outil, et plusieurs des options ci-dessus le font bien. Si vous voulez une instance PostgreSQL simple qui tourne juste à côté de votre application, avec les sauvegardes prises en charge et la liberté d'aller plus loin vous-même, c'est ce que le PostgreSQL en un clic sur MapleDeploy vous donne.

Propriété et juridiction, en bref

Presque tous les géants du cloud et la plupart des fournisseurs indépendants ci-dessus sont des entreprises américaines, ce qui signifie que le CLOUD Act américain s'applique à eux, peu importe la région où résident vos données. Parmi les services PostgreSQL gérés tiers, OVHcloud fait exception, avec son siège social en France. MapleDeploy est détenue et exploitée au Canada, avec des serveurs à Toronto. Que cette distinction compte pour vous dépend de si la juridiction est une exigence de conformité ou une préférence, et les deux sont des raisons légitimes. Consultez notre portrait complet de la résidence des données canadiennes pour la version détaillée.

Une courte liste de vérification avant de choisir

• Le fournisseur a-t-il vraiment une région canadienne pour la base de données, et pas seulement pour le stockage d'objets ou le site marketing?
• Où votre application s'exécute-t-elle, et est-ce la même région que la base de données?
• Y a-t-il des frais de sortie distincts pour le trafic entre votre application et votre base de données?
• Avez-vous besoin d'une bascule multi-nœuds, de répliques de lecture ou d'une récupération à un point dans le temps, ou une instance unique avec des sauvegardes planifiées suffit-elle?
• L'entreprise elle-même est-elle canadienne, européenne ou américaine, et cette réponse répond-elle à la question de juridiction dont votre équipe de conformité, ou vous-même, avez réellement besoin?