</>
Plan du cours — 58/64

Multi-tenance : un schéma, plusieurs clients

Avancé

Une application SaaS doit isoler les données de chaque client (« locataire ») : trois grandes approches.

ApprochePrincipeIsolationCoût d'exploitation
Colonne tenant_idToutes les tables partagent un schéma ; chaque ligne porte son locataireLogique (RLS conseillée)Faible : une seule base à migrer
Schéma par locataireUn schéma PostgreSQL par clientForteMoyen : N schémas à migrer (des milliers = pénible)
Base par locataireUne base (ou instance) par clientMaximaleÉlevé : pools, migrations, sauvegardes par client

Colonne tenant_id, en pratique#

CREATE TABLE commandes (
    tenant_id bigint NOT NULL,
    id        bigint GENERATED ALWAYS AS IDENTITY,
    total     numeric(12, 2) NOT NULL,
    PRIMARY KEY (tenant_id, id)
);
CREATE INDEX ON commandes (tenant_id, cree_le DESC);   -- tous les index commencent par tenant_id
  • Mettre tenant_id en tête de la clé et des index : les requêtes sont toujours filtrées par locataire.
  • Activer la RLS (voir le chapitre sécurité) : un oubli de WHERE tenant_id ne fuit pas de données.
  • Attention aux voisins bruyants : un gros client peut saturer la base ; prévoyez des quotas, ou déplacez-le vers sa propre base.

Astuce : commencez par tenant_id + RLS (le moins cher à exploiter). Réservez la base dédiée aux clients qui l'exigent contractuellement (conformité, isolation, gros volumes).

← Leçon précédenteIdempotence et exécutions multiplesLeçon suivante →Tester avec une vraie base