¿Cómo diseñas una base de datos multi-tenant: esquema compartido, esquema por tenant o base de datos por tenant?

#Tres puntos en un espectro

Los backends SaaS multi-tenant colocan los datos de cada tenant en uno de tres lugares, y la elección es en realidad sobre cuánto aislamiento compras y a qué costo operativo:

1. Esquema compartido (pooled) — una sola base de datos, un solo conjunto de tablas, cada fila etiquetada con un tenant_id. Todos los tenants comparten el mismo esquema, el mismo pool de conexiones, los mismos índices.
2. Esquema por tenant (bridge / siloed-lite) — una sola instancia de base de datos, pero cada tenant tiene su propio esquema/namespace con un conjunto idéntico de tablas (tenant_123.orders, tenant_456.orders).
3. Base de datos por tenant (siloed) — cada tenant tiene una base de datos completamente separada (potencialmente en instancias separadas), sin ningún motor de almacenamiento compartido.

#Esquema compartido: el default para la mayoría de los SaaS

Ajustar líneas largas
CREATE TABLE orders (
    id          BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    tenant_id   BIGINT NOT NULL REFERENCES tenants(id),
    customer_id BIGINT NOT NULL,
    total_cents INTEGER NOT NULL,
    status      TEXT NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Todo índice que soporte una consulta acotada por tenant empieza con tenant_id,
-- para que el planner pueda podar de inmediato a las filas de un solo tenant.
CREATE INDEX idx_orders_tenant_created ON orders (tenant_id, created_at DESC);

-- Aislamiento de cinturón y tirantes: row-level security en Postgres significa que
-- incluso un WHERE olvidado en el código de la aplicación no puede filtrar filas de otro tenant.
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
    USING (tenant_id = current_setting('app.current_tenant_id')::BIGINT);

La aplicación fija app.current_tenant_id una vez por conexión/transacción (típicamente justo después de tomar una conexión del pool, a partir del claim de tenant de la petición autenticada), y desde ese punto cada consulta —incluso un SELECT * FROM orders escrito con descuido, sin ningún WHERE— queda filtrada de forma transparente a ese tenant por el propio Postgres?. Esta es la red de seguridad más importante en un diseño de esquema compartido, porque la alternativa es "cada ingeniero, en cada consulta, para siempre, debe recordar filtrar por tenant_id" — una promesa que un código base termina rompiendo tarde o temprano.

El costo del esquema compartido es enteramente riesgo operativo concentrado en un solo lugar: un full table scan causado por la consulta mal escrita de un tenant quema I/O y buffer cache de los que dependen todos los demás tenants simultáneamente, y un problema de bloat de índice o de vacuum es problema de todos a la vez.

#Esquema por tenant: aislamiento sin proliferación de infraestructura

-- Onboarding del tenant 123: clonar la estructura del esquema plantilla.
CREATE SCHEMA tenant_123;

CREATE TABLE tenant_123.orders (
    id          BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    customer_id BIGINT NOT NULL,
    total_cents INTEGER NOT NULL,
    status      TEXT NOT NULL,
    created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

Aquí tenant_id desaparece de todas las tablas — el límite del esquema es el aislamiento, así que ningún WHERE tenant_id = ? puede olvidarse jamás. La trampa aparece en operaciones: agregar una columna ahora significa iterar cada esquema de tenant y correr la migración N veces (normalmente mediante una herramienta de migración manejada en un loop, con reintento/rollback rastreado por esquema), y la mayoría de los motores tiene un techo práctico de esquemas por instancia (Postgres maneja miles de esquemas, pero la planificación de consultas, pg_dump y las búsquedas de catálogo al conectar se vuelven más lentas conforme el número de esquemas crece hacia las decenas de miles).

#Base de datos por tenant: aislamiento total, peso operativo total

Esta es la decisión correcta cuando los tenants son lo bastante grandes como para que el riesgo de vecino ruidoso sea inaceptable, cuando los contratos exigen residencia de datos o infraestructura dedicada, o cuando los requisitos de cumplimiento/auditoría de un tenant empresarial grande (su propio calendario de backups, su propia llave de cifrado, su propia política de retención) no pueden satisfacerse con nada menos que una instancia dedicada. El costo es que "aprovisionar un tenant" se vuelve trabajo de infraestructura real, y correr una migración a través de una flota de 500 bases de datos de tenants necesita su propia orquestación (un runner de migraciones que itera cadenas de conexión, rastrea la versión de migración por tenant y maneja fallas parciales sin corromper el estado de toda la flota).

#El patrón que casi nadie se salta: un híbrido

Los backends SaaS de producción rara vez eligen un solo punto del espectro para todos sus tenants. La forma común es un nivel pooled (esquema compartido) para la larga cola de tenants gratuitos o de plan pequeño, donde el overhead por tenant debe ser casi cero, y un nivel siloed (esquema o base de datos por tenant) para cuentas empresariales que pagan por aislamiento, cumplimiento o rendimiento garantizado — con una ruta de migración para mover a un tenant de pooled a siloed conforme crece o sube de plan. Diseñar esa ruta de migración desde el día uno (identificadores de tenant consistentes, una capa de acceso a datos que no asuma "todo es una sola tabla compartida") es mucho más barato que improvisarla una vez que un solo prospecto empresarial exige un aislamiento que tu arquitectura nunca contempló.

🧠 Check your understanding
0/3 · 0/3 answered
1. En un diseño multi-tenant de esquema compartido, ¿cuál es el beneficio práctico principal de habilitar row-level security además del filtrado por tenant_id a nivel de aplicación?
Shardea automáticamente la tabla por tenantElimina por completo la necesidad de una columna tenant_idMejora el rendimiento de las consultas al agregar un índice implícitoOfrece un respaldo forzado por la base de datos para que un WHERE olvidado en el código de la aplicación no pueda filtrar filas de otro tenant
2. ¿Qué modelo de multi-tenancy hace más limpio ejecutar 'borrar todos los datos de un tenant' para una solicitud de cumplimiento?
Esquema compartido, mediante políticas de row-level securityEsquema por tenant es imposible de borrar por completoEsquema compartido, mediante un DELETE por tablaBase de datos por tenant, eliminando la base de datos completa
3. ¿Por qué la mayoría de las plataformas SaaS grandes terminan usando una estrategia híbrida de multi-tenancy en lugar de un solo modelo para todos los tenants?
Los motores de base de datos solo soportan un modelo de tenancy por instalaciónLos tenants pequeños necesitan un overhead casi nulo por tenant (pooled), mientras que los tenants grandes o regulados necesitan garantías de aislamiento que solo un esquema o base de datos siloed puede darEl esquema compartido y la base de datos por tenant no pueden coexistir en la misma empresaLos diseños híbridos son exigidos por el estándar SQL