Cómo Dar a Cada Cliente Sus Propios Datos Sin Romper Tu Base de Datos

Nota del Autor

Este tutorial está dirigido a desarrolladores que construyen aplicaciones SaaS con múltiples clientes (tenants) y necesitan decidir cómo estructurar sus datos. Ya sea que estés comenzando desde cero o refactorizando una arquitectura existente, esta guía te ayudará a tomar una decisión informada.

El Problema de los Datos Multi-Tenant

Cuando construyes una aplicación SaaS, uno de los desafíos más críticos es garantizar que los datos de un cliente nunca sean visibles para otro. Esto se conoce como aislamiento de tenants, y hacerlo bien puede ser la diferencia entre una plataforma confiable y una violación de datos catastrófica.

Imagina que tienes una plataforma de análisis llamada Dashrendr. Tienes cientos de empresas —cada una con sus propios usuarios, paneles y métricas— todas ejecutándose en la misma aplicación. ¿Cómo te aseguras de que Acme Corp nunca vea los datos de Globex?

Existen tres enfoques principales, cada uno con sus propias compensaciones.

Opción 1: Base de Datos Separada por Tenant

En este enfoque, cada tenant obtiene su propia instancia de base de datos completamente aislada.

Ventajas

• Aislamiento máximo: no hay posibilidad de fuga de datos entre tenants
• Fácil de cumplir con requisitos de residencia de datos
• El rendimiento de un tenant no afecta a otros
• Las copias de seguridad y restauraciones son por tenant

Desventajas

• Costoso de escalar: cientos de bases de datos = cientos de costos de infraestructura
• Las migraciones de esquema deben ejecutarse en cada base de datos individualmente
• La gestión de conexiones se vuelve compleja

Cuándo usarlo

Este enfoque es ideal cuando tienes pocos tenants de alto valor con estrictos requisitos de cumplimiento (por ejemplo, clientes empresariales, sectores de salud o finanzas).

-- Cada tenant tiene su propia base de datos
-- Conexión: postgresql://host/tenant_acme
-- Conexión: postgresql://host/tenant_globex

SELECT * FROM dashboards; -- Solo devuelve datos de Acme

Opción 2: Esquema Separado por Tenant

Aquí, todos los tenants comparten la misma base de datos, pero cada uno tiene su propio esquema (namespace) dentro de ella.

Ventajas

• Buen equilibrio entre aislamiento y costo
• Las migraciones pueden ejecutarse en todos los esquemas con scripts
• Más fácil de gestionar que múltiples bases de datos

Desventajas

• Aún puede ser costoso con miles de tenants
• Algunos motores de base de datos tienen límites en el número de esquemas
• Las consultas entre tenants requieren referencias de esquema explícitas

Cuándo usarlo

Funciona bien para plataformas con decenas a cientos de tenants donde el aislamiento es importante pero el costo de bases de datos separadas es prohibitivo.

-- Cada tenant tiene su propio esquema
-- Schema: acme.dashboards, globex.dashboards

SET search_path TO acme;
SELECT * FROM dashboards; -- Solo devuelve datos de Acme

Opción 3: Fila Separada (Discriminador de Tenant)

En este enfoque, todos los tenants comparten las mismas tablas, y cada fila tiene una columna tenant_id que identifica a qué tenant pertenece.

Ventajas

• El más económico y simple de implementar
• Las migraciones de esquema se ejecutan una sola vez
• Fácil de consultar datos entre tenants (para análisis internos)
• Escala bien con muchos tenants pequeños

Desventajas

• Mayor riesgo de fuga de datos si olvidas filtrar por tenant_id
• Un tenant ruidoso puede afectar el rendimiento de otros
• Más difícil de cumplir con requisitos estrictos de residencia de datos

Cuándo usarlo

Ideal para startups y plataformas con muchos tenants pequeños donde el costo y la simplicidad son prioritarios.

-- Todos los tenants comparten las mismas tablas
CREATE TABLE dashboards (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- SIEMPRE filtra por tenant_id
SELECT * FROM dashboards WHERE tenant_id = '{{tenant_id}}';

Cómo Dashrendr Maneja el Aislamiento de Tenants

En Dashrendr, comenzamos con el enfoque de fila separada porque nos permitió iterar rápidamente. A medida que crecimos y adquirimos clientes empresariales con requisitos de cumplimiento más estrictos, migramos a un modelo híbrido:

• Clientes del plan gratuito y de inicio: fila separada en tablas compartidas
• Clientes del plan empresarial: esquema separado o base de datos separada según el contrato

Esta estrategia híbrida nos permitió escalar de manera rentable mientras satisfacíamos las necesidades de cumplimiento de nuestros clientes más grandes.

Errores Comunes

1. Olvidar el filtro de tenant_id

Con el enfoque de fila separada, el error más peligroso es olvidar incluir WHERE tenant_id = ? en una consulta. Esto puede exponer todos los datos de todos los tenants. Usa un ORM o una capa de repositorio que aplique automáticamente el filtro de tenant.

-- ❌ PELIGROSO: falta el filtro de tenant
SELECT * FROM dashboards;

-- ✅ CORRECTO: siempre filtra por tenant
SELECT * FROM dashboards WHERE tenant_id = current_tenant_id();

2. No indexar tenant_id

Si usas el enfoque de fila separada, asegúrate de que tenant_id esté indexado en todas las tablas. Sin un índice, cada consulta realizará un escaneo completo de la tabla a medida que crezcan tus datos.

CREATE INDEX idx_dashboards_tenant_id ON dashboards(tenant_id);

3. Mezclar estrategias sin un plan

Migrar entre estrategias de aislamiento es costoso y arriesgado. Elige tu estrategia inicial basándote en tu modelo de negocio proyectado, no solo en las necesidades actuales.

4. Ignorar el aislamiento a nivel de aplicación

El aislamiento de base de datos no es suficiente por sí solo. Tu capa de aplicación también debe hacer cumplir los límites de tenant. Valida siempre el contexto del tenant en cada solicitud.

Conclusión

No existe una solución única para el aislamiento de datos multi-tenant. La elección correcta depende de tu escala, presupuesto, requisitos de cumplimiento y modelo de negocio.

Como regla general:

• Comienza con fila separada si eres una startup que busca velocidad y economía
• Considera esquema separado cuando el cumplimiento se vuelva importante
• Usa base de datos separada para clientes empresariales de alto valor con estrictos requisitos de aislamiento

Sea cual sea el enfoque que elijas, aplícalo de manera consistente, documéntalo bien y asegúrate de que tu equipo entienda las implicaciones de seguridad. El aislamiento de tenants no es solo una decisión técnica —es una promesa que le haces a tus clientes.

¿Tienes preguntas sobre cómo implementar el aislamiento de tenants en tu stack específico? Déjanos un comentario a continuación o consulta nuestra documentación de multi-tenant.