Open-source proxy for per-tenant Postgres, no app changes

À propos de Open-source proxy for per-tenant Postgres, no app changes

LokaDB est un proxy PostgreSQL open source qui permet de conserver une seule URL de connexion côté application tout en acheminant les requêtes de certains clients ou organisations vers leur propre base Postgres dédiée. Le projet est publié sous licence Apache-2.0 et fonctionne avec n’importe quel client parlant le protocole Postgres, sans nécessiter de modification de l’application ni de l’ORM. Il cible principalement les SaaS multi-tenant qui souhaitent offrir une séparation forte par tenant sans réécrire leur couche d’accès aux données.

L’architecture repose sur un routage au niveau du protocole Postgres : le proxy intercepte la connexion, identifie le tenant et redirige les opérations vers la base appropriée (centrale ou dédiée). Les tables déplacées deviennent des tables distantes via postgres_fdw, ce qui permet au proxy de maintenir une vue unifiée tout en isolant physiquement les données. Le code source est disponible sur GitHub et la solution peut être déployée en autogéré ou via une offre managée dans le cloud.

Fonctionnalités principales

• Routage par tenant sans changement applicatif : l’application conserve une chaîne de connexion unique ; le proxy identifie le tenant et achemine les requêtes vers le bon Postgres, qu’il s’agisse de la base centrale partagée ou d’une base dédiée. Aucune adaptation du code, de l’ORM ou des migrations n’est requise.

• Modèle hybride : il est possible de laisser certains tenants dans la base cloud centrale tout en déplaçant d’autres vers leur propre Postgres. Cette souplesse permet de traiter progressivement l’isolation sans basculer l’ensemble des clients.

• Déplacement en ligne : une organisation peut être déplacée vers une base dédiée (ou ramenée vers la base partagée) pendant que l’application continue d’écrire. Le processus utilise des mécanismes de synchronisation pour minimiser les interruptions.

• Compatibilité large : le proxy accepte tout client Postgres standard, quel que soit le langage ou l’ORM. Des tests ont été réalisés avec Laravel, Django et Go, mais toute stack utilisant le protocole natif est supportée.

• Tunnel sécurisé : la connexion entre le proxy et la base dédiée s’effectue via un tunnel sortant avec jetons d’enrôlement, renouvellement automatique des certificats, révocation rapide et chiffrement TLS de bout en bout. Aucun accès entrant n’est nécessaire chez le client.

• Architecture FDW : les tables déplacées deviennent des tables étrangères postgres_fdw pointant vers la base du client. Le proxy gère la création et la maintenance de ces liaisons, rendant la topologie transparente pour l’application.

Limitations connues : les triggers avec transition tables et les contraintes impliquant des déclencheurs ne sont pas encore supportés sur les tables déplacées. Il n’y a pas de commit atomique entre la base cloud et la base cliente : deux commits distincts sont effectués, comme avec postgres_fdw utilisé directement. Par ailleurs, les performances diminuent à grande échelle, notamment au-delà de 1000 organisations avec des écritures mixtes, et l’équipe déconseille les écritures mixtes au-delà de 3000 tenants.

Tarification

Aucune grille tarifaire publique n’est disponible dans les sources consultées. LokaDB propose deux modes de déploiement : une version autogérée (self-hosted) à partir du code source ouvert, et une version managée dans le cloud (managed cloud) dont les conditions financières ne sont pas divulguées. Pour obtenir un devis ou connaître les prix des services hébergés, il est nécessaire de contacter directement l’éditeur. La version open source est gratuite, mais les coûts d’infrastructure (serveurs, bande passante, maintenance) restent à la charge de l’équipe qui l’installe.

Cas d’utilisation

• SaaS multi-tenant B2B : les entreprises qui hébergent plusieurs clients dans une même base Postgres et doivent isoler certains d’entre eux pour des raisons de conformité (SOC 2, ISO 27001), de sécurité ou d’exigences contractuelles. LokaDB permet d’extraire un tenant vers sa propre base sans toucher à l’application.

