Patterns d'architecture multi-tenant SaaS

La multi-tenancy est la décision qui façonne discrètement l'ensemble de votre backend SaaS. Bien exécutée, elle vous permet de passer à des milliers de comptes sans friction. Mal exécutée, vous vous retrouvez à réécrire votre couche de données en pleine charge, en pleine croissance, sous le regard de vos clients. La bonne nouvelle : pour la plupart des produits, la bonne réponse est plus simple que ce qu'internet laisse entendre.

Les trois modèles

Il existe trois façons canoniques d'isoler les tenants, chacune arbitrant entre isolation et coût opérationnel :

1. Row-level (schéma partagé). Chaque table possède une colonne tenant_id, et chaque requête filtre sur celle-ci. Une seule base de données, un seul schéma, tous les tenants ensemble.
2. Schema par tenant. Chaque tenant dispose de son propre schéma PostgreSQL au sein d'une base de données partagée. Isolation renforcée, davantage d'objets à gérer.
3. Base de données par tenant. Chaque tenant obtient une base de données ou une instance dédiée. Isolation maximale, charge opérationnelle maximale.

Pourquoi le row-level s'impose pour la majorité des SaaS

Pour l'écrasante majorité des produits B2B SaaS, la multi-tenancy row-level est le bon choix par défaut. C'est le modèle le moins coûteux à opérer, le plus simple à faire évoluer par migrations, et il passe à l'échelle bien au-delà de ce que les fondateurs anticipent. L'objection revient toujours : « mais l'isolation », et Postgres y répond solidement.

Row-Level Security (RLS) permet à la base de données elle-même de garantir qu'une requête ne peut accéder qu'aux lignes de son propre tenant. Avec Supabase, RLS est le modèle natif : vous définissez une politique une fois, et même une requête boguée ne peut pas fuir d'un tenant à l'autre. Associé à un tenant_id sur chaque table et à un index dont il est la clé de tête, ce pattern sert confortablement de larges bases clients.

Un avertissement tiré de l'expérience : rédigez vos politiques RLS de sorte que les fonctions utilitaires s'exécutent une fois par requête, et non une fois par ligne. Une politique qui réévalue une résolution pour chaque ligne ralentira silencieusement vos endpoints au fur et à mesure que les tables grossissent. Encapsulez la vérification pour que le planificateur l'exécute en tant qu'init-plan.

Quand passer à une isolation plus forte

Escaladez de façon délibérée, pas par réflexe :

• Isolation réglementaire ou contractuelle : un client exige que ses données résident dans une base de données physiquement séparée.
• Risque de voisin bruyant : la charge de travail d'un tenant très important dégrade les performances de tous les autres.
• Personnalisation par tenant : les schémas divergent réellement, pas seulement les données.

Même dans ces cas, une approche hybride fonctionne bien : conservez la plupart des tenants en row-level et ne faites migrer vers des bases dédiées que vos comptes les plus importants ou les plus sensibles.

Concevoir pour le modèle dès le premier jour

Quel que soit votre choix, ancrez-le tôt :

• Ajoutez tenant_id à chaque table métier et faites-en la première clé de vos index composites.
• Ne faites jamais confiance au client pour le tenant — déduisez-le de la session authentifiée.
• Faites appliquer l'isolation au niveau de la base de données, pas seulement de la couche applicative, afin qu'une clause WHERE oubliée ne puisse pas provoquer de fuite.
• Faites du provisionnement d'un tenant un seul chemin de code, testé.

L'erreur qui coûte cher n'est pas de choisir le « mauvais » modèle — c'est de laisser la tenancy implicite et d'éparpiller la logique d'isolation dans toute la base de code. Centralisez-la, appliquez-la au niveau de la base de données, et vous conservez la liberté d'évoluer.

Si vous concevez un backend multi-tenant et souhaitez un partenaire ayant mis en production des systèmes PostgreSQL avec RLS à grande échelle, contactez-nous.