El hosting multi-tenant en la nube es un modelo donde un conjunto de servidores y software atiende a muchos clientes, con aislamiento lógico entre tenants. Piensa en un edificio de departamentos: los inquilinos comparten la estructura, la plomería y la electricidad, pero cada puerta tiene su cerradura. La alternativa — el hosting single-tenant — es la casa propia: control total, renta más alta, y buena parte del mantenimiento corre por tu cuenta.
Puntos clave
| Pregunta | Respuesta |
|---|---|
| Qué es | Servidores y software compartidos, muchos clientes, datos separados lógicamente |
| Por qué existe | Compartir infraestructura es lo que hace posible el precio de la nube |
| La parte difícil | El aislamiento — un tenant jamás debe ver los datos ni sentir la carga de otro |
| vs. single-tenant | Más barato, onboarding más rápido, un solo ciclo de updates — a costa de la separación física |
| Dónde pertenece el aislamiento | A la capa de datos — no al WHERE de cada query |
Cómo se mantienen separados los datos de los tenants
Todo sistema multi-tenant responde una pregunta antes que las demás: ¿dónde vive el aislamiento? En la capa de base de datos hay tres patrones canónicos — esquema compartido, esquema por tenant y base de datos por tenant. El esquema compartido es el caballo de batalla, y es más seguro cuando la propia base de datos impone la frontera:
-- Patrón 1: esquema compartido — cada fila lleva su tenant
CREATE TABLE invoices (
id bigserial PRIMARY KEY,
tenant_id uuid NOT NULL,
amount numeric(10,2) NOT NULL
);
-- Impón el aislamiento en la base de datos, no en cada query
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.tenant_id')::uuid);Con una política a nivel de fila, la query que olvida su filtro de tenant devuelve nada en lugar de todo — el modo de falla pasa de fuga de datos a página vacía.
En un Backend as a Service, el mismo principio se expresa como control de acceso por objeto en lugar de políticas SQL. Cada registro lleva una ACL que nombra el role del tenant que puede verlo, y la plataforma la impone en cada solicitud:
// JavaScript / Node.js — Back4app JS SDK
const doc = new Parse.Object('Invoice');
doc.set('amount', 480);
const acl = new Parse.ACL();
acl.setPublicReadAccess(false); // invisible to every other tenant
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();// Flutter / Dart — Back4app Flutter SDK
final doc = ParseObject('Invoice')..set('amount', 480);
final acl = ParseACL();
acl.setPublicReadAccess(allowed: false);
acl.setRoleReadAccess('tenant-acme', true);
acl.setRoleWriteAccess('tenant-acme', true);
doc.setACL(acl);
await doc.save();// iOS / Swift — Back4app Swift SDK
var doc = Invoice()
doc.amount = 480
var acl = ParseACL()
acl.publicRead = false
acl.setReadAccess(roleName: "tenant-acme", value: true)
acl.setWriteAccess(roleName: "tenant-acme", value: true)
doc.ACL = acl
doc.save { _ in }// Android / Kotlin — Back4app Android SDK
val doc = ParseObject("Invoice").apply { put("amount", 480) }
val acl = ParseACL().apply {
publicReadAccess = false
setRoleReadAccess("tenant-acme", true)
setRoleWriteAccess("tenant-acme", true)
}
doc.acl = acl
doc.saveInBackground()El aislamiento es un espectro, no un interruptor
Entre “todo compartido” y “todo dedicado” están las tres formas de despliegue entre las que elige la mayoría de los sistemas reales:
Las plataformas maduras mezclan las tres: pool para los muchos tenants pequeños, bridge para los medianos, y silo para los pocos que son regulados, enormes o ruidosos. El error es tratar la elección como global — puede tomarse por plan, e incluso por componente.
Hosting multi-tenant vs. single-tenant
| Dimensión | Multi-tenant | Single-tenant |
|---|---|---|
| Costo por tenant | Bajo — la infraestructura se amortiza | Alto — stack dedicado por cliente |
| Aislamiento de datos | Lógico (políticas, ACLs, esquemas) | Físico (instancia y base de datos separadas) |
| Radio de daño | Un incidente puede tocar a muchos tenants | Contenido a un solo cliente |
| Noisy neighbors | Posibles; exigen cuotas y throttling | Ninguno — los recursos son privados |
| Upgrades | Un rollout actualiza a todos | Cada instancia se parcha por separado |
| Onboarding | Cambio de configuración, minutos | Aprovisionamiento, de horas a semanas |
| Personalización | Configuración y feature flags | Cambios profundos por instancia |
| Ajuste a compliance | Suficiente para la mayoría; fricción bajo regímenes estrictos | Preferido bajo mandatos de aislamiento estricto |
| Uso típico | SaaS, BaaS, plataformas de nube compartidas | Industrias reguladas, planes enterprise premium |
Dos sentidos que conviene separar
“Hosting multi-tenant en la nube” se usa en dos altitudes distintas, y la mayoría de las explicaciones las mezcla:
- Como nivel de hosting: hosting compartido — tu carga de trabajo corre en las mismas máquinas físicas que las de otros clientes. Es el modo por defecto de toda nube pública; la definición del NIST lista el pooling de recursos entre tenants como característica esencial de la propia computación en la nube.
- Como arquitectura de aplicación: tu propio producto atiende a sus clientes desde un backend compartido — la forma en que se construye el software por suscripción. Aquí el casero eres tú, y el aislamiento de tenants se vuelve tu responsabilidad, que es donde entran los patrones de arriba.
Los dos sentidos se componen: un producto SaaS (multi-tenancy a nivel de aplicación) normalmente corre sobre infraestructura de nube compartida (multi-tenancy a nivel de hosting), con cada capa aislando a sus propios tenants.
El problema del noisy neighbor
Compartir significa contención: el import masivo de un tenant puede hacer lento el checkout de otro. Las mitigaciones estándar, en orden de escalada:
- Cuotas y rate limiting por tenant — limitar lo que cualquier tenant puede consumir por ventana.
- Planificación de recursos y autoscaling — absorber los picos antes de que se conviertan en la latencia de otro.
- Separación de cargas de trabajo — mover los jobs pesados (exports, analítica) a colas en segundo plano, fuera del camino de la solicitud.
- Silo parcial — cuando un tenant corre caliente de forma consistente, darle al componente en disputa (normalmente la base de datos) su propia partición y dejar el resto en el pool.
Casos de uso comunes
- Productos SaaS. Toda app por suscripción que atiende a todos sus clientes desde un código base — el caso canónico, y la razón de que el patrón exista.
- BaaS y hosting de plataforma. Las plataformas corren miles de apps sobre infraestructura compartida y aislada, así que aprovisionar cada app cuesta casi cero — el modelo detrás de los planes gratuitos.
- Aplicaciones B2B con workspaces por tenant. Un despliegue, muchas organizaciones cliente, cada una con sus usuarios, roles y frontera de datos.
- Plataformas internas. Un despliegue de analítica o herramientas compartido entre departamentos, aislado por equipo.
- Agencias que corren muchas apps de clientes. Plataforma compartida por debajo, un backend aislado por cliente encima.
¿Multi-tenant, single-tenant o mixto? Matriz de decisión
| Elige multi-tenant cuando… | Elige single-tenant cuando… | Elige mixto cuando… |
|---|---|---|
| Atiendes a muchos clientes con un producto | La regulación o los contratos exigen aislamiento físico | La mayoría de los tenants es estándar, unos pocos son regulados |
| El costo por cliente debe acercarse a cero | El SLA de un cliente justifica capacidad dedicada | Un tenant es 100× más grande que la mediana |
| Quieres un solo ciclo de updates para todos | La personalización profunda por cliente es el producto | Necesitas un plan premium “dedicado” |
| El onboarding debe ser autoservicio e instantáneo | Los clientes se cuentan con una mano | Un tenant ruidoso necesita su propia base de datos |
Empieza multi-tenant por defecto y gánate la salida tenant por tenant — encajar tenancy después en un código base single-tenant es mucho más difícil que mover a un cliente caliente a un silo más tarde.
Limitaciones y trade-offs
- El aislamiento vale lo que vale su imposición. Un filtro de tenant olvidado en el código de la aplicación es la fuga cross-tenant clásica. Empuja la frontera hacia la capa de datos — políticas a nivel de fila, ACLs por objeto — para que la plataforma falle cerrada.
- Radio de daño compartido. Una caída, un mal deploy o una brecha pueden afectar a todos los tenants a la vez. Los rollouts por etapas y los backups por tenant encogen el daño, no lo compartido.
- Los noisy neighbors son estructurales. Las cuotas y la planificación administran la contención; solo el silo parcial la elimina, a precios de silo parcial.
- Techo de personalización. Los tenants comparten un código base, así que el comportamiento por tenant vive en configuración y feature flags — una restricción que los clientes single-tenant no tienen.
- Contexto de tenant en todas partes. Cada query, clave de caché, job y línea de log necesita conocer al tenant; la complejidad migra de la infraestructura a la aplicación — exactamente la carga que el aislamiento gestionado en la capa de datos existe para absorber.
Hosting multi-tenant en Back4app
Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Es multi-tenant en las dos altitudes. Como plataforma, corre miles de backends de app aislados sobre infraestructura compartida — por eso un backend nuevo se aprovisiona en minutos en un plan gratuito. Para los tenants de tu aplicación, el aislamiento es una función de la capa de datos y no una convención: cada objeto lleva una ACL, los roles agrupan usuarios por tenant, y los permisos a nivel de clase fijan reglas para todo el esquema, todo impuesto por Back4app en cada solicitud. El análisis de ingeniería sobre row-level security muestra el patrón completo sobre una base de datos de documentos — sin depender de la disciplina del WHERE.
Preguntas frecuentes
¿Qué es multi-tenancy en la computación en la nube?
Es la arquitectura en la que una sola instancia de software — y la infraestructura debajo de ella — atiende a varios clientes, llamados tenants. Los tenants comparten cómputo, almacenamiento y un mismo código base, pero los datos de cada uno quedan lógicamente aislados e invisibles para los demás. Es el patrón que hace que la economía de la nube funcione: agregar un cliente es un cambio de configuración, no hardware nuevo.
¿Cuál es la diferencia entre hosting multi-tenant y single-tenant?
Single-tenant le da a cada cliente una instancia y una base de datos dedicadas — control máximo y aislamiento físico, a un precio mayor, con cada instancia parchada y actualizada por separado. Multi-tenant comparte una instancia entre todos los clientes — menor costo por tenant, un solo ciclo de updates para todos, y aislamiento impuesto de forma lógica en lugar de física. La mayoría del SaaS corre multi-tenant; los clientes regulados o muy grandes a veces justifican single-tenant.
¿Es segura una nube multi-tenant?
Sí, cuando el aislamiento se impone correctamente — un tenant no puede ver los datos de otro. Los riesgos residuales son bugs de aplicación que se saltan un filtro de tenant y el mayor radio de daño de un sistema compartido: una brecha o una caída puede tocar a todos los tenants. Por eso los diseños más sólidos empujan el aislamiento hacia la capa de datos — políticas a nivel de fila y control de acceso por objeto — en lugar de confiar en que cada query recuerde su cláusula WHERE.
¿Qué es el problema del noisy neighbor (vecino ruidoso)?
Es cuando el uso intensivo de CPU, memoria o I/O compartidos por parte de un tenant degrada el rendimiento de todos los demás en la misma infraestructura. Las mitigaciones incluyen cuotas y rate limiting por tenant, planificación de recursos, autoscaling y — cuando un tenant corre caliente de forma consistente — particionar el componente en disputa, normalmente la base de datos, en un silo propio.
¿Cómo se mantienen separados los datos de cada tenant en una nube compartida?
En la capa de base de datos hay tres patrones canónicos: un esquema compartido donde cada fila lleva un identificador de tenant (mayor densidad, normalmente acompañado de row-level security), un esquema por tenant en una base compartida, y una base de datos por tenant (aislamiento más fuerte, costo más alto). Por debajo, la infraestructura suma sus propias capas: máquinas virtuales, namespaces de contenedor y micro-VMs mantienen separadas las cargas de trabajo de los tenants.
¿Multi-tenancy es lo mismo que virtualización?
No. La virtualización divide una máquina física en máquinas virtuales aisladas; multi-tenancy comparte una instancia de aplicación entre muchos clientes. Son complementarias — la virtualización es uno de los mecanismos que los proveedores usan para aislar las cargas de los tenants, mientras que multi-tenancy es el patrón arquitectónico que decide qué se comparte en primer lugar.
¿Cuándo deberías elegir single-tenant?
Cuando regímenes regulatorios estrictos o contratos exigen aislamiento físico o residencia de datos, cuando un cliente necesita personalización profunda por instancia, o cuando el rendimiento garantizado de una cuenta valiosa compensa el costo. La respuesta cada vez más común es la tenancy mixta: agrupar a la mayoría de los tenants en infraestructura compartida y aislar en silos a los pocos que son regulados, enormes o ruidosos.
¿Por qué importa multi-tenancy para el SaaS?
Es la arquitectura sobre la que se construye el software por suscripción. Un código base atiende a todos los clientes, así que las correcciones y las funciones llegan a todos los tenants a la vez; la utilización del hardware se reparte entre la base de clientes; y el onboarding de un cliente nuevo cuesta casi nada. Sin multi-tenancy, cada suscripción cargaría con el precio de servidores dedicados y mantenimiento por cliente.