Un SaaS B2B est presque toujours multi-tenant. Trois patterns existent en Postgres, chacun avec ses trade-offs. Choisir le mauvais pour votre stade coûte des jours de refactor.
Défaut recommandé 2025 : Row-Level Security (RLS) avec une colonnetenant_id. Sauf besoin de fort isolement (santé, finance), c'est le meilleur ratio simplicité / sécurité.
Pattern 1 — Row-Level Security (RLS)
- Toutes les tables ont une colonne
tenant_id - Policies Postgres filtrent selon la session
- Une seule base, une seule migration à faire
- Isolation garantie au niveau moteur DB, pas au niveau app
Idéal pour : B2B classique, jusqu'à des milliers de tenants.
Pattern 2 — Schema par tenant
- Un schéma Postgres (
tenant_a,tenant_b) par client - Isolation forte, backup par tenant possible
- Migrations à répliquer sur chaque schéma : complexe
Idéal pour : quelques dizaines de tenants avec besoin d'isolement fort.
Pattern 3 — Base par tenant
- Une base Postgres complète par client
- Isolation totale, conformité facile
- Coût opérationnel élevé, migrations lourdes
Idéal pour : clients grand compte régulés (banque, santé) exigeant isolement souverain.
90 % des SaaS B2B tiennent en Row-Level Security. Le sur-isolement est un coût, pas un gain, jusqu'à ce qu'il devienne exigence contractuelle.
On regarde votre archi ?
En 30 minutes on peut trancher le bon pattern pour votre projet. Réservez un créneau. À lire : Supabase vs Firebase.