Backend SaaS multi-tenant: patrones y stack
Un SaaS B2B serio casi siempre necesita multi-tenant: varias organizaciones cliente, datos aislados, facturación por suscripción, roles por org y límites por plan. No hace falta microservicios el día uno; sí un modelo de datos claro y un sistema de auth que entienda organizaciones. Cambiar de monotenant a multi-tenant después es de los refactors más caros que existen: planificar bien al inicio te ahorra 3-6 meses de deuda técnica.
1. El diagnóstico: qué decisiones bloquean tu SaaS
Cuatro decisiones marcan el resto del producto durante años: estrategia de aislamiento (row-level vs schema vs DB por tenant), proveedor de auth multi-org, modelo de facturación (flat, seat-based, usage-based) y estrategia de migraciones. Equivocarse en cualquiera obliga a reescribir media base de código en seis meses.
La buena noticia: para el 90% de SaaS B2B la combinación correcta es predecible. Row-level con tenant_id + RLS de PostgreSQL, Clerk o Auth0 para auth con organizaciones, Stripe Billing con webhooks, migraciones expand-contract. Microservicios y Kubernetes el día 1 son anti-patrón: monolito modular en Node.js o Python con Postgres aguanta perfectamente los primeros 1000 tenants.
2. Estrategias de multi-tenancy (cuándo cada una)
- Row-level (tenant_id en cada tabla): el 90% de SaaS B2B. Una sola DB, todas las queries filtran por
tenant_id. Con PostgreSQL RLS (Row Level Security) evitás fugas si alguien olvida un WHERE. Mínimo coste operativo, escala a miles de tenants. - Schema por tenant: cuando necesitás personalización fuerte (columnas extra por cliente) o compliance específico. Una DB, N schemas; cada tenant tiene sus tablas. Más complejidad en migraciones (N veces) y backups.
- DB por tenant: solo enterprise (banca, salud) o cuando el contrato exige aislamiento físico. Máxima seguridad y rendimiento, pero coste operativo alto: backups, migraciones, monitorización y deploy son N veces más caros.
- Híbrido: plan free/pro en DB compartida (row-level), enterprise en DB dedicada. Funciona si tenés un buen abstraction layer en la capa de datos desde el inicio.
3. Auth, billing y entitlements
- Auth multi-org: Clerk (mejor DX, organizations + invitations out-of-the-box), Auth0 (más maduro, B2B SSO sólido pero caro al crecer), WorkOS (enterprise SSO/SCIM), Supabase Auth (gratis si ya lo usás, multi-org manual). Sesiones/JWT con claims de organización activa, invitaciones por email, roles (owner, admin, member, viewer).
- Stripe Billing: Customer = tenant, no usuario. Products = planes (Free/Pro/Enterprise), Prices mensual/anual. Subscription al plan + metered usage para consumo (API calls, GB). Webhooks de
invoice.paid,customer.subscription.updatedycustomer.subscription.deletedactualizan el estado del tenant. - Entitlements: definir por plan (
max_users,max_projects,max_api_calls). Middleware verifica en cada endpoint. Contadores en Redis con reset mensual, agregados a Postgres. Devolver402 Payment Requiredcon link a upgrade cuando se supera. - Customer Portal de Stripe: ahorra construir página de gestión (cambio de plan, actualizar tarjeta, ver facturas). 1 día de integración vs 2 semanas custom.
- API versionada: rate limits por tenant (no por IP), audit log de cambios sensibles (cambio de owner, eliminación de datos), API keys por organización con scopes.
- Aislamiento y observabilidad: logs y métricas etiquetados con
tenant_id. Dashboards por tenant para los tenants enterprise. Secretos de tenant cifrados en KMS/Vault.
4. Migraciones zero-downtime
El patrón estándar es expand-contract: añadir columna nueva (no breaking) → doble escritura desde el código → backfill por tenant en lotes pequeños → leer de la nueva → eliminar la vieja en un deploy posterior. Nunca renombrar ni borrar columnas en uso en el mismo deploy. Para tablas grandes, usar pg-online-schema-change o particionar por tenant_id. Las migraciones se ejecutan idempotentes con herramientas como Prisma Migrate, Drizzle Kit o Flyway, y se versionan en Git.
5. Estrategia de aislamiento: bento comparativo
Para qué: SaaS B2B estándar, freemium, hasta miles de tenants.
Pros: mínimo coste, RLS de Postgres, una migración para todos.
Contras: queries deben filtrar siempre, riesgo de fugas si falta WHERE.
Para qué: personalización por cliente, decenas-centenas de tenants medianos.
Pros: mejor aislamiento, fácil exportar por cliente.
Contras: N migraciones por deploy, search_path complica el ORM.
Para qué: enterprise, regulado (salud, banca), pocos tenants grandes.
Pros: aislamiento físico, escalado independiente por cliente.
Contras: backups, monitorización y migraciones N veces más caros.
6. Preguntas frecuentes
¿Row-level, schema por tenant o DB por tenant?
Row-level para el 90% de SaaS B2B: cero coste operativo, escala a miles de tenants y RLS de Postgres da aislamiento. Schema solo con personalización fuerte por cliente. DB por tenant solo enterprise (banca, salud) o cuando el contrato exige aislamiento físico.
¿Clerk, Auth0 o Supabase Auth para multi-org?
Clerk: mejor DX, organizations e invitations out-of-the-box. Auth0: maduro, B2B SSO sólido pero caro al crecer. Supabase: gratis si ya lo usás, multi-org manual pero funcional. Para SaaS nuevo, Clerk acelera 2-4 semanas; para enterprise serio, Auth0 o WorkOS.
¿Cómo facturar por plan con Stripe?
Stripe Billing con Products (planes) y Prices. Customer = tenant. Subscription + metered usage para consumo. Webhooks de invoice.paid, subscription.updated y subscription.deleted actualizan el estado. Customer Portal ahorra construir gestión.
¿Cómo aplicar límites por plan?
Entitlements por plan (max_users, max_api_calls). Middleware verifica en cada endpoint. Contadores en Redis con reset mensual. Devolver 402 Payment Required con link a upgrade cuando se supera.
¿Cómo hacer migraciones zero-downtime?
Patrón expand-contract: añadir columna nueva, doble escritura, backfill por tenant en lotes, leer de la nueva, eliminar la vieja en deploy posterior. Para tablas grandes, online schema change o particionar por tenant_id.
¿Necesitas implementación del backend?
Construimos backends SaaS multi-tenant con Node.js/Postgres, auth multi-org, Stripe Billing, entitlements y migraciones zero-downtime. También auditamos SaaS existentes con problemas de aislamiento o escalado.
Recursos relacionados
- Checklist de MVP en 4–8 semanas — cómo acotar alcance antes del primer cliente pagador.
- Cuándo conviene Next.js — frontend natural para un SaaS multi-tenant.
- Automatizar procesos en la empresa — qué automatizás del lado del cliente del SaaS.
- Crear una app para tu negocio — visión global de costes y plazos.
Última actualización: junio de 2026 · Escrito por el estudio RoviDev.