Cuando construyes software que sirve a múltiples empresas — cada una con sus propios empleados, datos y configuraciones — estás construyendo un sistema multi-tenant. Acertar con la arquitectura desde el principio ahorra meses de refactorización dolorosa más adelante. Equivocarse significa fugas de datos, cuellos de botella en el rendimiento e incidentes de seguridad.
En TitanGO Labs, cada producto que construimos es multi-tenant por diseño. Así es como lo abordamos.
Qué significa realmente multi-tenancy
En una aplicación multi-tenant, un único despliegue sirve a múltiples organizaciones (tenants). Cada tenant ve solo sus propios datos, usuarios y configuraciones — como si tuviera su propia instancia privada del software. Pero internamente, comparten el mismo código de aplicación, infraestructura de base de datos y despliegue.
La alternativa — despliegues single-tenant donde cada cliente tiene su propio servidor — funciona para software empresarial con grandes presupuestos. Para la mayoría de productos SaaS dirigidos a pequeñas y medianas empresas, no es viable económicamente.
Las tres estrategias de aislamiento
Existen tres enfoques comunes para el aislamiento de datos de tenants, cada uno con sus pros y contras:
1. Base de datos compartida, esquema compartido
Todos los tenants comparten las mismas tablas de base de datos. Cada fila incluye una columna tenant_id, y cada consulta filtra por ella.
Ventajas: El más sencillo de configurar. Menor coste de infraestructura. Fácil de consultar entre tenants para analítica.
Desventajas: Una cláusula WHERE tenant_id = ? olvidada significa una fuga de datos. El rendimiento de las consultas se degrada a medida que la tabla crece con todos los tenants. Más difícil ofrecer personalización por tenant.
2. Base de datos compartida, esquemas separados
Cada tenant obtiene su propio esquema de base de datos (namespace) dentro del mismo servidor. Las tablas son idénticas en estructura pero están físicamente separadas.
Ventajas: Fuerte aislamiento sin servidores separados. Las migraciones por tenant son posibles. Un error en una consulta no puede filtrar datos de otro tenant.
Desventajas: La gestión de esquemas se vuelve compleja a escala. El pool de conexiones necesita un ajuste cuidadoso. Algunas bases de datos manejan esto mejor que otras (PostgreSQL destaca aquí).
3. Bases de datos separadas
Cada tenant obtiene su propia base de datos completa.
Ventajas: Máximo aislamiento. Fácil de hacer backup, restaurar o migrar tenants individuales. El rendimiento es completamente independiente.
Desventajas: Mayor coste de infraestructura. La complejidad de despliegue y migración crece linealmente con el número de tenants. La analítica entre tenants requiere capas de agregación.
Nuestro enfoque
Para la mayoría de productos en TitanGO Labs, usamos base de datos compartida con esquemas separados en PostgreSQL. Esto nos da un fuerte aislamiento de datos sin la sobrecarga operativa de gestionar cientos de instancias de base de datos separadas.
El soporte de esquemas de PostgreSQL es excelente — cada tenant obtiene su propio namespace, todas las consultas se limitan al esquema correcto mediante el search path, y el riesgo de fuga de datos entre tenants es mínimo cuando la arquitectura se configura correctamente.
Para productos con requisitos de cumplimiento estrictos (como EntryGO, que gestiona registros de jornada de empleados bajo la legislación laboral española), añadimos salvaguardas adicionales:
- Políticas de seguridad a nivel de fila (RLS) como medida de defensa en profundidad
- Registro de auditoría para todos los accesos y modificaciones de datos
- Testing automatizado que verifica el aislamiento de tenants en cada release
Límites de seguridad más allá de la base de datos
El aislamiento de datos no es solo un problema de base de datos. La seguridad multi-tenant requiere atención en cada capa:
- Autenticación — Cada usuario pertenece a exactamente un tenant. Los tokens JWT o datos de sesión deben incluir y validar el contexto del tenant.
- Autorización — Los roles y permisos tienen alcance por tenant. Un administrador de la Empresa A tiene cero acceso a la Empresa B.
- Almacenamiento de archivos — Los archivos subidos deben almacenarse en rutas o buckets con alcance por tenant. Los controles de acceso deben prevenir el acceso entre tenants.
- Endpoints de API — Cada llamada API debe validar que el usuario solicitante tiene acceso a los datos del tenant solicitado.
- Trabajos en segundo plano — Los workers asíncronos deben mantener el contexto del tenant. Un trabajo procesando datos de la Empresa A nunca debe escribir accidentalmente en las tablas de la Empresa B.
Consideraciones de escalabilidad
Los sistemas multi-tenant necesitan manejar carga desigual. Un tenant puede tener 10 usuarios, otro puede tener 10.000. Diseña para esto desde el principio:
- Pool de conexiones — Usa herramientas como PgBouncer para gestionar las conexiones de base de datos eficientemente entre tenants.
- Limitación de tasa — Previene que un tenant monopolice los recursos compartidos.
- Monitorización por tenant — Rastrea el rendimiento de consultas, uso de almacenamiento y volumen de llamadas API por tenant para identificar problemas temprano.
- Escalado horizontal — Diseña servidores de aplicación sin estado para poder añadir capacidad sin reestructurar.
La conclusión
La arquitectura multi-tenant no es algo que añades después. Necesita ser una decisión fundamental que influye en tu modelo de datos, sistema de autenticación, estrategia de despliegue y enfoque de testing.
Si estás construyendo un producto SaaS y necesitas ayuda con aislamiento de tenants, seguridad de datos o arquitectura de escalabilidad — contacta con TitanGO Labs. Esto es lo que construimos cada día.