Cuando una aplicación SaaS comienza a crecer, uno de los primeros dilemas técnicos que aparecen es cómo aislar los datos de cada cliente. La decisión entre un esquema compartido con control de acceso por filas (RLS) o un esquema separado por inquilino no solo afecta al rendimiento, sino también a la estrategia de migraciones, copias de seguridad y cumplimiento normativo. En Q2BSTUDIO, como empresa especializada en desarrollo de software a medida, hemos analizado este problema en profundidad para nuestros clientes que despliegan soluciones en la nube con AWS o Azure, integran inteligencia artificial, protegen sus datos con ciberseguridad avanzada y utilizan herramientas de BI como Power BI. Este artículo plantea un análisis técnico y empresarial para que puedas elegir el modelo adecuado desde el inicio.
El modelo de esquema compartido con Row-Level Security (RLS) es el punto de partida más común. Consiste en añadir una columna tenant_id a cada tabla y activar políticas RLS en PostgreSQL que filtren automáticamente las filas según el contexto del inquilino. La principal ventaja es la simplicidad operativa: una sola migración, un único conjunto de índices y la posibilidad de realizar consultas cruzadas entre todos los clientes sin complejidad adicional. Además, el pool de conexiones funciona de forma natural y el aislamiento se garantiza a nivel de base de datos, no de aplicación. Para proyectos con un número incierto de inquilinos y cargas de trabajo homogéneas, esta aproximación es la más ágil. Sin embargo, hay que tener cuidado: si no se fuerza el RLS con FORCE ROW LEVEL SECURITY, el propietario de la tabla podría eludir las políticas. También es fundamental establecer el contexto de inquilino dentro de una transacción usando set_config con alcance local para evitar fugas entre peticiones cuando se utiliza PgBouncer en modo transaccional. En nuestros servicios cloud AWS/Azure implementamos estas prácticas para garantizar la seguridad desde el primer día.
El modelo de esquema por inquilino (schema-per-tenant) asigna un esquema PostgreSQL independiente a cada cliente. Las tablas son idénticas en estructura, pero los datos están físicamente separados. Esto simplifica el código de la aplicación, ya que no es necesario escribir cláusulas WHERE tenant_id = ? ni mantener políticas RLS. La restauración de un solo inquilino es trivial: basta con recuperar el esquema desde una copia de seguridad. Además, se pueden añadir columnas o índices personalizados sin afectar a otros clientes, lo que resulta útil en entornos empresariales con requisitos de cumplimiento como el GDPR. No obstante, la complejidad operativa crece rápidamente: cada migración debe ejecutarse en todos los esquemas, lo que con decenas de miles de inquilinos se convierte en un problema de planificación. El catálogo de PostgreSQL se infla con miles de objetos, degradando el rendimiento del planificador. Además, las consultas transversales entre inquilinos requieren uniones explícitas o una capa de agregación externa. Por eso, este modelo es adecuado cuando el número de clientes es predecible y acotado (decenas o unos pocos centenares), y cuando se necesita un aislamiento que el cliente pueda percibir como “separado”.
Existe una tercera opción, la base de datos por inquilino, que ofrece el máximo aislamiento físico. Cada cliente tiene su propia base de datos, incluso servidor dedicado. Esto permite cumplir requisitos de residencia de datos (por ejemplo, almacenar en una región concreta de Azure o AWS), realizar actualizaciones independientes y restaurar sin afectar a nadie más. Sin embargo, la sobrecarga operativa es enorme: un pool de conexiones por base de datos, migraciones orquestadas de forma independiente y la imposibilidad de realizar consultas SQL entre inquilinos. Solo recomendamos este enfoque para contratos empresariales de alto valor donde el coste no es un factor limitante.
Para ayudarte a decidir, aquí tienes una matriz comparativa:
Criterio – Esquema compartido + RLS / Esquema por inquilino / Base de datos por inquilinoNúmero de inquilinos: cientos a millones / decenas a pocos miles / decenasComplejidad de migraciones: baja (una única ejecución) / media (una por esquema) / alta (por base de datos)Radio de explosión en caso de error: alto (todos los inquilinos) / medio (límite del esquema) / bajo (una base de datos)Restauración individual: difícil / directa / trivialConsultas transversales: SQL fácil / engorroso / solo por APIRiesgo de vecino ruidoso: alto / medio / ningunoBaja por GDPR: DELETE múltiples tablas / DROP SCHEMA / DROP DATABASEAislamiento físico: no / no / síPool de conexiones: simple / requiere cuidado / complejoPersonalización por inquilino: difícil / posible / control total
Cuándo empezar con esquema compartido y RLS: si estás desarrollando un MVP sin conocer la evolución del número de clientes, si todos tienen cargas similares y necesitas analíticas transversales con facilidad. Es la opción que mantiene más puertas abiertas y permite migrar más adelante si es necesario.
Cuándo pasar a esquema por inquilino: cuando el número de clientes sea estable y acotado, cuando vendas a empresas que exijan una separación clara de datos o cuando necesites restaurar un inquilino concreto sin complicaciones. La migración desde esquema compartido se puede hacer inquilino a inquilino, con un periodo de doble escritura y verificación de integridad mediante comparación de “checksums”. En nuestros proyectos de BI con Power BI a menudo recomendamos este modelo para garantizar la confidencialidad de los datos por cliente.
Cuándo optar por base de datos por inquilino: si tienes clientes empresariales con contratos que exigen residencia de datos en regiones específicas, o si el producto es una infraestructura donde cada cliente espera recursos dedicados. El coste y la complejidad operativa solo se justifican en estos casos.
En Q2BSTUDIO sabemos que elegir el modelo de aislamiento adecuado desde el principio ahorra semanas de trabajo posterior. Nuestro equipo integra estas decisiones con soluciones de inteligencia artificial, agentes de IA, ciberseguridad y automatización de procesos. Tanto si trabajas en AWS como en Azure, te ayudamos a diseñar una arquitectura multi-tenant que crezca contigo.
