La elección del patrón de multi-tenancy define costo de infraestructura, velocidad de deploy y qué cabe en el contrato de compliance. Tres modelos dominan el SaaS: columna tenant_id en schema compartido, schema por tenant y base de datos por tenant. Cada uno compra un nivel de aislamiento con un precio diferente.

Schema compartido con tenant_id

Es el modelo de mayor densidad y menor costo: todas las rows de todos los tenants en las mismas tablas, filtradas por tenant_id. Una migration actualiza la base entera de una vez. El aislamiento exige row-level security: las políticas RLS de Postgres con current_setting('app.tenant_id') aplican el filtro en el engine, además de la aplicación. El riesgo de noisy neighbor vive en los índices compartidos y en el connection pool, donde el tenant gigante disputa recursos con los pequeños.

Schema por tenant

Aislamiento lógico más fuerte y restore por tenant viable: el pg_dump del schema del cliente afectado preserva los demás. El precio llega en las migrations: el script corre N veces, y miles de schemas transforman deploys de minutos en horas. El connection pooling sufre más allá de algunos cientos de tenants, porque cada schema multiplica entradas de catálogo y prepared statements en el pool.

Base de datos por tenant

Aislamiento máximo para comprador con exigencia de compliance: datos separados a nivel de almacenamiento, y el pricing tier con base dedicada se vuelve argumento comercial trivial en el plan Enterprise. El costo de infraestructura va al techo; las opciones administradas (RDS, Neon) reducen el dolor operativo de patching, backup y failover de cientos de bases.

El híbrido que casi todo SaaS termina construyendo

Enterprise gana base dedicada, standard comparte. Una capa de routing lee la configuración de tenancy en cache (Redis) y direcciona la conexión correcta a cada request. El arreglo atiende a ventas sin obligar al producto entero al costo de la base exclusiva.

¿Cómo evitar fugas entre tenants?

Todo camino de query necesita scope de tenant. Un middleware que extrae el tenant del JWT o del subdomain y setea current_setting le gana al WHERE manual, que alguien olvida en el endpoint nuevo. La suite automatizada corre en todo PR: intenta acceder a datos cross-tenant y espera negación. El bug de aislamiento es incidente de seguridad con fecha marcada; trata cada fallo de ese test como bloqueo de release.

Migración entre patrones

Empezar compartido y fatiar después cuesta semanas de backfill y reescritura de queries; empezar aislado y consolidar cuesta aún más. Decide por el comprador: un pipeline de ventas tirando de compliance pesado (salud, financiero) pide aislamiento compatible con contrato enterprise desde el día uno.