# Arquitectura SaaS Multi-Tenant: Estrategias de BD, Escala y Trade-Offs Reales | Alher Tech > Elegir tu estrategia multi-tenant el primer día marca los siguientes 5 años. BD compartida, schema-por-tenant, BD-por-tenant: cuándo gana cada una, números de rendimiento, garantías de aislamiento y cómo migrar si te equivocaste. - Canonical page: https://alhertech.com/es/guias-saas/arquitectura-saas-multi-tenant/ - Site: Alher Tech (custom software, AI agents and SEO engineering, https://alhertech.com/) - Contact: https://alhertech.com/es/contacto/ --- 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 - [Software a medida vs SaaS: cómo elegir](https://alhertech.com/es/guias-saas/software-medida-vs-saas/) - [Desarrollo de ERP a medida](https://alhertech.com/es/guias-saas/desarrollo-erp-medida/) - [Migración de sistemas legacy](https://alhertech.com/es/guias-saas/migracion-sistemas-legacy/) - [Nuestros servicios de software a medida](https://alhertech.com/es/servicios/desarrollo-software-a-medida/)