Arquitectura SaaS Multi-Tenant: Estrategias de BD, Escala y Trade-Offs Reales
Elegir tu estrategia multi-tenant el primer día marca los siguientes 5 años de tu SaaS. La elección equivocada aparece como un proyecto de migración de 6 meses justo cuando tu equipo de ventas menos puede permitírselo. Esta guía es un recorrido con opinión por las tres estrategias principales (base de datos compartida, schema-por-tenant, BD-por-tenant) con números de rendimiento, garantías de aislamiento y rutas de migración que usamos en Alher Tech para arquitecturar SaaS que escala.
Las Tres Estrategias
- BD compartida, schema compartido (row-level): Todos los tenants viven en las mismas tablas. Cada fila lleva tenant_id. La más barata de construir, la más barata de operar a poco tenant, pero el aislamiento depende de disciplina total al escribir queries.
- BD compartida, schema-por-tenant: Cada tenant tiene su schema en la misma BD. Aislamiento más fuerte que row-level, menos ops que BD-por-tenant. El término medio correcto en B2B SaaS hasta 1.000-3.000 tenants.
- BD-por-tenant: Cada tenant tiene su BD (o cluster) propios. El aislamiento más fuerte, residencia de datos fácil, lo más duro de operar. Correcto para enterprise SaaS o verticales con mucho compliance.
Cuándo Gana Cada Una
Números de Rendimiento (PostgreSQL, 2026)
Números reales de sistemas en producción que hemos entregado. Variarán para ti pero son los órdenes de magnitud:
| Estrategia | Techo práctico | Migración por tenant | Granularidad backup |
|---|
| Row-level (compartido) | ~5.000 tenants por cluster | Una transacción, todos los tenants | Todo o nada |
| Schema-por-tenant | ~3.000 schemas por BD | Por tenant vía search_path | Dump por schema posible |
| BD-por-tenant | ~200-500 BDs por cluster, luego shard | Por BD | Por BD en cualquier momento |
Row-level compartido puede escalar más con sharding, pero cruzas un umbral de complejidad ~5K tenants donde schema-por-tenant es operativamente más simple.
Aislamiento: Qué Garantiza Cada Uno
- Aislamiento row-level: Un bug en tu WHERE filtra datos entre tenants. La mayoría de equipos lo refuerza con Row-Level Security (RLS) de Postgres, que establece una policy que filtra por tenant_id automáticamente. Fuerte si se usa con disciplina.
- Aislamiento por schema: El acceso cross-tenant requiere queries explícitas cross-schema. Más fácil de revisar en code review. Connection strings por tenant o search_path previenen accidentes.
- Aislamiento por BD: Segmentación a nivel red. Credenciales distintas, pools distintos, ficheros físicos distintos. El aislamiento más fuerte sin clusters separados.
- Perspectiva compliance: HIPAA, PCI, SOC 2 no obligan a BD-por-tenant, pero los auditores hacen menos preguntas. El coste es operativo; el beneficio, velocidad en auditoría.
La Trampa de la Migración
Si empiezas con row-level y creces pasando 1.000 tenants con un par de enterprise pidiendo residencia de datos, tendrás que migrar. Los costes:
- Refactor consciente de schema en tenant_id por 100K+ líneas: 4-12 semanas de senior
- Scripts de migración para partir tenants en schemas sin downtime: 2-6 semanas
- Rehacer cada connection pool, dashboard, query de analítica
- Suele ser un proyecto de 6 meses que entrega cero valor de negocio nuevo
- Coste: 200K – 800K $ según escala y equipo
Si tienes cualquier indicio de que clientes enterprise pedirán aislamiento, empieza con schema-por-tenant el día uno. La complejidad marginal es pequeña; el coste de migrar después es enorme.
Arquitectura Práctica para B2B SaaS
La arquitectura que usamos por defecto en 2026 para B2B SaaS:
- PostgreSQL con schema-por-tenant. RLS de respaldo en tablas compartidas (auth, billing).
- Una sola instancia de aplicación, search_path dinámico por request según tenant autenticado.
- Pooling con PgBouncer en modo transaction (RDS Proxy en AWS).
- Feature flags por tenant vía columna JSON en una tabla de tenants.
- Migraciones por tenant con rollout controlado (10% → 50% → 100% en horas).
- Backup: WAL streaming + dumps lógicos por schema para PITR a nivel tenant.
- Plan de sharding documentado antes de necesitarlo. Cuando el tenant count o tamaño de BD cruza umbral, shardea tenants entre BDs por hash de tenant_id.
Errores Comunes
- Empezar BD-por-tenant 'porque los enterprise lo pedirán'. Igual sí. Hasta entonces pagas impuesto de ops por nada.
- Row-level sin RLS. Bug en código = filtración. Activa RLS aunque tu base 'siempre pase tenant_id'.
- Migraciones por tenant aplicadas en serie en 5.000 tenants son deploys de 4 horas. Scripts paralelos con controles.
- Queries cross-tenant agregadas en la BD principal. Bloquean cosas inesperadas. Replica a una BD de analítica.
- Guardar config de tenant en código. El onboarding requiere deploy. Múdala a la BD.
Elige por el Perfil de Cliente, No por la Demo
La multi-tenancy es la decisión arquitectónicamente más consecuente en un SaaS. Elige según los clientes que servirás de verdad, incluyendo los enterprise a dos años vista.
Schema-por-tenant en PostgreSQL es la respuesta correcta en la mayoría de B2B SaaS de 2026. Default ahí salvo razones específicas para ir más bajo (PYMES early-stage) o más alto (enterprise regulado).
Preguntas frecuentes
¿Empiezo con BD-por-tenant?
Solo si tus primeros clientes son enterprise regulados (HIPAA, banca, defensa). Si no, el overhead operativo retrasa la entrega del producto por beneficios que igual no necesitas.
¿Schema-por-tenant es solo Postgres?
Mejor soportado en PostgreSQL. MySQL tiene soporte limitado. SQL Server lo hace bien. Stores NoSQL (Mongo, Dynamo) manejan multi-tenancy distinto, típicamente por colección o por tabla.
¿Cuántos schemas aguanta PostgreSQL?
Techo práctico: 3-5K schemas antes de que las queries de pg_class noten lentitud. Algunos equipos corren 10K+ con tuning. Pasando eso, shardea schemas entre varias BDs.
¿Y Row-Level Security?
Úsalo como defensa en profundidad sobre tablas compartidas, no como mecanismo principal. Es la red de seguridad para errores humanos, no la arquitectura en sí.
¿Puedo migrar de row-level a schema-por-tenant después?
Sí, pero es un proyecto de 6 meses costando 200K-800K $ según tamaño. Si hay 30%+ de probabilidad de necesitarlo, empieza con schema-por-tenant.
Guías relacionadas