Multi-tenancy en web apps: cómo implementarlo correctamente desde el diseño
Implementación de multi-tenancy en web apps: modelo de datos, aislamiento por schema o RLS, gestión de organizaciones, billing por tenant y seguridad entre tenants.
Ideas clave
Lo esencial antes de bajar al detalle
- Multi-tenancy no es opcional en un SaaS B2B: debe diseñarse desde el modelo de datos inicial.
- Row-Level Security (RLS) en PostgreSQL es la forma más sólida de aislar datos entre tenants.
- El modelo de datos incorrecto es el error más costoso de corregir en un SaaS maduro.
- El onboarding de una nueva organización debe ser instantáneo y completamente automatizado.
Qué es multi-tenancy y por qué importa
En un SaaS multi-tenant, múltiples organizaciones (tenants) comparten la misma infraestructura pero sus datos están completamente aislados. Cada empresa ve solo su propio entorno. Puedes ampliar con Qué es una web app: diferencias con app nativa, PWA y web site en 2026 y Cómo desarrollar un portal de clientes como web app: funcionalidades, UX y tecnología.
Sin multi-tenancy, tienes lo que se llama single-tenant: una instancia separada por cliente. Más costoso de operar y escalar. Ver cómo construir un SaaS desde cero.
Tres modelos de aislamiento
- Database por tenant: máximo aislamiento, coste más alto. Solo para clientes enterprise con requisitos estrictos de cumplimiento.
- Schema por tenant (PostgreSQL): buen aislamiento, gestión de migraciones más compleja. Escala hasta ~1.000 tenants.
- Row-level (shared schema): el más común en SaaS. Todas las tablas tienen una columna `organization_id`. Escala bien con RLS.
Row-Level Security (RLS) en PostgreSQL
RLS permite definir políticas a nivel de base de datos que filtran automáticamente los datos según el contexto del usuario. Con Supabase, RLS está integrado y es el patrón recomendado. Puedes ampliar con Web corporativa y Web apps.
Ejemplo: `CREATE POLICY tenant_isolation ON items USING (organization_id = current_setting('app.current_org')::uuid);`. Esto hace imposible que una query devuelva datos de otro tenant aunque haya un bug en el código. Puedes ampliar con Ecommerce y React y Next.js.
Modelo de datos multi-tenant recomendado
- Tabla `organizations`: id, slug, name, plan, createdAt.
- Tabla `memberships`: userId, organizationId, role (OWNER, ADMIN, MEMBER).
- Todas las entidades de negocio llevan `organizationId` NOT NULL con FK a organizations.
- Índices compuestos en `(organizationId, createdAt)` para queries de listado frecuentes.
Onboarding de nueva organización
- Creación de organización en la misma transacción que el registro del primer usuario.
- Asignación automática del rol OWNER al fundador.
- Configuración de Stripe Customer y suscripción de prueba si aplica.
- Email de bienvenida con guía de primeros pasos.
Lecturas relacionadas
Sigue por aquí
Qué es una web app: diferencias con app nativa, PWA y web site en 2026
Guía clara para entender qué es una web app, en qué se diferencia de una app nativa, una PWA y un sitio web estático, con ejemplos reales.
Cómo construir un SaaS como web app desde cero: fases, tecnología y errores que evitar
Guía completa para construir un producto SaaS como web app: desde la validación de la idea hasta el lanzamiento y las primeras métricas de retención.
Cómo desarrollar un portal de clientes como web app: funcionalidades, UX y tecnología
Guía completa para crear un portal de clientes como web app: acceso seguro, dashboard personalizado, documentos, facturación, notificaciones y soporte.
Cuánto cuesta desarrollar una web app en 2026: rangos reales por tipo de proyecto
Desglose real de precios para desarrollar una web app en 2026: SaaS, dashboard, portal de clientes, marketplace. Qué incluye cada rango y cómo planificar el presupuesto.