• Segmentation progressive : au lieu d’une migration massive vers des bases dédiées, l’équipe peut ne déplacer que les gros clients ou les clients sensibles, tandis que la majorité des petits comptes reste dans la base partagée. Le modèle hybride facilite cette transition graduelle.

• Réduction des refontes applicatives : lorsqu’une entreprise souhaite offrir une option « bring your own database » ou une base dédiée par client, LokaDB évite de réécrire les requêtes, les schémas ou la logique de routage. L’intégration se fait au niveau de la connexion Postgres.

• Migrations en ligne : déplacer un tenant d’une base partagée vers une base dédiée, ou l’inverse, sans temps d’arrêt pour les utilisateurs. Utile lors d’une montée en gamme ou d’un changement de stratégie d’hébergement.

Notre avis

Avantages

• La promesse centrale est tenue : aucun changement applicatif n’est nécessaire. Les développeurs continuent d’écrire du SQL et d’utiliser leur ORM habituel, ce qui réduit considérablement le coût et le risque de la migration.
• Le caractère open source sous licence Apache-2.0 offre transparence, possibilité d’audit et liberté de déploiement, ce qui est appréciable pour les équipes qui souhaitent maîtriser leur infrastructure.
• L’isolation forte par tenant est obtenue avec une base dédiée pour les organisations ciblées, répondant à des besoins de conformité stricts sans complexité applicative.
• La flexibilité du modèle hybride permet une adoption progressive, ce qui est réaliste pour des SaaS comptant des centaines de clients aux exigences variées.
• La sécurité réseau est renforcée par le tunnel sortant : le client n’a pas à ouvrir de port entrant, et la gestion des certificats est automatisée.

Inconvénients

• L’absence de transaction atomique entre la base cloud et la base cliente est une limitation importante. Les opérations qui touchent à la fois des données partagées et des données dédiées ne peuvent pas être rollbackées ensemble, ce qui complique certains cas métier (facturation, synchronisation).
• Certaines fonctionnalités avancées de PostgreSQL, en particulier les triggers avec transition tables et les contraintes de clé étrangère impliquant des triggers, ne sont pas supportées sur les tables déplacées. Les équipes utilisant intensivement ces mécanismes devront adapter leur schéma.
• La scalabilité est encore limitée pour des volumes élevés de tenants avec des écritures mixtes. Au-delà de quelques centaines d’organisations, les performances peuvent se dégrader, ce qui restreint l’usage pour de très gros SaaS.
• Le produit est jeune : la maturité est en construction, la documentation et la communauté sont encore modestes. Il faudra évaluer la stabilité sur le long terme et la réactivité de l’équipe pour les correctifs.
• La tarification opaque pour l’offre managée rend l’évaluation budgétaire difficile. Les entreprises qui ne souhaitent pas gérer elles-mêmes le proxy devront entamer une démarche commerciale sans visibilité préalable.

Public cible : Équipes backend, SRE ou plateforme de SaaS multi-tenant utilisant PostgreSQL. Le produit convient particulièrement aux organisations B2B qui doivent proposer une option de base dédiée sans réécrire l’application, ainsi qu’à celles qui souhaitent adopter une stratégie hybride entre base partagée et bases dédiées.

Alternatives : Les architectures classiques de multi-tenancy avec séparation par schéma ou par base nécessitent généralement davantage de logique dans l’application. L’utilisation directe de postgres_fdw sans proxy est possible, mais elle impose de gérer le routage et les migrations manuellement. Des plateformes de bases de données managées multi-tenant existent, mais aucune n’est spécifiquement mentionnée dans les sources disponibles. Pour un cas d’usage précis avec des exigences SOC 2 ou ISO 27001, une comparaison détaillée avec ces alternatives peut être utile, mais dépasse le cadre de cette fiche.