Patterns
Stratégies de multi-tenancy : row-level vs schema-per-tenant vs DB-per-tenant
Comparatif des 3 modèles d'isolation pour SaaS B2B
Trois patterns coexistent. Row-level (Scell.io) : une seule DB, colonne `tenant_id` sur chaque table, isolation via Row Level Security PostgreSQL ou middleware applicatif. Coût par tenant proche de zéro, requêtes cross-tenant possibles, scaling jusqu'à ~50k tenants. Schema-per-tenant : un schéma PG par tenant, isolation forte au niveau DDL, migrations à exécuter N fois, scaling jusqu'à ~5k schémas avant que pg_catalog ne ralentisse. DB-per-tenant : une instance PG par client, isolation maximale (RGPD, HDS, banking), coût par tenant élevé, scaling limité à ~500 instances par cluster. Scell.io adopte row-level + connexion `pgsql_sandbox` séparée pour la donnée de test. Choix dicté par : exigences réglementaires (HDS → DB-per-tenant), volume tenants (>10k → row-level), variabilité de charge par tenant (très inégale → schema).
À retenir
- Row-level : RLS PostgreSQL ou middleware, scaling jusqu'à 50k tenants
- Schema-per-tenant : isolation DDL forte, limite ~5k schémas
- DB-per-tenant : exigée pour HDS / banking, coûteuse au-delà de 500 clients
- Scell.io : row-level + DB sandbox isolée (sk_test_* / sk_live_*)
- Critère décision : régulation > volume > variabilité de charge
Exemple de code
-- Row Level Security PostgreSQL pour multi-tenancy
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.current_tenant_id')::uuid);
-- Au début de chaque requête (middleware)
SET app.current_tenant_id = '8a7f...';
-- Toute requête est automatiquement filtrée
SELECT * FROM invoices; -- ne retourne QUE les factures du tenant actif