Si estás diseñando el modelo de datos de un SaaS vertical, la pregunta sobre multitenancy base de datos SaaS no es "¿RLS o schema-per-tenant?". Es cuánto te va a costar operar esa decisión en dos años, cuando lleguen clientes enterprise con auditorías, requisitos regulatorios y ventanas de mantenimiento propias. Row-level security funciona cuando todos comparten un modelo estable. Schema-per-tenant ayuda cuando necesitás aislamiento operativo real. El híbrido es lo más práctico: compartís lo común, separás lo riesgoso y reservás mayor aislamiento para tenants complejos.
Según Gartner, el gasto en SaaS llegaría a USD 299,1B en 2025 desde USD 250,8B en 2024. Cuando SaaS pasa de "software barato en la nube" a infraestructura crítica de operación, el modelo de tenancy afecta margen bruto, soporte, onboarding y capacidad de vender a cuentas más exigentes.
Datos clave del sector:
- El mercado SaaS de América Latina crecerá de USD 19 mil millones en 2024 a USD 66 mil millones para 2033.
- Un SaaS vertical bien posicionado puede alcanzar USD 5.000 de ingresos mensuales recurrentes con menos de 50 clientes.
- El churn promedio en SaaS B2B vertical es del 5 mensual versus 10 a 15 en soluciones horizontales.
- Las startups que validan con MVP invierten 80 veces menos recursos en la fase inicial de desarrollo.
- El ciclo de ventas B2B en SaaS vertical dura entre 30 y 90 días, frente a 6 a 12 meses en enterprise horizontal.
“El 28% de crecimiento de empresas SaaS en Latinoamérica cada año hace que la arquitectura multitenancy sea una decisión estratégica, no técnica.
Multitenancy base de datos SaaS: una decisión de producto, no solo técnica
En un SaaS horizontal, los tenants se parecen bastante entre sí. En un SaaS vertical, cada cliente opera dentro de un dominio con reglas propias: salud, logística, educación, legal, manufactura, servicios profesionales. Eso cambia toda la discusión.
La pregunta real no es "¿pongo un tenant_id en todas las tablas?". Es: "¿Cómo voy a aislar, cambiar, migrar, auditar, restaurar y escalar datos de muchos clientes sin que cada release sea una operación riesgosa?".
Hay tres patrones principales:
- Base compartida con
tenant_idy row-level security. - Schema separado por tenant.
- Diseño híbrido con distintos niveles de aislamiento según el tipo de cliente o módulo.
Esta decisión se conecta directamente con la de infraestructura: en infraestructura SaaS vertical comparativa están los criterios para elegir dónde alojar esa base de datos según tu etapa.
“El mercado SaaS latinoamericano crece al 28% anual: una oportunidad de USD 66.000 millones para 2033.
El marco silo-bridge-pool para pensar antes de decidir
AWS describe tres estrategias de particionamiento SaaS:
- Pool ≈ base compartida con
tenant_idy controles de acceso. - Bridge ≈ schema-per-tenant o particiones dedicadas dentro de infraestructura común.
- Silo ≈ database-per-tenant o infraestructura dedicada para clientes que exigen aislamiento fuerte.
La advertencia clave: no confundir particionamiento con aislamiento. Una tabla compartida con tenant_id particiona datos, pero el aislamiento real también depende de autorización, políticas de query, backups, restauración, observabilidad, cifrado, jobs internos, webhooks y acciones administrativas.
Tres opciones y sus costos reales
Base compartida con row-level security
Todas las tablas en el mismo schema, cada fila con referencia al tenant, RLS para controlar qué ve cada uno. La ventaja es simplicidad operativa: una sola estructura, una sola migración por release, un solo conjunto de índices.
El costo aparece en el aislamiento. Un bug en la capa de aplicación, una política mal definida o una consulta administrativa sin filtro pueden exponer datos de otro tenant. RLS reduce ese riesgo, pero la aplicación debe establecer correctamente el contexto del tenant en cada request, job, worker y script interno.
IBM reportó que el costo promedio global de una brecha de datos llegó a USD 4,88M en 2024. En multitenancy, un error de límite entre tenants no es solo un bug técnico: puede convertirse en un problema comercial, legal y reputacional.
Funciona mejor cuando:
- El modelo de datos es bastante uniforme entre tenants.
- La personalización se maneja por configuración, no por estructura.
- El equipo puede invertir en tests de aislamiento.
- Los tenants no necesitan ciclos de migración independientes.
Schema-per-tenant
Cada cliente tiene su propio schema dentro de la misma base de datos. Las tablas se repiten por tenant, pero la infraestructura física puede seguir compartida.
La ventaja principal es el aislamiento lógico: más difícil mezclar datos, operaciones por tenant más claras —backups parciales, restauraciones selectivas, migraciones controladas.
El costo más visible está en las migraciones. Una migración que antes corría una vez ahora debe correr para cada schema. Si hay muchos tenants, la operación necesita tooling, control de versiones, reintentos, observabilidad y rollback.
Funciona mejor cuando:
- El número de tenants es manejable para el equipo.
- El aislamiento por cliente vale más que la simplicidad inicial.
- Hay clientes grandes con ciclos de cambio delicados.
Arquitectura híbrida
El enfoque que reconoce que no todos los tenants ni todos los datos necesitan el mismo nivel de aislamiento. Un diseño híbrido puede adoptar varias formas:
- Tenants pequeños en tablas compartidas con RLS, clientes enterprise con schemas separados.
- Datos comunes en base compartida, módulos sensibles en estructuras dedicadas.
- Entidades centrales compartidas, datos de alto volumen o alta sensibilidad en estructuras propias.
Grand View Research estimó el mercado global de vertical software en USD 150,25B en 2024 y proyectó USD 430,12B para 2033. Esa expansión trae más industrias, más regulación y más presión para que la arquitectura soporte distintos niveles de aislamiento sin partir el producto en copias independientes.
Comparativa rápida
| RLS (pool) | Schema-per-tenant | Híbrido | |
|---|---|---|---|
| Aislamiento | Lógico (por política) | Lógico (por namespace) | Variable según módulo |
| Migraciones | Una vez, afecta todos | N veces, controladas | Mixto |
| Personalización | Por config | Puede variar estructura | Por módulo |
| Tooling requerido | Bajo | Alto | Medio-alto |
| Blast radius | Todo el sistema | Un tenant | Depende del límite |
| Mejor para | Tenants uniformes | Clientes enterprise | Mezcla de perfiles |
El costo que más sorprende: las migraciones
En base compartida, la migración se ejecuta una vez pero afecta a todos. Un error impacta toda la plataforma.
En schema-per-tenant, el impacto se puede controlar por cliente, pero la ejecución se multiplica. Hay que saber qué tenants migraron, cuáles fallaron, cuáles necesitan reintento.
Una práctica sana es diseñar migraciones como operaciones de producto:
- Cada migración debe ser idempotente o tener reintentos seguros.
- Los cambios destructivos deben dividirse en pasos.
- El código nuevo debe poder convivir temporalmente con datos viejos.
- Las migraciones largas se observan como procesos, no como comandos invisibles.
Personalización: agotar configuración antes de separar estructura
Un error frecuente en SaaS vertical es confundir personalización con estructura separada. Antes de separar datos, conviene agotar opciones de configuración bien diseñadas: catálogos, reglas declarativas, campos personalizados acotados, workflows configurables, permisos por rol y feature flags.
La regla práctica: separar estructura cuando la variación afecta garantías operativas, no solo preferencias.
Cinco preguntas para elegir el patrón correcto
¿Qué tan parecidos son los tenants? Si el modelo de datos será casi igual para todos, RLS puede ser suficiente.
¿Qué pasa cuando algo falla? Si un error global sería inaceptable, conviene introducir límites más fuertes para los tenants críticos.
¿Qué tan seguido cambia el modelo? Alta iteración → base compartida simplifica releases.
¿Cuál es la capacidad operativa del equipo? Schema-per-tenant exige tooling. Híbrido exige arquitectura clara. RLS exige disciplina de seguridad.
¿Qué esperan los clientes del vertical? Según el sector, algunos compradores valoran aislamiento, auditoría y recuperación más que velocidad de features.
Recomendación práctica para empezar
Para la mayoría de los SaaS verticales nuevos: empezar con diseño compartido con RLS si el dominio es uniforme, pero dejando preparada una ruta híbrida.
Desde el inicio conviene tener:
- Una entidad
tenantsólida. - Contexto de tenant obligatorio en cada request.
- Boundaries claros en repositorios o servicios.
- Migraciones versionadas.
- Tests que fallen si una consulta cruza tenants.
Esta arquitectura es parte del stack que usamos cuando construimos productos como los que describe crear software propio y venderlo. Si el software va a tener múltiples clientes, el multitenancy bien diseñado desde el inicio evita migraciones dolorosas cuando el negocio escala.
También vale la pena considerar la comparación Bubble vs desarrollo propio en este contexto: si construís en Bubble, el control de multitenancy queda delegado a la plataforma y fuera de tu alcance.
Cómo puede ayudarte solu30
En solu30 trabajamos con equipos que están construyendo o escalando SaaS B2B y verticales. Si tu producto empezó con una base compartida y ahora aparecen clientes con más exigencias, o si estás diseñando la arquitectura inicial y no querés encerrarte en una decisión frágil, podemos ayudarte a definir un modelo de multitenancy pragmático.
El trabajo no es solo elegir entre RLS o schema-per-tenant. Es diseñar aislamiento, migraciones, observabilidad, límites operativos y una ruta de evolución que acompañe ventas, soporte y producto. Contactanos en solu30.io.
Pasos concretos para validar un SaaS vertical antes de desarrollar:
- Identificá 10 potenciales clientes del nicho y pediles 30 minutos
- Mostrales el problema, no la solución: ¿lo reconocen?
- Presentá un mockup o flujo en papel y pedí feedback sobre precio
- Conseguí 3 pre-compromisos antes de escribir una línea de código
- Construí el MVP solo con las 2-3 funciones que los 3 validaron
Preguntas frecuentes
¿Cuál es la mejor estrategia de multitenancy para un SaaS vertical?
No hay una única mejor estrategia: depende del riesgo, volumen, regulación y tipo de clientes que atendés. En muchos SaaS verticales, el enfoque híbrido suele ser más práctico porque te permite compartir lo común y aislar lo que realmente necesita control operativo.
¿Cuándo conviene usar row-level security en una base compartida?
RLS conviene cuando tus tenants tienen un modelo de datos parecido, reglas estables y necesidades de aislamiento moderadas. Te ayuda a mantener costos bajos y operación simple, pero tenés que cuidar muy bien autorización, jobs internos, auditoría y pruebas de acceso.
¿Cuándo tiene sentido usar schema-per-tenant?
Schema-per-tenant tiene sentido cuando necesitás más aislamiento operativo, migraciones diferenciadas o restauración por cliente. También puede ayudarte con clientes enterprise que piden auditorías, ventanas de mantenimiento propias o configuraciones más complejas.
¿Qué significa usar un diseño híbrido de multitenancy?
Un diseño híbrido combina distintos niveles de aislamiento según el módulo, el cliente o el riesgo de los datos. Por ejemplo, podés tener datos comunes en tablas compartidas y separar workflows críticos, datos regulados o clientes grandes en schemas o bases dedicadas.
¿Qué error deberías evitar al diseñar multitenancy en SaaS?
El error más común es pensar solo en agregar un tenant_id a todas las tablas y dar el problema por resuelto. También necesitás pensar en backups, restauración, migraciones, monitoreo, permisos administrativos, webhooks y soporte cuando el sistema crezca.