Multi-Tenancy en SaaS B2B: Arquitectura + Decisiones

Multi-tenancy es la arquitectura que define cómo el SaaS aísla data + compute por cliente. 3 modelos típicos. Decisión arquitectónica importante difícil de cambiar después.

Vinculados: desarrollar SaaS B2B desde Argentina.

Los 3 modelos

1. Shared schema (con tenant_id)

Todos los tenants en misma DB + misma schema. Cada tabla tiene tenant_id que filtra queries.

Pros:

• Más simple
• Más barato (1 DB para todos)
• Backups + migrations simples
• Escala linealmente

Contras:

• Aislamiento por código (queries deben filtrar)
• Si bug, riesgo de cross-tenant data leak
• Compliance estricto requiere más work

2. Schema per tenant

Misma DB, schema separada por tenant.

Pros:

• Aislamiento medio
• Customizaciones por tenant más fáciles
• Backups por tenant

Contras:

• Migrations: aplicar a todos los schemas
• Connection pool más complejo
• Limit de schemas en Postgres (~10k práctico)

3. Database per tenant

DB separada por tenant.

Pros:

• Aislamiento máximo
• Compliance estricto fácil
• Performance isolation
• Cada tenant puede tener config custom

Contras:

• Costo lineal (cada DB cuesta)
• Operations complejo
• Migrations a aplicar N veces
• Solo justifica para enterprise muy estricto

Cuándo cada uno

Shared schema

• Mayoría de SaaS B2B (95%)
• Tenants chicos-medianos
• Compliance estándar (GDPR, etc)
• Bootstrap con presupuesto limitado

Schema per tenant

• Algunos tenants requieren customización profunda
• Compliance sectorial específico
• Tenants de tamaño grande pero no enorme

DB per tenant

• Tenants enterprise con compliance estricto (HIPAA, FedRAMP)
• Performance isolation requirement
• Justifica el costo extra

Implementación shared schema

Si el SaaS lo armás desde cero, vale considerar sistemas a medida que ya nacen con multi-tenancy bien hecho desde la primera tabla.

Pattern recomendado

• Cada tabla con tenant_id (UUID o int)
• Index compuesto (tenant_id, otros campos)
• Middleware que inyecta tenant_id en cada query
• RLS (Row Level Security) en Postgres como defensa adicional

Postgres RLS

ALTER TABLE customers ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON customers
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

App setea app.tenant_id al inicio de cada request. Postgres aplica filter automático.

Validation extra

• Tests específicos para cross-tenant access
• Audit log con tenant_id
• Reviews de queries antes de prod

Migración entre modelos

Shared → Schema-per-tenant

Posible pero costosa. Generalmente solo cuando 1-2 tenants enormes lo justifican (mover esos 2 a schemas separados).

Schema-per-tenant → DB-per-tenant

Más fácil que la anterior. Cada schema se exporta a DB nueva.

Importante: decidir bien al inicio. Migrar cuesta meses.

Costos típicos

Shared schema

• 1 Postgres = USD 25-200/mes según volumen
• Setup: incluido en stack base
• Mantenimiento: simple

Schema per tenant (100 tenants)

• 1 Postgres + lógica = USD 50-500/mes
• Mantenimiento: medio (migrations N veces)

DB per tenant (100 tenants)

• 100 DBs = USD 2.500-20.000/mes
• Mantenimiento: alto

En síntesis

Multi-tenancy: shared schema con tenant_id es default correcta para 95% de SaaS B2B. RLS de Postgres + tests + middleware = arquitectura sólida. Schema o DB per tenant solo cuando casos específicos lo justifican.

Cotizá tu proyecto. Más sobre el tema: desarrollar SaaS B2B desde Argentina, stack tecnológico para sistemas empresariales 2026.