Elegir cómo almacenar los datos de cada cliente es una decisión de arquitectura con consecuencias en seguridad, operación y evolución del producto. En un SaaS multiempresa, no basta con que cada usuario vea una interfaz distinta: el sistema debe controlar qué datos puede consultar y modificar cada cliente, incluso ante errores de código, tareas en segundo plano o cambios de configuración.
No existe un modelo universalmente mejor. Una base compartida puede simplificar la operación, mientras que una base dedicada puede facilitar ciertos requisitos de aislamiento, pero también multiplica tareas y costes operativos. La decisión adecuada depende del riesgo que se quiere reducir, de los compromisos con los clientes y de la capacidad real del equipo para operar la arquitectura.
Qué significa aislar los datos por cliente
El aislamiento de datos, o multitenencia, consiste en separar lógicamente la información de cada organización dentro de un servicio compartido. El tenant suele ser una empresa cliente, aunque el modelo de negocio puede definir otra unidad. La aplicación debe asociar cada petición, proceso y dato a un tenant autorizado y hacer cumplir esa relación de forma coherente.
Separar almacenamiento no resuelve automáticamente todos los riesgos. Una autorización incorrecta puede permitir que un usuario acceda a funciones de otro cliente; un registro exportado o un sistema de analítica puede exponer datos aunque la base principal esté bien segmentada. También deben considerarse copias de seguridad, registros, cachés, archivos, integraciones y entornos de soporte.
Por eso, la pregunta útil no es solo dónde guardar los datos, sino qué controles impiden el acceso cruzado y cómo se comprueba que funcionan. La arquitectura de almacenamiento es una capa de esa estrategia, no un sustituto de la autenticación, la autorización, la revisión de código o la gestión segura de operaciones.
Tres modelos habituales de almacenamiento
Base de datos compartida
Todos los clientes usan la misma base de datos y, a menudo, las mismas tablas. Cada registro incorpora un identificador de tenant y las consultas deben filtrar por él. Este modelo suele reducir la complejidad de aprovisionamiento y facilita aplicar cambios de esquema una sola vez. Es una opción razonable cuando el producto está empezando, los requisitos son similares entre clientes y el equipo puede establecer controles fiables.
Su principal riesgo es que una consulta o proceso olvide el filtro. La consecuencia puede ser una lectura o modificación entre clientes. Además, los clientes comparten recursos: una carga intensa de una empresa puede afectar a otras si no se gestiona la capacidad.
Esquema separado por cliente
Una base de datos aloja varios esquemas, uno por cliente, con tablas similares. La separación puede hacer más visible la frontera entre conjuntos de datos y permite ciertas operaciones por cliente. Sin embargo, no elimina el riesgo de errores de enrutamiento ni garantiza aislamiento de recursos. Las migraciones y herramientas deben recorrer los esquemas de forma consistente; con muchos clientes, administrar versiones y excepciones puede volverse difícil.
Base de datos dedicada
Cada cliente, o un grupo pequeño de clientes, tiene una base de datos propia. Esto puede facilitar la ubicación de datos, las restauraciones selectivas y el cumplimiento de requisitos contractuales que demanden recursos o límites de acceso diferenciados. También puede reducir el impacto de una carga o incidente en otros clientes, según cómo estén desplegados los servicios.
El coste es operativo: aprovisionar, actualizar, supervisar, respaldar y probar muchas bases requiere automatización y capacidad del equipo. Una base dedicada tampoco protege frente a permisos excesivos, credenciales comprometidas o errores en la aplicación. Hay que verificar qué aislamiento ofrece realmente la plataforma elegida.
Criterios para decidir
Evalúa los modelos con los requisitos concretos del producto, no con una preferencia abstracta por la separación. Documenta tanto las necesidades actuales como los compromisos que probablemente afecten la evolución.
- Riesgo de acceso cruzado: identifica qué datos son sensibles, qué actores acceden a ellos y dónde puede perderse el contexto del tenant. Define controles preventivos y pruebas negativas que intenten acceder a datos ajenos.
- Requisitos del cliente: comprueba obligaciones contractuales, necesidades de residencia, retención, restauración o auditoría. No interpretes una petición de “base dedicada” como requisito legal sin validarla con las áreas responsables.
- Operación: estima el trabajo de despliegues, copias de seguridad, restauración, observabilidad, soporte y gestión de incidencias. Considera si el equipo puede automatizarlo de manera repetible.
- Variabilidad del producto: clientes con versiones, extensiones o políticas muy distintas pueden requerir límites más claros. Aun así, evitar una plataforma común puede crear divergencias difíciles de mantener.
- Coste de cambio: pregunta cómo moverías un cliente, cómo validarías los datos trasladados y cuánto tiempo podría durar una transición. Una decisión inicial simple es más segura si no bloquea alternativas futuras.
Una matriz de decisión ayuda a hacer explícitas las compensaciones. Puntúa cada opción frente a requisitos verificables, y separa los criterios obligatorios de los deseables. Si un cliente exige una condición que el modelo compartido no puede cumplir, esa restricción debe pesar más que una preferencia general por la simplicidad.
Controles para un modelo compartido
Si eliges una base compartida, trata el identificador de tenant como parte esencial del diseño. Debe obtenerse de una identidad y un contexto validados por el servidor, no confiarse a un valor arbitrario enviado por el navegador. Las capas de acceso a datos deben recibir ese contexto de manera consistente y evitar consultas sin alcance de tenant.
Establece controles en más de una capa cuando la tecnología lo permita: restricciones de base de datos, permisos acotados, políticas de acceso y validaciones en la aplicación. No los consideres intercambiables; comprueba cuáles aplican en tus procesos, conexiones y tareas administrativas. Para procesos asíncronos, colas y tareas programadas, transmite y valida el tenant de forma explícita.
Incluye pruebas automatizadas que creen al menos dos tenants y comprueben lecturas, escrituras, búsquedas, exportaciones y operaciones de soporte. Añade revisiones para nuevas consultas y mide señales como errores de autorización, consultas sin contexto y trabajos fallidos. Los registros deben ayudar a investigar incidentes, pero no exponer datos sensibles innecesarios.
Cuándo adoptar un enfoque híbrido
Un modelo híbrido combina una base compartida para la mayoría y almacenamiento separado para clientes que lo justifiquen. Puede ser útil cuando existe una diferencia demostrable en requisitos, volumen, residencia o aislamiento. También permite empezar con una operación común y reservar recursos específicos donde aporten valor.
Define reglas de asignación antes de hacer excepciones: qué requisito habilita una base dedicada, quién aprueba el cambio, cómo se calcula el coste y qué soporte se ofrece. Mantén un mecanismo común para identificar la ubicación de cada tenant y evita que la lógica de negocio dependa de nombres o direcciones de bases de datos. Sin criterios claros, el enfoque híbrido se convierte en una colección de casos especiales.
Diseñar para migrar y tomar una decisión revisable
Desde el inicio, separa la identidad del tenant de su ubicación física. Usa una capa de acceso que pueda dirigir operaciones al almacén correcto, y automatiza el aprovisionamiento y las migraciones. Mantén cambios de esquema compatibles durante las transiciones cuando sea posible, y define cómo verificar recuentos, integridad y permisos antes de habilitar el destino.
Una migración puede requerir copiar datos, detener escrituras o sincronizar cambios y cambiar el enrutamiento. El procedimiento depende de la tecnología y de los requisitos de continuidad: ensáyalo, define una estrategia de reversión y comunica el impacto esperado. No presupongas que mover una base dedicada es siempre más sencillo; el volumen, las dependencias y la consistencia determinan la dificultad.
Antes de cerrar la decisión, responde estas preguntas por escrito:
- ¿Qué unidad representa un tenant y de dónde procede su contexto?
- ¿Qué requisitos son obligatorios y cuáles son preferencias negociables?
- ¿Qué controles detectan y bloquean accesos entre clientes?
- ¿Quién opera respaldos, restauraciones, despliegues y excepciones?
- ¿Qué señales justificarían cambiar de modelo y cómo se ejecutaría la migración?
Elige el modelo que cumpla los requisitos con una operación que el equipo pueda sostener. Revisa la decisión cuando cambien los clientes, el riesgo o las capacidades de la plataforma. El aislamiento adecuado no es el más complejo: es el que ofrece controles comprobables y puede operarse de forma consistente.