Multi-Tenant vs Single-Tenant | Eligiendo la Arquitectura SaaS Correcta

Todo producto SaaS necesita responder una pregunta fundamental: ¿cómo sirves a múltiples clientes desde el mismo software? La respuesta es tu modelo de tenencia. Afecta al coste, la seguridad, el rendimiento y la velocidad a la que puedes lanzar. Acertar desde el principio te ahorra migraciones dolorosas después.

Definiciones

Multi-tenant

Una instancia de la aplicación sirve a todos los clientes. Todos comparten los mismos servidores, el mismo código y a menudo la misma base de datos. Los datos de cada cliente están lógicamente aislados, pero la infraestructura es compartida.

Piénsalo como un edificio de apartamentos. Cada inquilino vive en el mismo edificio, comparte el ascensor y los pasillos, pero tiene su propia unidad cerrada con sus propios muebles.

Single-tenant

Cada cliente obtiene su propia instancia dedicada de la aplicación. Servidores separados, bases de datos separadas, a veces códigos separados. Nada se comparte entre clientes.

Piénsalo como casas independientes. Cada inquilino tiene su propio edificio, su propia fontanería, su propio jardín. Aislamiento completo, pero más caro de mantener.

Cómo Funciona la Multi-Tenencia

Hay tres enfoques comunes para la arquitectura multi-tenant, cada uno con diferentes compromisos.

Modelo 1: Aplicación compartida, base de datos compartida

Todos los tenants comparten una única instancia de aplicación y una única base de datos. Los datos de los tenants se separan usando un identificador de tenant (normalmente una columna tenant_id) en cada tabla.

Arquitectura:

• Un servidor de aplicación (o cluster) maneja todas las solicitudes.
• Una base de datos almacena todos los datos de los tenants.
• Cada consulta incluye una cláusula WHERE tenant_id = ? para limitar los datos al tenant correcto.

Ventajas:

• Menor coste de infraestructura. Una base de datos, un despliegue de app.
• Lo más simple de desplegar y actualizar. Despliega una vez, todos obtienen el cambio.
• Fácil de agregar datos entre tenants para analítica e informes.

Desventajas:

• Mayor riesgo de filtración de datos si una consulta olvida el filtro de tenant.
• Un tenant ruidoso puede degradar el rendimiento para todos.
• Las migraciones de base de datos afectan a todos los tenants simultáneamente.
• Lo más difícil para cumplir con regulaciones de residencia de datos.

Este es el enfoque más común para productos SaaS B2B con un gran número de clientes pequeños a medianos.

Modelo 2: Aplicación compartida, bases de datos separadas

Todos los tenants comparten la misma instancia de aplicación, pero cada tenant obtiene su propia base de datos. La aplicación enruta las consultas a la base de datos correcta basándose en el tenant autenticado.

Arquitectura:

• Un servidor de aplicación (o cluster) maneja todas las solicitudes.
• Una base de datos separada para cada tenant.
• Una capa de enrutamiento mapea la identidad del tenant a la conexión de base de datos correcta.

Ventajas:

• Aislamiento de datos más fuerte. Sin riesgo de consultas cruzadas entre tenants.
• Más fácil cumplir requisitos de residencia de datos. Puedes ubicar cada base de datos en la región requerida por el tenant.
• El backup y restauración por tenant es sencillo.
• El uso pesado de un tenant no bloqueará las tablas de otros tenants.

Desventajas:

• Más infraestructura que gestionar. Cientos de tenants significa cientos de bases de datos.
• Las migraciones de esquema deben aplicarse a cada base de datos individualmente.
• Los informes cruzados entre tenants requieren consultar múltiples bases de datos.
• Mayor coste que un modelo totalmente compartido.

Este es un punto medio sólido para productos que necesitan mejor aislamiento sin el coste de single-tenancy completa.

Modelo 3: Aplicación separada, base de datos separada

Cada tenant obtiene su propia instancia de aplicación y su propia base de datos. Totalmente aislado. Esto es esencialmente single-tenancy, pero gestionada por el proveedor SaaS en lugar del cliente.

Arquitectura:

• Un despliegue de aplicación dedicado por tenant.
• Una base de datos dedicada por tenant.
• Una capa de enrutamiento (a menudo un load balancer o API gateway) dirige el tráfico a la instancia correcta.

Ventajas:

