Arquitectura multi-tenant: la forma correcta de aislar los datos del cliente
Una guía práctica sobre los compromisos entre los modelos silo, bridge y pool, y por qué Row-Level Security suele ser la mejor elección.
Los productos SaaS multi-tenant obligan a tomar una decisión fundamental desde el primer día: ¿cómo se aislarán los datos de cada cliente? Una mala decisión aquí puede crear problemas de cumplimiento, dificultades de escalado y, en el peor de los casos, fugas de datos entre tenants.
El modelo silo entrega una base de datos física separada a cada tenant. Ofrece el aislamiento más fuerte y hace muy sencillas las copias y restauraciones por cliente, pero también eleva el coste de infraestructura y complica enormemente los cambios de esquema.
El modelo bridge coloca múltiples esquemas de tenant dentro de la misma instancia de base de datos. Reduce costes y mejora la separación, pero el modelo operativo puede volverse incómodo cuando el número de esquemas crece o el motor empieza a resentirse por demasiadas tablas.
El modelo pool mantiene todos los tenants en las mismas tablas y separa los registros con una columna tenant_id. Es el enfoque más escalable y rentable, aunque también introduce el mayor riesgo a nivel de aplicación: un bug en una consulta puede exponer datos de otro cliente si el aislamiento no se aplica con rigor.
Por eso muchos equipos modernos de SaaS B2B usan tablas compartidas combinadas con Row-Level Security. Las políticas definidas en la base de datos bajan el aislamiento al nivel de persistencia y reducen la posibilidad de que un fallo de aplicación devuelva registros de otro tenant.
La mejor elección sigue dependiendo de requisitos regulatorios, segmentación de clientes y madurez operativa. Aun así, para muchos productos SaaS actuales, el modelo pool con Row-Level Security ofrece el equilibrio más sólido entre seguridad, coste y escala.