Arquitectura Multi-Tenant

Multi-tenant significa que múltiples clientes (tenants) comparten la misma aplicación y base de datos. Hay 3 estrategias de aislamiento:

1. Shared Database, Shared Schema: Todos los tenants en las mismas tablas, separados por tenant_id. Más barato, más fácil de mantener, pero requiere disciplina para no mezclar datos.

2. Shared Database, Separate Schemas: Cada tenant tiene su propio schema (namespace) en la misma DB. Buen balance entre aislamiento y costo.

3. Separate Databases: Cada tenant tiene su propia DB. Máximo aislamiento, pero más caro y complejo de mantener. Solo para enterprise con requisitos estrictos de compliance.

La estrategia más común (y recomendada para startups) es Shared Schema con Row-Level Security (RLS). En PostgreSQL/Supabase, puedes activar RLS para que la base de datos NUNCA devuelva filas de otro tenant, sin importar qué query ejecutes. Esto elimina la posibilidad de bugs de filtrado que expongan datos de otro cliente.

-- ESTRATEGIA 1: Shared Schema con tenant_id
CREATE TABLE proyectos (
  id SERIAL PRIMARY KEY,
  tenant_id UUID NOT NULL REFERENCES organizaciones(id),
  nombre TEXT NOT NULL,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Índice para queries rápidas por tenant
CREATE INDEX idx_proyectos_tenant ON proyectos(tenant_id);

-- Row-Level Security (PostgreSQL/Supabase)
ALTER TABLE proyectos ENABLE ROW LEVEL SECURITY;

-- Política: cada usuario solo ve datos de su organización
CREATE POLICY tenant_isolation ON proyectos
  USING (tenant_id = current_setting('app.current_tenant')::UUID);

-- En tu API (middleware):
-- SET app.current_tenant = 'uuid-del-tenant';
-- Ahora cualquier SELECT solo devuelve datos de ese tenant