• Aislamiento completo. Sin recursos compartidos entre tenants.
• Máxima flexibilidad para personalización por tenant.
• El rendimiento de un tenant nunca afecta a otro.
• La historia de cumplimiento más simple.

Desventajas:

• El mayor coste de infraestructura con diferencia.
• La complejidad de despliegue crece linealmente con el número de tenants.
• Las actualizaciones deben desplegarse a cada instancia individualmente (o automatizarse muy cuidadosamente).
• No escala económicamente para grandes números de tenants pequeños.

Este modelo tiene sentido para SaaS enterprise donde los clientes exigen infraestructura dedicada y están dispuestos a pagar un premium por ello.

Ventajas y Desventajas de un Vistazo

Factor	Multi-Tenant (BD Compartida)	Multi-Tenant (BD Separada)	Single-Tenant
Coste de infraestructura	Menor	Medio	Mayor
Aislamiento de datos	Lógico (nivel de fila)	Físico (nivel de BD)	Completo
Complejidad de despliegue	Baja	Media	Alta
Velocidad de actualización	Instantánea para todos	App instantánea, migraciones por BD	Despliegue por instancia
Personalización	Limitada	Limitada	Completa
Cumplimiento	Más difícil	Moderado	Más fácil
Escalabilidad (número de tenants)	Excelente	Buena	Pobre
Riesgo de vecino ruidoso	Alto	Medio	Ninguno

Aislamiento de Datos y Seguridad

El aislamiento de datos es la consideración más importante en cualquier modelo de tenencia. Una brecha de seguridad donde un tenant puede acceder a los datos de otro tenant es catastrófica para un negocio SaaS. Puede destruir la confianza, violar regulaciones y terminar con la empresa.

Row-level security

En un modelo de base de datos compartida, el Row-Level Security (RLS) de PostgreSQL es una de las defensas más fuertes contra la filtración de datos. RLS aplica el aislamiento de tenants a nivel de base de datos, no a nivel de aplicación. Incluso si tu código de aplicación tiene un bug que olvida filtrar por tenant, la propia base de datos previene el acceso cruzado entre tenants.

Así es cómo configurarlo:

-- Enable RLS on a table
ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

-- Create a policy that restricts access to the current tenant
CREATE POLICY tenant_isolation ON projects
  USING (tenant_id = current_setting('app.current_tenant_id')::uuid);

-- Force RLS even for table owners
ALTER TABLE projects FORCE ROW LEVEL SECURITY;

Antes de ejecutar cualquier consulta, establece el contexto del tenant:

-- Set at the beginning of each request/transaction
SET LOCAL app.current_tenant_id = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';

-- Now this query automatically returns only the current tenant's data
SELECT * FROM projects;
-- No WHERE clause needed. RLS handles it.

Aislamiento a nivel de aplicación

Además de la seguridad a nivel de base de datos, tu aplicación debe aplicar los límites del tenant:

// Middleware that sets tenant context on every request
async function tenantMiddleware(req: Request, res: Response, next: NextFunction) {
  const tenantId = extractTenantId(req); // From JWT, subdomain, or header

  if (!tenantId) {
    return res.status(401).json({ error: "Tenant not identified" });
  }

  // Set tenant context for the database connection
  await db.raw(`SET LOCAL app.current_tenant_id = '${tenantId}'`);

  req.tenantId = tenantId;
  next();
}

La defensa en profundidad es el principio aquí. Nunca dependas de una sola capa de aislamiento. Combina filtrado a nivel de aplicación, seguridad a nivel de base de datos y auditorías de seguridad regulares.

Consideraciones de Rendimiento

Desafíos de base de datos compartida

En una base de datos compartida, todos los tenants compiten por los mismos recursos. Un tenant ejecutando un informe pesado puede ralentizar las consultas para todos los demás. Las mitigaciones incluyen:

• Connection pooling. Usa PgBouncer o una herramienta similar para prevenir que un tenant agote las conexiones de base de datos.
• Timeouts de consulta. Establece tiempos máximos de ejecución para que una consulta descontrolada no pueda bloquear recursos indefinidamente.
• Rate limiting. Aplica límites por tenant en solicitudes API y operaciones de base de datos.
• Read replicas. Enruta operaciones de lectura pesadas (informes, exportaciones) a una réplica para que no afecten a la base de datos principal.

