Construir software B2B implica casi siempre servir a múltiples clientes desde una sola base de código. La pregunta no es si multi-tenant, sino cómo aislar a cada cliente para que un bug, una consulta pesada o una mala configuración no afecte al resto. Los tres patrones dominantes resuelven esto de manera distinta.
1. Base de datos compartida, esquema compartido
Todos los clientes comparten la misma tabla. Las filas se filtran por un campo tenant_id. Es el patrón más eficiente en costo y el más arriesgado: una sola consulta mal escrita puede filtrar datos entre clientes.
Conviene cuando los clientes son pequeños, los volúmenes son bajos y el equipo de desarrollo es chico. No conviene cuando hay datos sensibles, regulación fuerte o clientes grandes con SLA dedicado.
2. Base de datos compartida, esquema por cliente
Misma instancia de base de datos, pero cada cliente tiene su propio esquema. Mejor aislamiento, mayor costo operativo por la proliferación de esquemas, y migraciones más complejas porque hay que correrlas N veces.
Conviene cuando los clientes tienen modelos de datos ligeramente distintos o cuando se necesita cierta personalización. Pierde sentido cuando los esquemas terminan siendo idénticos al 95%.
3. Base de datos por cliente
Cada cliente tiene su propia base de datos. Máximo aislamiento, máxima claridad operacional, máximo costo. Permite mover clientes problemáticos a instancias dedicadas sin tocar el resto.
Conviene cuando hay pocos clientes grandes, cuando el SLA exige aislamiento físico o cuando hay regulación que lo exige (banca, salud, gobierno).
Criterios prácticos para elegir
- Menos de 20 clientes pequeños: esquema compartido.
- Entre 20 y 200 clientes con necesidades similares: esquema por cliente.
- Más de 200 clientes, todos con el mismo modelo: esquema compartido con políticas estrictas de row-level security.
- Pocos clientes grandes con SLA dedicado: base de datos por cliente.
Errores frecuentes
- Empezar con esquema compartido y migrar tarde, cuando ya hay cientos de clientes.
- Creer que el aislamiento por aplicación (middleware que filtra por
tenant_id) es suficiente. No lo es: cualquier bug en la capa de aplicación rompe el aislamiento. - Olvidar las copias de seguridad por cliente. En esquema compartido, restaurar un cliente implica restaurar a un punto anterior y reconciliar el resto.
Cierre
Multi-tenant no es una decisión técnica aislada. Es una decisión comercial disfrazada de técnica: define cuánto cuesta atender a un cliente más, cuánto cuesta sacarlo, y qué tan rápido se puede mover entre planes.
En CodeHub diseñamos la arquitectura multi-tenant de cada producto B2B junto con el modelo comercial, no antes.