Multi-tenancy en SaaS: modelos y cuándo usarlos

Estás construyendo un SaaS y, tarde o temprano, aparece la pregunta que decide media arquitectura: ¿cómo separas los datos de un cliente de los del resto? Todos tus clientes viven en el mismo sistema, pero ninguno puede ver ni rozar la información de otro. Cómo resuelvas eso —lo que se llama multi-tenancy— condiciona tu coste de infraestructura, tu seguridad, tu velocidad para crecer y hasta qué clientes vas a poder vender.

Lo tratamos por encima en nuestra guía de desarrollo de SaaS; aquí le damos su sitio. En esta guía te contamos qué modelos de multi-tenancy existen, los escenarios reales donde elegimos cada uno y los errores que le cuestan caros a un producto cuando el aislamiento se decide tarde.

Qué significa realmente multi-tenancy

Multi-tenancy es servir a muchos clientes (tenants) desde una sola aplicación sin montar una copia del sistema por cada uno. Lo contrario —una instalación separada por cliente— es fácil de entender y carísimo de mantener: cada actualización se multiplica por el número de clientes y el negocio no escala.

En la práctica, casi todo se reduce a tres modelos de aislamiento de datos, de más separado a más compartido:

• Silo: una base de datos (o una instancia) por cliente. Aislamiento máximo, el más fácil de explicar a un cliente exigente y el más caro de operar y actualizar.
• Bridge: una base de datos compartida con un schema por cliente. Un punto intermedio razonable, aunque gestionar cientos de schemas y sus migraciones tiene su propio coste.
• Pool: todos los clientes en las mismas tablas, separados por una columna tenant_id. Máxima densidad y el más barato de escalar, pero el aislamiento depende al 100% de que tu código —y tu base de datos— nunca se equivoquen de tenant.

La elección no es ideológica: depende de tu sector, de tus obligaciones de cumplimiento, del tamaño de tus clientes y de a qué velocidad esperas crecer.

Escenarios reales que nos encontramos

El SaaS que arranca: pool con tenant_id

Para la mayoría de productos que empiezan, el modelo pool es la decisión correcta: barato, denso y rápido de construir. El trabajo fino no es el modelo, es blindarlo. Aquí apoyamos el aislamiento en la propia base de datos con seguridad a nivel de fila (row-level security), de modo que “olvidarse el tenant_id” en una consulta no exponga datos de otro cliente. El aislamiento no puede depender solo de que el desarrollador se acuerde.

El cliente enterprise que exige su propio aislamiento

Llega un cliente grande y su equipo de seguridad pone una condición: sus datos no comparten base de datos con nadie. Si tu arquitectura es pool puro y no habías previsto esto, promover a ese cliente a un silo puede ser un mini-proyecto. Por eso diseñamos la frontera del tenant para poder mover clientes concretos a un aislamiento mayor sin reescribir la aplicación.

El sector regulado: salud, fintech y residencia del dato

En salud o en fintech, el aislamiento y la residencia del dato no son una preferencia comercial: son un requisito. A veces obligan a un silo por cliente o incluso a alojar ciertos tenants en una región concreta. Estas restricciones hay que conocerlas antes de elegir el modelo, no descubrirlas cuando el contrato ya está firmado.

El “vecino ruidoso” que tumba a todos

En un modelo compartido, un solo cliente que dispara consultas pesadas o procesa un volumen enorme puede degradar el rendimiento de todos los demás. Es el problema del vecino ruidoso. Se gestiona con límites por tenant, colas y aislamiento de recursos para los clientes grandes, pero hay que diseñarlo a propósito: no se arregla solo.

Cómo lo abordamos

Después de construir varios SaaS multi-tenant, el orden que seguimos ahorra los refactors más caros.

tenant_id desde el día uno, aunque empieces en pool

Aunque arranques con el modelo más simple, el concepto de tenant está presente en el modelo de datos desde la primera tabla. Añadir el aislamiento cuando ya tienes clientes en producción es de los refactors más peligrosos que existen; dejar el hueco correcto al principio cuesta muy poco.

El aislamiento vive en la base de datos, no solo en el código

Confiar el aislamiento únicamente a que cada consulta filtre bien por cliente es frágil: basta un endpoint despistado para filtrar datos entre tenants. Por eso lo reforzamos en la capa de datos (row-level security, políticas por tenant), para que el aislamiento no dependa de que nadie cometa un error.

Diseñar para poder promover clientes de pool a silo

La arquitectura que preferimos empieza en pool y permite mover un cliente concreto a su propio schema o a su propia base de datos cuando el negocio lo pide, sin reescribir el producto. Así no pagas el coste del silo para todos desde el día uno, pero puedes ofrecerlo cuando un cliente grande lo exige.

Migraciones y operación pensadas para muchos tenants

Con muchos clientes, una migración de base de datos deja de ser trivial: hay que poder aplicarla de forma segura y repetible sobre todos los tenants, con marcha atrás. La operación de un SaaS multi-tenant —migrar, hacer backup, restaurar un solo cliente— se diseña, no se improvisa.

Errores que conviene evitar

• Dejar el aislamiento para “cuando haga falta”. Meter multi-tenancy después, con clientes en producción, es uno de los refactors más caros y arriesgados que hay.
• Fiar el aislamiento solo al código de aplicación. Un único endpoint que se olvide del tenant_id filtra datos entre clientes. Refuérzalo en la base de datos.
• Elegir silo por defecto “por seguridad”. Una base de datos por cliente desde el día uno multiplica tu coste y tu operación sin que la mayoría de clientes lo pidan.
• Ignorar al vecino ruidoso. Sin límites por tenant, un solo cliente pesado degrada la experiencia de todos los demás.
• Olvidar las migraciones multi-tenant. Lo que es fácil con una base de datos se vuelve un problema serio cuando son cientos y no lo diseñaste.

Cómo elegir equipo para tu SaaS multi-tenant

El modelo de multi-tenancy es una de esas decisiones tempranas que el negocio paga durante años. Al elegir con quién construirlo, fíjate en que te pregunten por tu sector y tus obligaciones de cumplimiento antes de proponer un modelo, que te expliquen cómo van a reforzar el aislamiento en la base de datos y no solo en el código, y que dejen la puerta abierta a aislar a los clientes que lo exijan sin reescribir el producto. Un buen equipo no elige el modelo de moda: elige el que encaja con tu negocio y tu forma de crecer.

En LMNHUB construimos SaaS multi-tenant como lo que son: un proyecto de ingeniería sobre tu negocio. Decidimos el modelo de aislamiento con tu sector delante, lo reforzamos en la capa de datos y lo dejamos preparado para escalar y para el equipo senior de startups que lo va a mantener.

Si estás diseñando tu SaaS o te has encontrado con un cliente que exige más aislamiento del que tienes, cuéntanos tu caso y te respondemos con un plan concreto y un equipo senior, sin humo ni un presupuesto genérico.