---
term: 'Hosting Multi-Tenant en la Nube'
seoTitle: '¿Qué es el Hosting Multi-Tenant en la Nube? Guía Completa'
headline: '¿Qué es el Hosting Multi-Tenant en la Nube?'
slug: hosting-multi-tenant
category: cloud-architecture
shortDefinition: '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.'
relatedTerms:
- multi-tenant-database-architecture
- tenant-isolation
- infrastructure-as-a-service
- row-level-security
contrastsWith:
- multi-tenant-database-architecture
faq:
- question: '¿Qué es multi-tenancy en la computación en la nube?'
answer: '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.'
- question: '¿Cuál es la diferencia entre hosting multi-tenant y single-tenant?'
answer: '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.'
- question: '¿Es segura una nube multi-tenant?'
answer: '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.'
- question: '¿Qué es el problema del noisy neighbor (vecino ruidoso)?'
answer: '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.'
- question: '¿Cómo se mantienen separados los datos de cada tenant en una nube compartida?'
answer: '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.'
- question: '¿Multi-tenancy es lo mismo que virtualización?'
answer: '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.'
- question: '¿Cuándo deberías elegir single-tenant?'
answer: '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.'
- question: '¿Por qué importa multi-tenancy para el SaaS?'
answer: '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.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'The NIST Definition of Cloud Computing (SP 800-145)'
url: 'https://csrc.nist.gov/pubs/sp/800/145/final'
- name: 'Multitenancy (Wikipedia)'
url: 'https://en.wikipedia.org/wiki/Multitenancy'
- name: 'PostgreSQL Row Security Policies'
url: 'https://www.postgresql.org/docs/current/ddl-rowsecurity.html'
- name: 'Row-Level Security and Multi-Tenancy on MongoDB (Back4app Engineering)'
url: 'https://www.back4app.com/multi-tenant-mongodb-row-level-security'
cta:
title: 'Aislamiento de tenants sin la plomería'
text: 'Back4app impone el acceso por tenant en la capa de datos — ACLs en cada objeto, roles por tenant y permisos a nivel de clase — para que el aislamiento no dependa de que cada query recuerde un filtro. Levanta un backend multi-tenant en el plan gratuito.'
linkText: 'Empieza gratis'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: multi-tenant-cloud-hosting
---
**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:
```sql
-- 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](https://www.postgresql.org/docs/current/ddl-rowsecurity.html), 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:**
```javascript
// 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
// 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();
```
**Swift:**
```swift
// 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 }
```
**Kotlin:**
```kotlin
// 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:
```mermaid
flowchart LR
accTitle: Espectro de aislamiento de tenants
accDescr: Tres formas de despliegue, desde pool, donde todos los tenants comparten app y base de datos, pasando por bridge, con app compartida pero datos aislados, hasta silo, un stack dedicado por tenant.
A["Pool
todos los tenants comparten app + base de datos
(mayor densidad, menor costo)"] --> B["Bridge
app compartida, datos aislados
(esquema o base de datos por tenant)"]
B --> C["Silo
stack dedicado por tenant
(aislamiento más fuerte, costo más alto)"]
```
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](https://csrc.nist.gov/pubs/sp/800/145/final) 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:
1. **Cuotas y rate limiting por tenant** — limitar lo que cualquier tenant puede consumir por ventana.
2. **Planificación de recursos y autoscaling** — absorber los picos antes de que se conviertan en la latencia de otro.
3. **Separación de cargas de trabajo** — mover los jobs pesados (exports, analítica) a colas en segundo plano, fuera del camino de la solicitud.
4. **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](https://www.back4app.com/multi-tenant-mongodb-row-level-security) muestra el patrón completo sobre una base de datos de documentos — sin depender de la disciplina del WHERE.