Multi-tenant SaaS
Servir a múltiples clientes (tenants) desde la misma aplicación, decidiendo cuánto comparten a nivel de infraestructura y datos.
Modelos comunes
Base de datos compartida con columna `tenant_id`: más barato de operar, pero requiere disciplina estricta para no filtrar datos entre tenants.
Schema por tenant o base de datos por tenant: mejor aislamiento y más fácil de justificar ante requisitos de compliance, a costa de más overhead operativo (migraciones, backups, monitoreo por tenant).
Cuándo tiene sentido
El producto se vende como SaaS a múltiples clientes que no deben ver los datos de otros.
Aislamiento por tenant separado (schema/DB) tiene más sentido cuando hay requisitos regulatorios o clientes grandes que lo exigen contractualmente.
Compensaciones
Base compartida: un bug en el filtro por tenant es un incidente de seguridad, no solo un bug — cada query debe filtrar correctamente.
Base/schema por tenant: cada release toca N bases de datos; escalar a miles de tenants vuelve costosa la gestión operativa.
El modelo elegido afecta directamente cómo se factura, cómo se hacen backups y cómo se cumple con requisitos de residencia de datos.
Comentarios