Ventajas de bases de datos separadas

Con bases de datos por tenant, el aislamiento de rendimiento viene incorporado. La carga pesada de un tenant solo afecta a su propia base de datos. También puedes provisionar bases de datos más grandes o más pequeñas según el plan y uso de cada tenant.

El compromiso es la sobrecarga de gestión. Monitorizar 500 bases de datos es más difícil que monitorizar una. El tooling automatizado se vuelve esencial.

Implicaciones de Coste a Escala

Veamos algunos números aproximados. Asume que tienes 100 tenants.

Base de datos compartida (multi-tenant):

• 1 cluster de aplicación: ~200 euros/mes
• 1 instancia PostgreSQL gestionada: ~100 euros/mes
• Total: ~300 euros/mes (3 euros por tenant)

Bases de datos separadas (multi-tenant):

• 1 cluster de aplicación: ~200 euros/mes
• 100 instancias de base de datos pequeñas: ~2.000 euros/mes
• Total: ~2.200 euros/mes (22 euros por tenant)

Single-tenant:

• 100 instancias de aplicación: ~5.000 euros/mes
• 100 instancias de base de datos: ~2.000 euros/mes
• Total: ~7.000 euros/mes (70 euros por tenant)

Estos números son simplificados, pero el patrón se mantiene. La infraestructura compartida es drásticamente más barata. Con 1.000 tenants, la brecha se amplía aún más.

Por eso los precios deben alinearse con la arquitectura. Si cobras 20 euros al mes y ejecutas infraestructura single-tenant a 70 euros por tenant, pierdes dinero en cada cliente.

Cuándo Elegir Multi-Tenant

La arquitectura multi-tenant es la elección correcta cuando:

• Estás construyendo SaaS B2B para SMBs. Alto volumen, precios más bajos y conjuntos de funcionalidades estándar.
• La eficiencia de costes importa. Necesitas mantener los costes de infraestructura bajos en relación con los ingresos.
• Quieres actualizaciones rápidas y uniformes. Despliega una vez, todos los tenants obtienen la mejora.
• Tus clientes no requieren infraestructura dedicada. La mayoría de pequeñas y medianas empresas no les importa dónde viven sus datos, siempre que estén seguros.
• Estás en las fases iniciales. Empieza multi-tenant. Es más barato y más simple. Siempre puedes ofrecer single-tenant después para clientes enterprise.

Cuándo Elegir Single-Tenant

La arquitectura single-tenant tiene sentido cuando:

• Vendes a empresas grandes. Las grandes organizaciones a menudo requieren infraestructura dedicada como parte de su proceso de compra.
• El cumplimiento lo exige. Industrias como salud (HIPAA), finanzas (SOX, PCI-DSS) y gobierno tienen requisitos estrictos de aislamiento de datos.
• Los clientes necesitan personalización. Si cada cliente requiere diferentes configuraciones, integraciones o incluso funcionalidades, single-tenant te da la flexibilidad.
• Tu precio lo soporta. Si cobras 5.000 euros o más al mes por cliente, el coste de infraestructura se justifica fácilmente.
• La residencia de datos es un requisito duro. Cuando los datos deben residir en un país específico, la infraestructura separada por tenant es el enfoque más directo.

Enfoques Híbridos

No tienes que elegir solo uno. Muchas empresas SaaS exitosas usan un modelo híbrido:

• Multi-tenant para niveles estándar. Los clientes free, starter y pro comparten infraestructura. Esto mantiene los costes bajos y te permite escalar.
• Single-tenant para enterprise. Los clientes premium obtienen instancias dedicadas con SLAs personalizados, certificaciones de cumplimiento y soporte dedicado.

El código de la aplicación es el mismo. El modelo de despliegue difiere. Esto requiere buena automatización de infraestructura, pero es un patrón probado.

Cómo implementar un modelo híbrido

1. Construye la app como multi-tenant primero. Toda la lógica de aislamiento de tenants permanece igual sin importar el modelo de despliegue.
2. Usa infrastructure-as-code (Terraform, Pulumi o CDK) para automatizar la creación de entornos.
3. Crea un pipeline de aprovisionamiento que pueda levantar un nuevo entorno dedicado en minutos, no días.
4. Mantén un único código base. La misma imagen Docker ejecuta en entornos compartidos y dedicados. La configuración (no el código) determina el comportamiento.

