🏢 Entendiendo el Multitenant: Single Tenant vs Multi-Tenant, Schemas y Estrategias de Aislamiento

En el mundo del software como servicio (SaaS), la gestión de múltiples clientes (o tenants) es un pilar fundamental. ¿Cómo separar datos, garantizar seguridad y escalar sin volverse loco? Aquí entran los conceptos de single-tenant, multi-tenant y el rol de los schemas en bases de datos.

🔹 ¿Qué es un Tenant?

Un tenant es un grupo de usuarios que comparten el mismo acceso a una aplicación SaaS. Normalmente corresponde a un cliente u organización. Cada tenant tiene sus propios datos, configuraciones y, a menudo, su propia identidad visual.

Ejemplos:

• Una empresa que usa Salesforce → esa empresa es un tenant.
• Un equipo en Slack → ese workspace es un tenant.

🔹 Modelos de despliegue: Single-Tenant vs Multi-Tenant

🧱 Single-Tenant (un cliente por instancia)

Cada cliente tiene su propia instancia dedicada de la aplicación y la base de datos. Es como tener un edificio entero para una sola familia.

Ventajas:

• Aislamiento total de datos.
• Personalización extrema (versiones específicas, recursos dedicados).
• Cumplimiento normativo (GDPR, HIPAA) más fácil.

Desventajas:

• Mayor costo operativo (más instancias, actualizaciones, monitoreo).
• Complejidad al escalar (cada nuevo cliente = nueva infraestructura).

☁️ Multi-Tenant (un cliente por tenant, pero todos comparten la misma infraestructura)

Una sola instancia de la aplicación y una base de datos servirán a múltiples tenants. Los datos se distinguen mediante algún mecanismo (schema, fila con tenant_id, etc.). Es como un gran edificio de apartamentos.

Ventajas:

• Menor costo por cliente (aprovechamiento de recursos).
• Actualizaciones y parches una sola vez.
• Escalamiento horizontal más simple (se replica el mismo stack).

Desventajas:

• Riesgo de fuga de datos entre tenants si no se aísla bien.
• Dificultad para "inquilinos ruidosos" (clientes que consumen muchos recursos).
• Menor capacidad de personalización por tenant.

🔹 Estrategias de aislamiento de datos en Multi-Tenant

Cuando compartes una base de datos, necesitas separar lógicamente a los tenants. Aquí aparecen los schemas (en SQL) y otras técnicas.

1️⃣ Base de datos por tenant

Es casi single-tenant pero en un mismo servidor. Cada tenant tiene su propia base de datos.

✅ Alto aislamiento.
❌ Administración de muchas bases de datos, conexiones, backups.

2️⃣ Schema por tenant

Un mismo servidor y una misma base de datos, pero cada tenant tiene su propio schema (ej: tenant1.tabla, tenant2.tabla). Los schemas actúan como contenedores de tablas.

✅ Buen equilibrio: aislamiento lógico, backups centralizados.
❌ Límite de schemas por base de datos (en PostgreSQL ~16k, por ejemplo).

3️⃣ Fila con tenant_id (discriminador)

Una sola tabla para todos los tenants, con una columna tenant_id que identifica a cada fila. Todas las consultas deben incluir un filtro por ese ID.

| id | tenant_id | nombre | datos | |----|-----------|------------|-------------| | 1 | acme | Producto X | ... | | 2 | globex | Producto Y | ... |

✅ Máximo compartir, menor costo, fácil de escalar.
❌ Mayor riesgo de fuga de datos si olvidas el WHERE tenant_id = ?.
❌ Backups/restauraciones por tenant son complejas.

🔹 ¿Qué es un Schema en bases de datos?

Un schema (esquema) es un contenedor lógico dentro de una base de datos que agrupa tablas, vistas, procedimientos, etc.
En SQL Server, PostgreSQL y otros, el esquema también ayuda a definir permisos y aislamiento.

• En PostgreSQL, public es el esquema por defecto.
• En Oracle, un esquema equivale casi a un usuario.

En el contexto multi-tenant, usar un schema por tenant permite:

• Restaurar solo un tenant (backup por schema).
• Mover un tenant a otro servidor más fácil.
• Dar permisos granulares (USAGE ON SCHEMA).

🔹 Ejemplo práctico con PostgreSQL

Crear un tenant usando un nuevo schema:

-- Crear schema para el tenant "acme"
CREATE SCHEMA acme;

-- Crear tablas dentro de ese schema
CREATE TABLE acme.usuarios (
    id SERIAL PRIMARY KEY,
    nombre TEXT
);

-- Consultar datos de ese tenant
SET search_path TO acme;
SELECT * FROM usuarios;

Para la estrategia de tenant_id:

CREATE TABLE public.pedidos (
    id SERIAL,
    tenant_id TEXT,
    producto TEXT,
    cantidad INT
);

-- Consultar solo los pedidos de acme
SELECT * FROM pedidos WHERE tenant_id = 'acme';

🧠 ¿Cuándo elegir cada estrategia?

| Criterio | Base de datos por tenant | Schema por tenant | Fila con tenant_id | |------------------------------|--------------------------|-------------------|--------------------| | Aislamiento de datos | 🔒🔒🔒 (Máximo) | 🔒🔒 (Medio) | 🔒 (Bajo) | | Costo operativo | 💰💰💰 Alta | 💰💰 Media | 💰 Baja | | Facilidad de restauración | 👍 (DB completa) | 👍👍 (por schema) | 👎 (compleja) | | Límites técnicos | Conexiones | Cantidad de schemas| Tamaño de tabla | | Recomendado para | Bancos, salud, gobierno | SaaS con clientes grandes| SaaS masivo (ej: Trello, Notion) |

🚀 Conclusión

No hay una única solución "correcta". El diseño multi-tenant depende de:

• Requisitos de seguridad y aislamiento.
• Presupuesto y recursos de operaciones.
• Escala esperada (decenas, miles o millones de tenants).

Si empiezas un SaaS, la estrategia de schema por tenant o fila con tenant_id suele ser el punto de partida. A medida que creces, podrías migrar a bases de datos dedicadas para clientes premium.

¿Tienes un caso concreto? ¡Comparte y lo analizamos!

#SaaS #MultiTenant #ArquitecturaDeSoftware #BasesDeDatos #PostgreSQL