Multi-tenencia SaaS: elige el modelo correcto de aislamiento de datos

INTRODUCTION

Empieza por el requisito de aislamiento, no por la base de datos

El modelo de multi-tenencia SaaS adecuado es el que encaja con los límites reales de tu producto, tu capacidad operativa y el riesgo de cambios futuros. Para la mayoría de los MVP, la decisión no es “¿qué modelo es mejor?”, sino “¿cuánto aislamiento necesitamos ahora y qué será doloroso cambiar después?”.

Una forma práctica de plantearlo: si los tenants se diferencian sobre todo por la propiedad de los datos y los permisos, un diseño de tablas compartidas con autorización explícita por tenant puede ser suficiente para empezar. Si prevés una separación más fuerte entre clientes, una mayor carga administrativa o controles operativos por tenant, los esquemas o bases de datos separadas pueden tener sentido. Ninguna de estas opciones garantiza la seguridad por sí sola; la aplicación sigue necesitando autorización del lado del servidor y pruebas cuidadosas.

Si estás planificando desarrollo web a medida para un producto SaaS, esta suele ser una de las primeras decisiones arquitectónicas que debes tomar. También afecta a cómo defines el discovery, construyes el MVP y planificas futuras migraciones. Para los equipos que trabajan con un estudio de producto, merece la pena hablarlo junto con decisiones de arquitectura más amplias en desarrollo web y la definición del MVP.

Compara los tres modelos comunes de aislamiento de datos

Aquí tienes una comparación sencilla para fundadores y responsables de producto que están evaluando un MVP SaaS:

Tablas compartidas

Las tablas compartidas suelen ser la vía más rápida para un MVP. Mantienen el esquema compacto y simplifican la iteración del producto porque todas las funcionalidades trabajan contra un único modelo de datos. A menudo es la opción adecuada cuando los primeros clientes son pocos, el modelo de permisos es sencillo y necesitas validar el producto antes de añadir complejidad operativa.

La desventaja también es clara: un error al filtrar por tenant puede exponer o modificar datos entre clientes. Eso significa que el modelo depende mucho de un código de aplicación disciplinado y de reglas de base de datos.

Si usas PostgreSQL con Supabase, la seguridad a nivel de fila puede ayudar a aplicar reglas de acceso en la capa de base de datos, pero sigue siendo solo una capa de defensa; la aplicación debe pasar correctamente el contexto del tenant y usar lógica explícita de autorización. La guía de Supabase sobre row-level security explica cómo las políticas de RLS controlan el acceso a nivel de fila.

Esquemas separados

Los esquemas crean un punto intermedio. Mantienes una sola base de datos, pero los datos de cada tenant viven en su propio espacio de nombres. Esto puede hacer más claros ciertos trabajos operativos, especialmente cuando quieres un límite más visible entre clientes sin gestionar una base de datos por tenant.

La contrapartida es la complejidad. Las migraciones se vuelven más difíciles porque cada esquema necesita los mismos cambios estructurales. Los informes y análisis entre tenants también pueden resultar más engorrosos. Para los equipos de producto, este modelo suele encajar cuando el número de tenants es limitado o cuando algunos clientes necesitan una separación más estricta de la que resulta cómoda con un diseño de tablas compartidas.

Bases de datos separadas

Las bases de datos separadas ofrecen catálogos de datos distintos. Pueden compartir un mismo servidor: el aislamiento físico depende del alojamiento y del despliegue. Eso puede ser útil cuando los tenants son grandes, tienen expectativas de cumplimiento diferentes o necesitan aislamiento por motivos operativos. También puede reducir el radio de impacto de un error en el entorno de un cliente.

El coste es la sobrecarga de gestión. Ahora tienes más copias de seguridad, más migraciones, más monitorización y más decisiones operativas. Para un MVP, esto puede ralentizar la entrega salvo que el caso de negocio justifique claramente esa complejidad.

Mantén explícitos los límites de tenant en la aplicación

Sea cual sea el modelo de aislamiento que elijas, el sistema debe hacer explícita la pertenencia a un tenant. No dependas del estado del front-end, de URLs ocultas ni de la última acción de un usuario para inferir el acceso.

Una base práctica es:

1. El usuario inicia sesión.
2. El servidor determina a qué tenants pertenece ese usuario.
3. La petición se autoriza en un contexto concreto de tenant.
4. Todo acceso a datos se filtra según ese contexto de tenant.
5. Los trabajos en segundo plano, exportaciones y operaciones de búsqueda usan el mismo límite de tenant.

Ese último punto importa. Los errores entre tenants suelen aparecer fuera del flujo principal de petición/respuesta: en exportaciones CSV, indexación de búsqueda, trabajos en cola, tareas programadas o herramientas administrativas. Si esas rutas no aplican las mismas reglas, el modelo de aislamiento se vuelve inconsistente.

Aquí es donde la autorización del lado del servidor importa más. No se puede confiar en que un cliente decida a qué tenant puede acceder. El servidor debe aplicar membresía y permisos antes de cualquier lectura o escritura sensible.

Si también estás diseñando la experiencia de producto en torno a espacios de trabajo o portales de clientes, puede ayudar revisar cómo la multi-tenencia afecta al UX y a la arquitectura de la información en un portal de cliente o plataforma SaaS. Ese tipo de proyecto suele combinar diseño de producto con límites arquitectónicos.

Un marco de decisión concreto

Usa esta lista para elegir el modelo más pequeño que encaje con tus necesidades:

