Elegir una arquitectura multi-tenancy es una de las decisiones más trascendentales en el diseño de plataformas SaaS. Afecta a la estructura de costes, al aislamiento de datos, a las características de rendimiento y a la complejidad operativa durante toda la vida del producto. Los tres patrones dominantes son base de datos compartida con discriminación por ID de tenant, esquema por tenant dentro de un servidor de base de datos compartido y base de datos por tenant completamente aislada. Cada patrón ocupa un punto diferente en el espectro entre eficiencia operativa y aislamiento de tenants. Hemos construido plataformas SaaS en producción usando los tres y podemos compartir orientación concreta para emparejar el patrón con el contexto de negocio.
El patrón de base de datos compartida almacena todos los datos de los tenants en tablas comunes, diferenciados por una columna de ID de tenant. Este es el enfoque más eficiente en costes porque la infraestructura escala con el volumen total de datos en lugar del número de tenants. Añadir un nuevo tenant es instantáneo y no requiere aprovisionamiento. Sin embargo, este patrón exige disciplina rigurosa en el diseño de consultas: cada consulta debe incluir el filtro de ID de tenant, y un filtro omitido significa una fuga de datos catastrófica. Mitigamos este riesgo con políticas de seguridad a nivel de fila en la base de datos y middleware obligatorio de contexto de tenant que inyecta el filtro automáticamente. El aislamiento de rendimiento es el otro desafío, ya que un solo tenant ejecutando consultas pesadas puede impactar a todos los demás sin una gobernanza de recursos cuidadosa.
El esquema por tenant proporciona un aislamiento lógico más fuerte mientras comparte el servidor de base de datos subyacente. Cada tenant obtiene su propio esquema con estructuras de tablas idénticas, y la aplicación cambia de esquema según el contexto del tenant autenticado. Este patrón simplifica las conversaciones de cumplimiento porque puedes demostrar límites de datos claros, y las migraciones de esquema específicas por tenant son posibles para la personalización empresarial. El coste operativo crece linealmente con el número de tenants, ya que cada esquema requiere gestión de migración independiente. Hemos encontrado que este patrón funciona bien para productos SaaS B2B con decenas a cientos de tenants donde los requisitos de aislamiento de datos son moderados y se espera alguna personalización por tenant.
La base de datos por tenant ofrece las garantías de aislamiento más fuertes. Cada tenant tiene una instancia de base de datos completamente independiente, potencialmente en hardware dedicado. Este patrón es necesario cuando los tenants tienen requisitos regulatorios de residencia de datos, cuando el aislamiento de rendimiento debe ser absoluto, o cuando los tenants necesitan la capacidad de traer sus propias claves de cifrado. La compensación es una sobrecarga operativa significativa: el aprovisionamiento, la monitorización, el respaldo y la migración deben estar automatizados para cada instancia de tenant. El coste escala directamente con el número de tenants independientemente del uso. Recomendamos este patrón para productos SaaS de nivel empresarial con menos de cien tenants de alto valor donde los requisitos de aislamiento justifican la inversión en infraestructura.