Qu'est-ce qu'une architecture de base de données multi-tenant ?

L’architecture de base de données multi-tenant est un modèle qui stocke de nombreux clients dans une couche de données, isolés par ligne, schéma ou base dédiée. Ces trois niveaux d’isolation constituent tout l’espace de décision — le reste du sujet n’en est que la conséquence : comment s’exécutent les migrations, ce que coûte une restauration, où vit le noisy neighbor (voisin bruyant) et jusqu’où chaque modèle passe à l’échelle.

Points clés

Les trois modèles, en SQL

-- Modèle 1 · Schema partagé ("pool") : un seul jeu de tables, le tenant sur chaque ligne
CREATE TABLE invoices (
  tenant_id uuid   NOT NULL,
  id        bigint GENERATED ALWAYS AS IDENTITY,
  total     numeric(10,2),
  PRIMARY KEY (tenant_id, id)      -- le tenant en tête : prêt pour l'index et le sharding
);
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_rows ON invoices
  USING (tenant_id = current_setting('app.tenant')::uuid);

-- Modèle 2 · Schema par tenant ("bridge") : une seule base, un namespace chacun
CREATE SCHEMA tenant_acme;          -- mêmes tables, répétées pour chaque tenant

-- Modèle 3 · Base par tenant ("silo") : séparation physique complète
CREATE DATABASE tenant_acme;        -- isolation la plus forte ; N exemplaires de tout

Sur un backend géré, la même garantie s’exprime sans SQL : le contrôle d’accès vit sur les données elles-mêmes, donc l’isolation tient sur chaque chemin — API, dashboard ou SDK :

// JavaScript / Node.js — Back4app JS SDK
// The same query for every tenant — ACLs scope results server-side
const query = new Parse.Query('Invoice');
const invoices = await query.find({ sessionToken: user.getSessionToken() });
// Only rows this tenant's role can read come back. No WHERE clause to forget.

// Flutter / Dart — Back4app Flutter SDK
// The same query for every tenant — ACLs scope results server-side
final query = QueryBuilder<ParseObject>(ParseObject('Invoice'));
final response = await query.query();
// The session's role decides which rows exist, before results leave the server
if (response.success) {
  print('${response.results?.length} invoices visible to this tenant');
}

// iOS / Swift — Back4app Swift SDK
// The same query for every tenant — ACLs scope results server-side
let query = Invoice.query()
query.find { result in
  if case .success(let invoices) = result {
    print("\(invoices.count) invoices visible to this tenant")
  }
}

// Android / Kotlin — Back4app Android SDK
// The same query for every tenant — ACLs scope results server-side
val query = ParseQuery.getQuery<ParseObject>("Invoice")
query.findInBackground { invoices, e ->
  if (e == null) {
    Log.d("Billing", "${invoices.size} invoices visible to this tenant")
  }
}

Schema partagé vs. schema par tenant vs. base par tenant

Les pièges

• L’indexation se fait « tenant d’abord ». tenant_id figure dans chaque table — même là où les jointures le font paraître redondant — et ouvre chaque index composite : (tenant_id, created_at), pas l’inverse. Chaque requête réelle est restreinte à un tenant ; les index doivent l’être aussi.
• Les migrations se multiplient avec l’isolation. La flexibilité du silo se paie d’une couche d’orchestration : suivi des versions par tenant, logique de nouvelle tentative, détection de dérive. Les équipes sous-estiment cette ligne plus que n’importe quelle autre du tableau.
• La sécurité au niveau des lignes a ses petites lignes opérationnelles. Les politiques s’appuient sur des paramètres par connexion, qui interagissent avec les modes de pooling de connexions — définissez le tenant par transaction, et testez le pooler. Auditez aussi quels rôles contournent RLS ; les chemins superutilisateur sont la faille classique.
• L’arithmétique des connexions. Un pool par base de tenant épuise vite les connexions ; les conceptions à schema partagé partagent un seul pool — un autre avantage discret du modèle pool, qui n’apparaît qu’à grande échelle.
• L’asymétrie de restauration pousse à la répartition par niveaux. “Pouvez-vous restaurer uniquement nos données à hier ?” est une question de contrat grand compte ; si la réponse doit être oui, ce tenant a sa place dans un silo — ce qui mène directement à l’hybride.

Passage à l’échelle et état final hybride

La voie de croissance du modèle pool est le sharding par tenant : plusieurs bases à schema partagé, chacune contenant une partie des tenants, avec un catalogue qui associe tenant → shard (le projet open-source Citus a intégré cela dans PostgreSQL, y compris le déplacement d’un tenant très actif vers son propre nœud). Combiné à une répartition en tiers, cela donne l’architecture vers laquelle convergent la plupart des SaaS matures : le tier gratuit mutualisé, les tenants de taille moyenne mutualisés sur plusieurs shards, et les quelques tenants réglementés ou énormes en silo — avec tenant_id conservé dans chaque schéma, partout, pour que n’importe quel tenant puisse changer de tier sans refonte. La mobilité des tenants est la propriété à concevoir dès le premier jour ; il est presque impossible de l’ajouter après coup.

Cas d’usage courants

• SaaS B2B. Le cas fondateur : chaque workspace, organisation ou équipe de votre produit est un tenant dans l’un de ces modèles.
• Produits freemium à grande échelle. Des milliers de petits tenants gratuits mutualisés à un coût marginal proche de zéro — l’économie qui rend les offres gratuites possibles.
• Secteurs réglementés. Des clients de la santé, de la finance et du juridique qui exigent contractuellement des silos — servis depuis la même base de code grâce à l’hybride.
• Agences et plateformes. Une application qui sert de nombreuses organisations clientes, chacune avec sa propre frontière.
• Plateformes internes multi-équipes. Les départements comme tenants sur des outils partagés — mêmes modèles, modèle de menace plus clément.

Quel modèle devriez-vous choisir ? Matrice de décision

Et la méta-réponse : choisissez par niveau, pas par entreprise — les conceptions hybrides placent chaque tenant dans le modèle le moins cher qui satisfait ses exigences, et le déplacent quand ces exigences changent.

Limites et trade-offs

• Schema partagé : le besoin le plus fort d’une isolation appliquée par la base de données — un filtre oublié est une brèche, c’est pourquoi RLS ou les ACL de la couche de données sont non négociables, et non un durcissement optionnel.
• Schema par tenant : l’entre-deux inconfortable — une orchestration des migrations comparable à celle du silo, une isolation plus faible que celle du silo, et des limites de métadonnées de la base qui arrivent étonnamment tôt.
• Base par tenant : tout × N — migrations, sauvegardes, supervision, connexions, coût — et l’analytique entre tenants qui devient un projet de data engineering.
• Les trois : le contexte de tenant envahit tout (requêtes, caches, jobs, logs), et passer d’un modèle à l’autre coûte cher sans discipline des identifiants dès le premier jour : identifiants globalement uniques et colonnes tenant_id partout, même dans les silos.

Les données multi-tenant sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l’authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Sa réponse à la règle absolue de cet article — appliquer l’isolation dans la base de données — ce sont des ACL par objet, des rôles par tenant et des permissions au niveau de la classe, vérifiés par la plateforme à chaque requête et depuis chaque surface, comme le montrent les onglets de code ci-dessus. C’est le modèle à schema partagé, débarrassé du risque de la clause WHERE ; l’analyse d’ingénierie sur la sécurité au niveau des lignes détaille le modèle complet sur une base de données documentaire, et la vue côté hébergement du même sujet couvre le niveau d’infrastructure situé au-dessus.