Arquitectura Multi-tenant: Cómo Diseñar un SaaS para Miles de Clientes

Multi-tenancy es la característica que convierte una aplicación web en un verdadero SaaS. Sin ella, estás desplegando instancias separadas para cada cliente, lo que no escala ni en costo ni en operación. Con una arquitectura multi-tenant bien diseñada, un solo despliegue sirve a miles de organizaciones con datos completamente aislados. Esta guía cubre los tres modelos principales y cómo elegir el correcto para tu producto.

¿Qué es Multi-tenancy?

Un "tenant" es una organización o cliente que usa tu SaaS. Multi-tenancy significa que múltiples tenants comparten la misma infraestructura (servidores, base de datos, código) mientras mantienen sus datos completamente separados e invisibles entre sí. Es el modelo que usan Slack, Notion, Salesforce y prácticamente todo SaaS B2B exitoso.

Los 3 Modelos de Multi-tenancy

Modelo 1: Base de Datos Compartida (Shared Schema)

Todos los tenants comparten las mismas tablas. El aislamiento se logra con una columna tenant_id en cada tabla y Row Level Security (RLS) en PostgreSQL para garantizar que cada consulta solo accede a los datos del tenant correcto.

• Ventajas: Más económico, operación simple, fácil de implementar
• Desventajas: Riesgo de filtrar datos si RLS falla, performance compartido
• Ideal para: SaaS en etapa inicial, mercado SMB, hasta ~10,000 tenants

Con Supabase, activar RLS es trivial. Define una política que compare el tenant_id de cada fila con el claim del JWT del usuario autenticado:

Modelo 2: Esquemas Separados (Schema-per-Tenant)

Cada tenant tiene su propio schema de PostgreSQL (ej: tenant_abc.users, tenant_xyz.users) dentro de la misma base de datos. El aislamiento es más fuerte: un bug en el ORM no puede cruzar datos entre tenants.

• Ventajas: Buen aislamiento, migraciones por tenant posibles, más fácil de auditar
• Desventajas: Complejidad operacional, migraciones deben aplicarse a todos los schemas
• Ideal para: SaaS de mediana escala, mercado mid-market, regulación moderada

Modelo 3: Base de Datos Aislada (Database-per-Tenant)

Cada tenant tiene su propia base de datos PostgreSQL completamente separada. Aislamiento máximo pero costo y complejidad también máximos.

• Ventajas: Aislamiento total, compliance con regulaciones estrictas (HIPAA, GDPR), personalización por tenant
• Desventajas: Muy costoso a escala, operación compleja, lento para provisionar
• Ideal para: Enterprise SaaS, healthcare, fintech, clientes que exigen datos en su propia infraestructura

Implementación con Prisma y PostgreSQL (Modelo Shared Schema)

El modelo más común para SaaS en crecimiento es shared schema con RLS. Así se estructura el schema de Prisma:

• Tabla Organization como entidad raíz del tenant
• Tabla User con relación many-to-many a Organization via Membership
• Todas las tablas de negocio incluyen organizationId como foreign key
• Middleware en tRPC o API Routes inyecta el organizationId del usuario autenticado en cada query

Gestión de Roles y Permisos por Tenant

En un SaaS multi-tenant, los roles no son solo "admin" y "user" globales. Cada tenant necesita sus propios roles: el usuario Pablo puede ser admin en la organización A pero viewer en la organización B.

El patrón recomendado es una tabla Membership con campos userId, organizationId y role. Complementa con una librería de autorización como Permit.io o implementa RBAC manual con una tabla de permisos granulares si tus necesidades lo justifican.

Subdominios por Tenant

Una experiencia SaaS premium incluye subdominios personalizados: empresa-abc.tusalas.io o incluso dominios propios del cliente. En Next.js con Vercel, esto se logra con:

• Dominio wildcard *.tusalas.io en Vercel
• Middleware de Next.js que extrae el subdominio del header Host
• Lookup del tenant por slug o dominio personalizado en la base de datos
• Inyección del tenantId en el contexto de la request

Onboarding Automático de Tenants

El momento en que un usuario se registra en tu SaaS, debes provisionar automáticamente su tenant. El flujo típico:

• Usuario completa sign up → crea Organization con slug único
• Crea Membership con rol OWNER
• Provisiona datos de ejemplo o plantillas iniciales
• Configura plan en Stripe con metadata.organizationId
• Envía email de bienvenida con Resend

Errores Comunes en Arquitectura Multi-tenant

• Olvidar el tenant_id en queries: Siempre valida en middleware, no confíes solo en el cliente
• Rutas de admin sin protección: Las rutas de administración interna deben verificar que el usuario tiene rol correcto en el tenant correcto
• Migraciones sin considerar todos los tenants: En schema-per-tenant, automatiza las migraciones con scripts
• Sin rate limiting por tenant: Un tenant mal intencionado puede saturar recursos compartidos

Conclusión

La arquitectura multi-tenant correcta depende de tu mercado objetivo, volumen esperado y requisitos de compliance. Para la mayoría de los SaaS en México y LATAM que apuntan al mercado SMB, shared schema con RLS en Supabase es el punto de partida correcto. Conforme creces y adquieres clientes enterprise, puedes migrar gradualmente a modelos de mayor aislamiento sin reescribir toda la aplicación.