SaaS multi-tenant: qué es y cuándo te conviene (frente a un sistema para un solo cliente)
20 de setembro de 2026 · 3 min de leitura · genbia
Single-tenant es un sistema para una empresa. Multi-tenant es un producto que varias empresas usan con sus datos separados, su marca a veces, y una sola base de código que tú operas. La diferencia no es un flag en Postgres. Es si tu negocio es un proyecto… o un software que se vende.
Definición corta
En multi-tenant cada cliente (tenant) ve solo lo suyo: usuarios, pedidos, configuración, facturación. El proveedor despliega una vez, parchea una vez y cobra por uso o por plan. En single-tenant cada cliente puede tener su instancia, su fork y su infierno de versiones.
Si tu caso es “esta clínica y nadie más”, no fuerces SaaS. Si tu caso es “voy a onboardear diez operaciones iguales”, el tenant es el producto.
Comparación
| Un cliente (a medida) | SaaS multi-tenant | |
|---|---|---|
| Encaje | Proceso único, regulado o muy raro | Mismo flujo, muchos clientes |
| Datos | Una base, un dueño | Aislamiento por tenant, auditorías |
| Billing | Proyecto / bolsa de horas | Planes, trials, límites |
| Roadmap | Lo que pide ese contrato | Lo que escala para todos |
| Costo de cada cliente nuevo | Alto (otro proyecto) | Onboarding, no reescritura |
Cuándo sí
- Ya vendiste (o vas a vender) el mismo panel a más de un cliente.
- El diferenciador es el producto, no el consultor embebido.
- Necesitas métricas de producto: activación, churn, uso por tenant.
- Puedes decir que no a un custom que rompe el modelo.
La plataforma delivery white label es este patrón: una base, muchas marcas. El CRM WhatsApp también: varios equipos, una plataforma.
Cuándo no
- Un solo dueño y un proceso que cambia cada trimestre.
- Requisitos de residencia de datos que exigen instancia dedicada.
- El primer cliente exige un fork “porque somos especiales” y no hay segundo cliente.
Ahí el camino es software a medida, no un SaaS a medias que luego no puedes vender.
Lo que hay que diseñar el día uno (aunque el MVP sea flaco)
- Identidad del tenant. Empresa, no usuario suelto.
- Permisos. Admin del tenant vs staff vs tú como operador.
- Límites. Qué pasa si un tenant satura la API.
- Backups y borrado. Un cliente se va: qué se elimina y qué queda en logs.
- Onboarding. Crear tenant no puede ser un ticket de ingeniería cada vez.
La IA y n8n, si entran, se cuelgan por tenant (claves, WhatsApp, webhooks). Un workflow global que mezcla clientes es un incidente de privacidad.
Cómo lo enfocamos
No empezamos por “arquitectura de FAANG”. Empezamos por: ¿cuántos tenants en 12 meses y qué no pueden ver entre ellos? Con eso se elige esquema, billing y el recorte del MVP.
GENBIA diseña SaaS multi-tenant cuando el negocio es el producto. Si el negocio es un sistema para una operación, construimos a medida y no fingimos un marketplace.