Elige tablas compartidas si:

• Estás construyendo un MVP y necesitas avanzar rápido.
• Todos los tenants usan el mismo esquema base.
• Tu equipo puede mantener explícita la autorización por tenant en el código y en las reglas de base de datos.
• Estás preparado para probar cada flujo de datos en busca de fugas entre tenants.

Elige esquemas separados si:

• Quieres una separación más clara sin la sobrecarga de muchas bases de datos.
• Esperas que la administración específica por tenant cobre importancia.
• Puedes gestionar migraciones repetidas y la consistencia de esquemas.
• Tienes un motivo para separar los datos lógicamente, pero no del todo operativamente.

Elige bases de datos separadas si:

• Los clientes requieren una separación operativa u organizativa más fuerte.
• Esperas que los entornos de los tenants diverjan.
• Puedes asumir el coste de migración y mantenimiento.
• El producto justifica la complejidad añadida desde el principio.

Una regla útil: prefiere el modelo más simple que siga encajando con las necesidades de tus clientes y de tu operación. Reestructura más adelante solo cuando el modelo actual empiece a generar fricción real, no una incomodidad hipotética.

Ejemplo hipotético: un portal de clientes con varios espacios de trabajo

Imagina un producto SaaS B2B en el que cada empresa cliente tiene un espacio de trabajo, y cada espacio de trabajo tiene muchos usuarios. La aplicación necesita compartir documentos, mostrar feeds de actividad y generar exportaciones.

Un diseño razonable para el MVP podría usar tablas compartidas con un tenant_id en cada tabla perteneciente al tenant. Los usuarios pertenecen a uno o varios espacios de trabajo mediante una tabla de membresías. Cada petición verifica en el servidor la membresía del usuario antes de leer o escribir datos. Se puede usar RLS para reforzar las restricciones a nivel de fila en la base de datos.

Ahora considera los modos de fallo:

• Un usuario adivina el ID de otro espacio de trabajo en la URL.
• Un endpoint de informes exporta filas sin aplicar filtros por tenant.
• Un trabajo en segundo plano indexa registros de todos los tenants en un único espacio de búsqueda.
• Una pantalla de administración lee el tenant incorrecto porque confía en la entrada del cliente.

La arquitectura no es incorrecta porque existan estos riesgos; solo lo sería si no los abordara. Las tablas compartidas pueden funcionar muy bien aquí si la aplicación aplica de forma consistente una autorización consciente del tenant y prueba los puntos de riesgo.

Prueba el límite, no solo el camino feliz

En multi-tenencia SaaS, las pruebas negativas son tan importantes como las positivas. Quieres demostrar que el sistema deniega el acceso cuando debe hacerlo.

Casos de prueba útiles incluyen:

• Lecturas entre tenants: un usuario del tenant A no puede leer registros del tenant B.
• Escrituras entre tenants: un usuario del tenant A no puede actualizar registros del tenant B.
• Búsqueda: el tenant A no puede ver contenido del tenant B en los resultados de búsqueda.
• Exportación: las exportaciones CSV o PDF incluyen solo los datos del tenant activo.
• Trabajos en segundo plano: las tareas en cola procesan solo los registros del tenant previsto.
• Herramientas de administración: los usuarios internos también necesitan reglas claras para cambiar de tenant y definir el alcance de acceso.

Cuando uses RLS, prueba la cadena completa de la petición, no solo una consulta directa a la base de datos. RLS puede ayudar en la capa de base de datos, pero tu API, los workers de tareas y las herramientas administrativas siguen necesitando el contexto correcto del tenant.

Cuándo revisar la arquitectura

No necesitas sobredimensionar el modelo inicial, pero sí necesitas disparadores claros para el cambio. Revisa la arquitectura cuando veas una o varias de estas señales:

• Las migraciones se están volviendo difíciles de aplicar de forma segura entre tenants.
• Uno o varios clientes necesitan una separación más fuerte de la que ofrece el modelo actual.
• La configuración específica por tenant está creciendo hasta convertirse en una divergencia estructural.
• Los trabajos en segundo plano, la búsqueda o las exportaciones se están volviendo difíciles de mantener seguros por tenant.
• El equipo está dedicando demasiado tiempo a defender el modelo actual en lugar de entregar valor de producto.

Ese es el momento en que un MVP con tablas compartidas puede evolucionar hacia esquemas o bases de datos, o en que una configuración basada en esquemas puede necesitar una separación operativa mayor.

Planifica el siguiente paso

Para la mayoría de fundadores y responsables de producto, la forma práctica más segura es empezar con el modelo más simple que siga haciendo explícita la propiedad del tenant, y luego hacer cumplir los límites en el servidor, la base de datos y la suite de pruebas.

Una buena lista de lanzamiento es:

• Define la membresía de tenant y las reglas de autorización antes de implementar.
• Elige un modelo de aislamiento de datos y documenta por qué.
• Haz explícito el contexto del tenant en cada ruta de petición.
• Añade pruebas negativas para lecturas, escrituras, búsqueda, exportaciones y trabajos.
• Revisa si RLS o reglas similares de base de datos pueden reforzar, no sustituir, la autorización de la aplicación.
• Define disparadores de migración para saber cuándo reconsiderar la arquitectura.

Si estás planificando un MVP SaaS y quieres ayuda para elegir entre tablas compartidas, esquemas o bases de datos separadas, podemos analizar juntos el producto, el modelo de datos y el alcance del lanzamiento. Inicia la conversación : hablar de tu proyecto.