Single-tenant DB-por-cliente: lo que ganamos vs lo que sacrificamos

Cuando arrancamos Suite HUB en 2024, la primera gran decisión arquitectónica fue: single-tenant DB-por-cliente o multi-tenant compartido. Elegimos single-tenant, y dos años después sigo pensando que fue la decisión correcta — pero con costos reales que es honesto reconocer.

El contexto#

Nuestro cliente típico es una PYME panameña: un taller mecánico, una lavandería, un restaurante, un consultorio veterinario. Tamaños de 1–5 sucursales, 3–30 usuarios, volúmenes de datos manejables (decenas de miles de transacciones/año, no millones).

Para ese segmento, la pregunta no es “¿cómo escalo a 10 millones de tenants?” sino “¿cómo entrego un sistema confiable con el menor riesgo posible?”.

Lo que decidimos#

Una base de datos por instalación cliente. Cada cliente tiene:

• Su propia BD SQLite (HUB Lite/Core) o MySQL (HUB Pro)
• Su propia carpeta en el servidor con su config.php
• Su propio dominio o subdominio
• Su propio set de usuarios, módulos, configuración

Multi-sucursal vive dentro del tenant, no como tenant compartido. Un cliente con 3 locales tiene una BD con 3 sucursales como entidades, no 3 BDs separadas.

Lo que ganamos#

1. Aislamiento total de seguridad#

Si comprometen un cliente, los demás no se enteran. Cero riesgo de query mal filtrado que exponga data de tenant ajeno. La superficie de ataque para una catástrofe multi-cliente es virtualmente cero.

Esto es enorme para clientes con data sensible (médica, fiscal, financiera).

2. Personalización agresiva sin riesgo cruzado#

Cada instalación puede tener módulos custom, integraciones específicas, modificaciones de UI, sin afectar a nadie más. Cuando un cliente pide “necesito un campo extra en la factura”, lo añadimos sin pensar dos veces.

En multi-tenant compartido, ese tipo de custom obliga a feature flags, condicionales, toda una capa de complejidad que se acumula.

3. Backup, restore, migración trivial#

Restaurar un cliente es copiar un archivo SQLite o un dump MySQL. Migrar de un servidor a otro es scp + tres archivos de config. Si un cliente quiere su data para auditoría legal, le entrego el .sqlite y se la lleva.

4. Performance predecible#

La BD de cada cliente tiene su propio cache, su propio storage, sus propios índices. Un cliente con consultas pesadas no degrada a otro. No hay “vecino ruidoso”.

5. Compliance simplificado#

Para DGI Panamá (facturación electrónica), tener la data de cada contribuyente físicamente separada simplifica auditorías y certificaciones. Lo mismo aplicaría para HIPAA, GDPR, normas bancarias.

Lo que sacrificamos#

1. Operación de “actualización masiva” más compleja#

Cuando sale una nueva versión, no es UPDATE a una BD — es un script que itera por cada instalación, valida estado, aplica migración. Construimos un sistema de auto-migration que corre al arrancar cada cliente, pero requiere disciplina.

2. Analíticas cruzadas requieren extracción#

No puedo correr una query “muéstrame el promedio de facturas/día de todos mis clientes” en una sola BD. Requiere job que extrae métricas anonimizadas de cada tenant hacia una BD analítica separada. Más infraestructura.

3. Costo por cliente más alto#

Cada instalación consume su slice de RAM, disco, conexiones. Para una PYME de 5 usuarios eso es despreciable, pero para una hipotética cuenta con 10,000 clientes nuestro stack no escalaría linealmente como lo haría un multi-tenant compartido.

4. Onboarding más involucrado#

Crear un nuevo cliente no es INSERT INTO tenants — es provisión de BD, config, dominio, primer usuario admin. Tenemos un script que lo automatiza, pero sigue siendo más complejo que un signup self-service.

Por qué seguiría eligiendo lo mismo#

Para el segmento que servimos, los beneficios pesan más:

• Equipo pequeño → menos cosas pueden romper a todos
• Clientes con data sensible → aislamiento es valor
• Personalización es ventaja competitiva → multi-tenant la complicaría
• Volumen objetivo modesto (cientos, no miles) → el costo extra es asumible

Si construyera una SaaS B2C consumer con 100K usuarios free, claro que iría multi-tenant. Pero no es lo que somos.

Cuándo SÍ pivotamos#

Para HUB Enterprise (futuro, para cadenas / franquicias con decenas de sucursales), estamos evaluando un híbrido: multi-tenant compartido con particionamiento lógico estricto, porque la lógica de cadena requiere consolidación nativa que single-tenant complica.

Pero eso es una edición distinta, no un cambio de la arquitectura base.

Conclusión#

“Single-tenant vs multi-tenant” no es una decisión técnica universal — es una decisión de modelo de negocio. Conoce tu cliente, conoce tu volumen, conoce tu equipo. La elección correcta es la que te permite dormir tranquilo y mover rápido sobre lo que importa, no la que se ve mejor en una arquitectura de pizarrón.