Vous construisez un produit B2B. Comment isolez-vous les données d'un client de celles d'un autre ?

Les trois options sont un schéma partagé avec une colonne d'identifiant de tenant, un schéma par tenant, et une base par tenant, en arbitrant entre simplicité opérationnelle et isolation. Le schéma partagé passe le mieux à l'échelle et coûte le moins cher mais exige que le filtre de tenant soit appliqué structurellement, par exemple avec la sécurité au niveau ligne ou une couche de données qui l'applique toujours. Une base par tenant donne l'isolation la plus forte et la restauration par client la plus simple, à un vrai coût opérationnel.

Mon choix par défaut est un schéma partagé avec un identifiant de tenant sur chaque table, parce que c'est le moins cher à exploiter et qu'intégrer un client est une insertion plutôt qu'un travail de provisionnement. Le danger est évident, une clause where manquante fuit des données entre clients, donc je ne laisse jamais ça à la discipline. J'utilise la sécurité au niveau ligne avec le tenant défini depuis la session authentifiée, pour que même une requête écrite à la main ne renvoie rien en dehors du tenant, et j'ajoute des tests qui tentent délibérément de lire les lignes d'un autre tenant. Je passe à un schéma ou une base par tenant quand il y a un vrai déclencheur : un client avec une exigence contractuelle de résidence des données, une poignée de comptes grands comptes assez gros pour constituer leur propre charge, ou un régime de conformité qui veut une séparation démontrable. Les coûts sont ceux que les gens sous-estiment : une migration tourne désormais sur chaque schéma, le pooling de connexions devient plus dur, et il faut de l'automatisation pour le provisionnement et la restauration par tenant. J'ai aussi dû traiter les voisins bruyants séparément, avec des limites de débit par tenant, parce que l'isolation des données n'est pas l'isolation de la capacité.