Arquitectura multi-tenant para SaaS: hacerlo bien a la primera

El error arquitectónico más caro en SaaS es construir un sistema single-tenant y tratar de convertirlo en multi-tenant después. Hemos visto ese rewrite tomar de 6 a 12 meses y costar más que el desarrollo original del producto. Es el tipo de deuda técnica que no se acumula gradualmente: llega toda de golpe cuando tu primer cliente enterprise pregunta: "¿Cómo está aislada nuestra data de la de otros tenants?"

Si estás construyendo un producto B2B SaaS, la multi-tenancy tiene que estar diseñada desde el primer commit. Aquí va qué significa eso en la práctica.

Modelos de multi-tenancy

Hay tres enfoques principales de multi-tenancy, cada uno con trade-offs distintos:

Base de datos compartida, schema compartido. Todos los tenants comparten la misma base y las mismas tablas, con una columna tenant_id que distingue la data. Es el más simple de construir y el más eficiente de operar. Es la opción correcta para la mayoría de los productos SaaS.

Fortalezas: arquitectura más simple, costo de infraestructura más bajo, más fácil desplegar updates. Limitaciones: el aislamiento de tenant es lógico (no físico), el desempeño de un tenant puede afectar a otros (problema de "noisy neighbor") y algunos clientes enterprise pueden no aceptar aislamiento shared-schema.

Base de datos compartida, schemas separados. Cada tenant recibe su propio schema dentro de la misma base. Ofrece mejor aislamiento que shared-schema y aun así comparte infraestructura.

Fortalezas: mejor aislamiento que shared-schema, más fácil cumplir con requisitos de residencia de datos y permite customización por tenant. Limitaciones: migraciones más complejas, mayor overhead operacional y el connection pooling se vuelve más complicado.

Bases de datos separadas. Cada tenant recibe su propia base. Aislamiento máximo, pero complejidad y costo máximos.

Fortalezas: el aislamiento más fuerte, cumplimiento de residencia de datos más fácil y elimina problemas de noisy neighbor. Limitaciones: el costo de infraestructura más alto, el proceso de despliegue y migración más complejo y lo más difícil de mantener consistencia entre tenants.

Nuestra recomendación para la mayoría de las empresas SaaS

Empieza con base de datos compartida y schema compartido, con row-level security y filtrado por tenant en la capa de aplicación. Esto cubre el 80% de los casos de uso B2B SaaS. Si clientes enterprise específicos exigen aislamiento más fuerte, implementa schemas separados para esos tenants y mantén el resto en el modelo compartido.

Los detalles de implementación clave:

Row-level security. Cada query a base de datos tiene que filtrar por tenant_id. Esto no es solo responsabilidad de la aplicación: impleméntalo a nivel de base de datos usando las políticas de row-level security de PostgreSQL. Esto previene fugas de datos aun si el código de aplicación tiene un bug.

Middleware en la capa de aplicación. Cada request de API tiene que resolver el contexto de tenant (desde el token de autenticación, el subdominio o un header) y adjuntarlo al contexto del request. Cada query a base de datos tiene que usar ese contexto para filtrar resultados.

Testing. Los bugs de multi-tenancy son el peor tipo de bug SaaS: fugan data de un cliente a otro cliente. Las pruebas automatizadas tienen que verificar específicamente el aislamiento de tenant: crear data en el tenant A, consultar como tenant B, confirmar que no hay fugas.

La migración que nadie quiere hacer

Si ya construiste un sistema single-tenant, la migración a multi-tenant es posible pero cara. Típicamente implica agregar tenant_id a cada tabla, actualizar cada query, implementar row-level security, actualizar todos los endpoints de API y migrar la data existente de clientes. Presupuesta de 3 a 6 meses para un producto pequeño, y de 6 a 12 meses para uno complejo.

Por eso hacerlo bien a la primera importa. Las 2 o 3 semanas de esfuerzo adicional para implementar multi-tenancy desde el inicio ahorran meses de rewrite después, y evitan el golpe a la velocidad de ingeniería que viene con una migración arquitectónica mayor.

Relacionados: Guía de desarrollo MVP SaaS → · Construyendo para industrias reguladas → · Nuestra práctica Build →