SaaS multi tenant: qué es y cómo se aíslan los datos
En un SaaS multi tenant muchos clientes comparten aplicación y base de datos, y cada uno ve solo lo suyo. Es más barato de operar que single tenant, pero exige aislar los datos: mejor si lo impone la propia base de datos por fila y lo comprueban pruebas que intentan leer datos ajenos.
Un SaaS multi tenant es una aplicación en la que muchos clientes (tenants) comparten el mismo software y, normalmente, la misma base de datos, pero cada uno ve solo sus datos. Frente al single tenant, con una instalación por cliente, es más barato de operar y de actualizar, pero exige un aislamiento de datos impecable.
Qué significa SaaS multi tenant
Tenant significa inquilino, y la comparación funciona: un edificio de pisos frente a una urbanización de chalés. En el edificio, la estructura, el ascensor y las tuberías son comunes, y cada vecino tiene su llave. En la urbanización, cada casa tiene sus propios cimientos.
En software, multi tenant quiere decir que una sola aplicación, en una sola versión, atiende a todos los clientes. Cuando publicas una mejora, les llega a todos a la vez. Cada dato lleva la marca de su cliente, y el sistema tiene que impedir que nadie cruce esa frontera, ni por un descuido del código ni por la curiosidad de un usuario.
Multi tenant vs single tenant
| Aspecto | Multi tenant | Single tenant |
|---|---|---|
| Infraestructura | Compartida por todos los clientes | Una instalación por cliente |
| Coste de operación | Menor: se mantiene una sola plataforma | Mayor: cada instalación se opera aparte |
| Actualizaciones | Una publicación llega a todos | Cliente a cliente, a su ritmo |
| Personalización | Por configuración, dentro de lo que permite el producto | Puede llegar al código de ese cliente |
| Aislamiento | Lógico: lo imponen la aplicación y la base de datos | Físico: sistemas separados |
| Riesgo típico | Un filtro que falla expone datos de otro cliente | Versiones distintas, caras de mantener al día |
| Rendimiento | Un cliente muy activo puede afectar a los demás («vecino ruidoso») | Cada cliente con sus recursos |
Single tenant tiene sentido con clientes grandes que exigen por contrato separación física, con personalizaciones profundas o con volúmenes que justifican una instalación propia. Para un producto con muchos clientes pequeños y medianos, lo razonable suele ser multi tenant, siempre que el aislamiento esté bien resuelto.
El «vecino ruidoso» también tiene solución dentro del modelo compartido: límites de uso por cliente, colas que reparten el trabajo pesado de forma equitativa y avisos cuando un cliente consume muy por encima de lo normal.
Tres formas de aislar los datos
| Modelo | Cómo es | Ventaja | Inconveniente |
|---|---|---|---|
| Base de datos por cliente | Cada cliente tiene su propia base | Aislamiento fuerte; copia y restauración por cliente | Muchas bases que migrar y vigilar; se encarece con muchos clientes |
| Esquema por cliente | Una base, con un juego de tablas por cliente | Separación clara dentro de una misma base | Cada cambio de estructura se repite en cada esquema |
| Tablas compartidas con columna de cliente | Todas las filas en las mismas tablas, marcadas con su cliente | Lo más sencillo de operar y de hacer evolucionar | Todo depende de que el filtro se aplique siempre |
Los tres son válidos. El tercero es el más sencillo de operar cuando hay muchos clientes y, a la vez, el que más disciplina exige, porque la seguridad de todos depende de un filtro. De ahí la siguiente sección.
Cómo se aíslan los datos por fila en la base de datos
En el modelo de tablas compartidas, cada fila lleva el identificador de su cliente. La pregunta clave es quién aplica el filtro:
- Solo la aplicación. Cada consulta añade «y, además, de este cliente». Funciona mientras nadie lo olvide en ningún listado, exportación, informe ni tarea en segundo plano.
- También la base de datos. Además del código, la base impone una política por fila. Varios motores lo ofrecen: PostgreSQL lo llama políticas de seguridad de fila (row security policies) y SQL Server, seguridad de nivel de fila. Deciden qué filas puede ver o modificar cada consulta según quién la hace.
La segunda opción cambia el tipo de fallo. Según la documentación de PostgreSQL, con la seguridad por fila activada y sin ninguna política que dé acceso, no se ve ni se modifica ninguna fila. Si el código olvida el filtro, la base sigue devolviendo solo las filas del cliente de la sesión; y si lo que falta es el propio contexto de cliente, con una política bien escrita el resultado es una pantalla vacía que alguien reporta, no una fuga que nadie ve.
Tomando PostgreSQL como ejemplo, la idea cabe en dos órdenes. Es un ejemplo simplificado para entender el mecanismo, no un código para copiar tal cual:
ALTER TABLE facturas ENABLE ROW LEVEL SECURITY;
CREATE POLICY solo_su_cliente ON facturas USING (cliente_id = NULLIF(current_setting('app.cliente_id', true), '')::int);
La primera activa la protección en la tabla; la segunda dice que una factura solo es visible si su cliente coincide con el de la sesión. La aplicación, al atender cada petición, le indica a la base para qué cliente está trabajando. El true y el NULLIF hacen que, si la sesión no indica cliente, el valor sea nulo y no encaje con ninguna fila, en lugar de dar un error.
Dos trampas técnicas
- Quién se salta la política. La documentación de PostgreSQL advierte de que los superusuarios y los roles con el atributo BYPASSRLS se la saltan siempre, y el propietario de la tabla normalmente también, salvo que se active FORCE ROW LEVEL SECURITY. Si la aplicación se conecta con uno de esos roles, la protección existe en el papel y no en la práctica, y las pruebas pasan por el motivo equivocado.
- El contexto de cliente. La base necesita saber para qué cliente es cada consulta. Si una tarea programada no lo indica, con una política como la del ejemplo verá cero filas en lugar de dar un error: el fallo es silencioso y hay que vigilarlo con pruebas y comprobando el número de filas afectadas.
Pruebas que intentan leer datos ajenos y deben fallar
Un aislamiento que no se prueba es una suposición. La prueba útil es adversarial: se hace pasar por un cliente e intenta, a propósito, llegar a lo de otro.
- Crea dos clientes de prueba, A y B, con datos de cada tipo.
- Entra como A y pide por su identificador un registro de B: una ficha, una factura, un documento.
- Intenta modificarlo o borrarlo: el cambio debe afectar a cero filas.
- Recorre listados, búsquedas, exportaciones, informes y ficheros descargables: nada de B debe aparecer.
- Repite con cada rol, porque un permiso mal puesto puede abrir lo que el aislamiento cerraba.
- Ejecuta todo en cada entrega, no una vez al principio.
El resultado correcto es un fallo: un «no encontrado», un «sin permiso» o una lista vacía. Si la prueba consigue leer datos de B, el que ha fallado es el sistema. No es un riesgo exótico: el control de acceso roto encabeza el OWASP Top 10 de 2025. En nuestros productos, los datos de cada cliente están aislados en la propia base de datos, por fila, con pruebas que intentan leer datos ajenos y deben fallar.
Si parte del código lo escribe una IA, estas pruebas importan todavía más: un asistente genera listados que funcionan de maravilla con un único cliente de prueba. Lo contamos en crear un SaaS con IA.
Errores típicos en un SaaS multi tenant
- Identificadores consecutivos sin comprobar el dueño: cambiar un número en la dirección y ver la factura de otro.
- Exportaciones e informes escritos aparte que olvidan el filtro.
- Tareas programadas y colas que trabajan sin contexto de cliente.
- Cachés compartidas que sirven a un cliente la respuesta preparada para otro.
- Ficheros subidos con rutas adivinables y sin comprobación de permisos.
- Accesos de soporte a la cuenta de un cliente que no dejan rastro.
InmoCenter, Entrenify, isoMenú y XBarber son nuestros productos propios, y en ellos hemos construido las piezas de un SaaS multi tenant: alta autoservicio, planes, cobro con tarjeta y datos aislados por cliente. El resto de piezas de un SaaS, del alta al cobro, están en cómo crear un SaaS desde cero, y lo que construimos, en desarrollo de SaaS.
Fuentes consultadas
Comprobadas el 26 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
- PostgreSQL Documentation: Row Security Policies. PostgreSQL Global Development Group.
- Seguridad de nivel de fila (SQL Server). Microsoft Learn.
- PostgreSQL Documentation: System Administration Functions (current_setting). PostgreSQL Global Development Group.
- OWASP Top 10:2025 · A01 Broken Access Control. OWASP.
- PostgreSQL Documentation: Conditional Expressions (NULLIF). PostgreSQL Global Development Group.
- PostgreSQL Documentation: CREATE POLICY. PostgreSQL Global Development Group.
Preguntas frecuentes
¿Qué es un tenant en un SaaS?
Cada cliente que usa la plataforma con su propio espacio: una empresa con sus usuarios, sus datos y su configuración. No es cada persona que entra, sino cada organización que contrata.
¿Es menos seguro un SaaS multi tenant que uno single tenant?
No por definición. Tiene un riesgo concreto, que un filtro que falla exponga datos de otro cliente, y se controla con aislamiento en la base de datos y pruebas adversariales. Un single tenant mal mantenido, con versiones sin actualizar, también es inseguro.
¿Qué diferencia hay entre multi tenant y multi instancia?
En multi instancia cada cliente tiene su propia copia de la aplicación, normalmente desplegada de forma automatizada. Da un aislamiento físico parecido al single tenant, pero cuesta más infraestructura y cada actualización hay que aplicarla instancia a instancia.
¿Se puede pasar de single tenant a multi tenant más adelante?
Se puede, pero es una migración delicada: marcar cada dato con su cliente, unir bases, revisar todas las consultas y probar el aislamiento con datos reales. Si tu idea es un producto con muchos clientes, conviene decidirlo al principio.
¿Puede cada cliente tener su propia configuración en un multi tenant?
Sí, por configuración: módulos que se activan, planes, interruptores, textos y campos propios. Lo que no conviene es mantener código distinto por cliente, porque se pierde la ventaja de una sola versión para todos.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.