La arquitectura multi-inquilino en plataformas SaaS requiere equilibrar costos, seguridad y escalabilidad mediante diversos modelos de persistencia. Las opciones varían desde bases de datos compartidas con seguridad lógica hasta instancias dedicadas por cliente. Cada enfoque determina el nivel de aislamiento y la complejidad operativa del sistema de datos.
La implementación técnica prioriza el control de acceso mediante mecanismos como la seguridad a nivel de fila. Los criterios de selección dependen del modelo de negocio, exigencias regulatorias y la gestión de recursos. Es fundamental adoptar arquitecturas flexibles que permitan escalar desde esquemas compartidos hacia entornos aislados según sea necesario.
Modelos de particionamiento de datos en aplicaciones SaaS
La selección entre una infraestructura compartida o dedicada determina la rentabilidad, la complejidad operativa y el cumplimiento de seguridad de una plataforma. Implementar una arquitectura SaaS multi tenant optimiza el uso de cómputo y base de datos, pero traslada la responsabilidad de la seguridad a la capa de software.
La elección técnica debe basarse en el nivel de aislamiento requerido y el costo marginal por cada nuevo cliente (tenant).
Comparativa de estrategias de persistencia
Existen tres patrones fundamentales para estructurar la persistencia de datos en sistemas multi-inquilino:
- Base de datos compartida, esquema compartido: Todos los tenants residen en las mismas tablas, diferenciados por una columna
tenant_id. Ofrece el menor costo de infraestructura y máxima densidad de usuarios, pero requiere políticas estrictas de control de acceso lógico. - Base de datos compartida, esquemas separados: Cada tenant cuenta con su propio esquema (schema) dentro de una misma instancia de base de datos. Facilita migraciones diferenciales y respaldos individuales, con un costo de mantenimiento moderado.
- Base de datos aislada (Database-per-Tenant): Cada cliente opera en una instancia independiente. Maximiza la seguridad y el aislamiento de recursos físicos, pero eleva los costos operativos y dificulta las actualizaciones masivas de esquema.
Implementación de Row-Level Security (RLS)
En esquemas compartidos sobre motores relacionales modernos como PostgreSQL, la seguridad a nivel de fila (RLS) previene fugas de datos entre organizaciones:
- Contexto de sesión: La aplicación define una variable de sesión en la conexión (
SET LOCAL app.current_tenant_id = 'tenant_123') antes de ejecutar cualquier consulta. - Políticas restrictivas de motor: La base de datos aplica automáticamente la cláusula
WHERE tenant_id = current_setting('app.current_tenant_id')en todas las operacionesSELECT,UPDATEyDELETE. - Eliminación del error humano en ORM: Al delegar el filtro al motor de persistencia, se anula el riesgo de que un desarrollador olvide incluir la cláusula de filtrado manual en el código fuente.
Criterios de decisión técnica
Evalúa los siguientes factores antes de definir la arquitectura del sistema:
- Economía de escala: Adopta esquemas compartidos si el modelo de negocio es autoservicio (self-service) o freemium con márgenes unitarios reducidos.
- Ruido de vecinos (Noisy Neighbor): Implementa límites de tasa (rate limiting) y cuotas de cómputo por tenant para evitar que un cliente monopolice los recursos del clúster.
- Requisitos regulatorios: Utiliza bases de datos dedicadas exclusivamente para contratos empresariales que exijan cifrado con llaves gestionadas por el cliente (CMEK) o aislamiento físico estricto.
Inicia con esquemas compartidos protegidos por Row-Level Security en el motor de base de datos y abstrae la capa de acceso a datos para permitir migrar tenants específicos a bases dedicadas conforme escalen sus requerimientos de contrato.