Estrategias de Base de Datos en Detalle

La base de datos es donde las decisiones de tenencia tienen más impacto. Aquí hay tres estrategias probadas.

Estrategia 1: Tablas compartidas con tenant_id

Cada tabla tiene una columna tenant_id. Todas las consultas filtran por ella.

CREATE TABLE projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_projects_tenant ON projects(tenant_id);

-- Always query with tenant context
SELECT * FROM projects WHERE tenant_id = $1;

Mejor para: La mayoría de productos SaaS. Simple, rentable, bien entendido.

Estrategia 2: Schema por tenant

Cada tenant obtiene su propio schema de PostgreSQL dentro de una base de datos compartida. Las tablas tienen la misma estructura, pero los datos están físicamente separados.

-- Create a schema for a new tenant
CREATE SCHEMA tenant_abc123;

-- Create tables in the tenant's schema
CREATE TABLE tenant_abc123.projects (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Set the search path per request
SET search_path TO tenant_abc123, public;

-- Now queries are automatically scoped
SELECT * FROM projects;

Mejor para: Productos que necesitan aislamiento más fuerte que el nivel de fila pero no quieren el coste de bases de datos separadas. Funciona bien hasta unos cientos de tenants.

Estrategia 3: Bases de datos separadas

Cada tenant obtiene una instancia dedicada de PostgreSQL (o una base de datos dedicada en un servidor compartido).

// Database connection routing
class TenantDatabaseRouter {
  private connections: Map<string, DatabasePool> = new Map();

  async getConnection(tenantId: string): Promise<DatabasePool> {
    if (this.connections.has(tenantId)) {
      return this.connections.get(tenantId)!;
    }

    const config = await this.loadTenantDbConfig(tenantId);
    const pool = new DatabasePool({
      host: config.host,
      port: config.port,
      database: config.database,
      user: config.user,
      password: config.password,
    });

    this.connections.set(tenantId, pool);
    return pool;
  }

  private async loadTenantDbConfig(tenantId: string): Promise<DbConfig> {
    // Look up tenant's database connection details
    // from a central configuration store
    return await configStore.get(`tenants/${tenantId}/database`);
  }
}

Mejor para: SaaS enterprise con clientes de alto valor, requisitos estrictos de cumplimiento u obligaciones de residencia de datos.

Tomando la Decisión

Aquí hay un marco de decisión simple:

1. ¿Cuál es el tamaño de tu cliente objetivo? SMB apunta a multi-tenant. Enterprise apunta a single-tenant o híbrido.
2. ¿Cuál es tu precio? Por debajo de 100 euros/mes, necesitas multi-tenant para ser rentable. Por encima de 1.000 euros/mes, single-tenant se vuelve viable.
3. ¿Cuáles son los requisitos de cumplimiento? Las industrias reguladas a menudo requieren aislamiento más fuerte.
4. ¿Cuántos tenants esperas? Cientos o miles de tenants necesitan infraestructura compartida. De diez a cincuenta tenants grandes pueden funcionar con instancias dedicadas.
5. ¿Cuál es la capacidad operativa de tu equipo? Single-tenant requiere más inversión en DevOps. Multi-tenant es operativamente más simple.

Si no estás seguro, empieza con multi-tenant usando una base de datos compartida y row-level security. Es la opción de menor coste, es segura cuando se implementa correctamente, y mantiene tu arquitectura simple. Siempre puedes añadir un nivel dedicado para clientes enterprise después.

La Conclusión

No hay un modelo de tenencia universalmente correcto. La elección correcta depende de tus clientes, tus precios, tus requisitos de cumplimiento y tus capacidades operativas.

La mayoría de productos SaaS deberían empezar multi-tenant. Es más barato, más simple y escala bien. A medida que te mueves hacia el mercado más alto y empiezas a vender a organizaciones más grandes, añade opciones single-tenant para clientes que las necesitan y pagarán en consecuencia.

La arquitectura debe servir al negocio, no al revés. Construye para los clientes que tienes hoy y diseña con suficiente flexibilidad para servir a los clientes que quieres mañana.

---

¿Necesitas ayuda eligiendo la arquitectura correcta para tu producto SaaS? Hemos construido sistemas multi-tenant y single-tenant en diversas industrias. Encontremos el mejor enfoque para tu proyecto.