Architecture Multi-Tenant & Isolation des Données PostgreSQL
L'isolation des données est le pilier fondamental de tout SaaS B2B critique. Découvrez comment nos architectures de bases de données PostgreSQL garantissent une étanchéité absolue et des performances pérennes.
Comparatif des modèles d'isolation Multi-Tenant
Le choix du patron d'isolation conditionne la sécurité, la complexité opérationnelle et les coûts d'infrastructure de votre plateforme SaaS. Voici l'analyse comparative de nos experts :
Schéma par Tenant (PostgreSQL)
Une seule base de données logique, mais un schéma SQL autonome par client (client_a.users, client_b.users).
- Risque de fuite transverse : Zéro
- Sauvegarde/Restauration sélective
- Coût d'infrastructure optimisé
Row-Level Security (RLS)
Tables mutualisées où chaque enregistrement porte un tenant_id, filtré au niveau du moteur PostgreSQL par des politiques de sécurité strictes.
- Migrations de schéma simplifiées
- Dépendance critique à la config RLS
Base de Données Dédiée
Une instance de base de données physique ou virtuelle complètement séparée par organisation cliente.
- Isolation physique maximale
- Coût d'exploitation plus élevé
// Résolution dynamique du sous-domaine client et routage vers le bon schéma
export async function tenantResolverMiddleware(req: Request, res: Response, next: NextFunction) {
const host = req.headers.host || "";
const subdomain = host.split(".")[0]; // ex: 'acme' -> schema 'tenant_acme'
const tenant = await TenantRegistry.findBySubdomain(subdomain);
if (!tenant || !tenant.isActive) {
return res.status(404).json({ error: "Tenant introuvable ou inactif" });
}
// Initialisation du contexte SQL isolé
const client = await pgPool.connect();
await client.query(`SET search_path TO ${tenant.schemaName}, public`);
req.tenantContext = { id: tenant.id, db: client };
res.on("finish", () => client.release());
next();
}