SaaS multi-tenant con Next.js y PostgreSQL: quién puede construirlo

Tienes una idea de SaaS, o un producto que ha superado su primera versión, y cada cliente necesita su propio espacio de trabajo, sus propios usuarios y sus propios datos. Buscas un equipo que sepa construir un SaaS multi-tenant con Next.js y PostgreSQL, y casi todas las propuestas se parecen sobre el papel. La diferencia aparece después: la primera fuga de datos, la primera migración que se atasca, el primer cliente que ralentiza a todos los demás.

Esta guía te explica qué debe saber hacer ese equipo: elegir un modelo de tenencia, enrutar y autenticar a cada cliente, vincular la facturación a los límites del plan, y ejecutar migraciones y copias de seguridad en todos los tenants. De cada parte obtienes qué significa para tu negocio, cómo se ve lo bueno y una pregunta que separa la experiencia de un discurso comercial. Para la cuestión más amplia de elegir agencia, nuestra guía para elegir una agencia de desarrollo Next.js para SaaS es el mejor punto de partida.

La respuesta corta: un buen equipo recomienda tablas compartidas con row level security para la mayoría de los MVP, hace cumplir el tenant en la base de datos, diseña los límites del plan en la primera semana y puede mostrarte cómo se restaura un solo tenant. Las secciones siguientes te enseñan a comprobar cada afirmación.

Quién construye SaaS multi-tenant y qué esperar#

Cuatro tipos de equipos construyen SaaS multi-tenant: tus propios ingenieros, un estudio de producto, una agencia web generalista y un equipo especialista en SaaS. La multi-tenencia es lo que los distingue, porque una demo la oculta y un lanzamiento la deja al descubierto. Saber qué buscar te permite preseleccionar con confianza.

Qué significa multi-tenant para tu negocio#

Multi-tenant significa que un único producto en ejecución atiende a muchas organizaciones cliente, llamadas tenants, y cada una ve solo sus propios datos. Lanzas una versión, corriges un error una vez y pagas una sola plataforma, mientras cada cliente siente que tiene un producto privado. Tu coste por cliente baja a medida que creces. El riesgo es que un solo error puede mostrar los datos de un cliente a otro.

Un tenant suele ser una empresa, no una persona. Dentro hay miembros con roles como propietario, administrador y lector. Los precios, el soporte y las promesas de cumplimiento dependen de esa estructura, así que es una decisión de producto antes que técnica.

Tres tipos de equipos que encontrarás#

Cada tipo tiene una fortaleza real y una pregunta que vale la pena hacerle:

• Los ingenieros internos conocen mejor tu dominio. Pregunta quién ha operado un producto multi-tenant en producción, porque contratar esa experiencia puede llevar meses.
• Los estudios de producto y las agencias generalistas entregan interfaces y primeras versiones con rapidez. Pide evidencia sobre tenencia, facturación y operación, más allá del diseño y la velocidad.
• Los equipos especialistas en SaaS ya se han enfrentado al aislamiento, la medición y las migraciones. Pregunta qué harían distinto en tu producto y por qué.

Un equipo pequeño y sénior que ha operado un producto multi-tenant suele superar a uno más grande que aprende con tu presupuesto. El tamaño importa menos que quién ya ha visto estos problemas.

Elige un modelo de tenencia para tu SaaS multi-tenant#

Tu modelo de tenencia fija tu coste por cliente, la solidez del aislamiento y lo difícil que resulta cada lanzamiento. Existen tres modelos. Un buen equipo te recomienda uno para tu etapa y te dice qué te haría cambiarlo.

Esquema compartido con row level security#

Todos los tenants comparten las mismas tablas y cada fila lleva un identificador de tenant. PostgreSQL filtra las filas con él mediante row level security (RLS), una función integrada que asocia una regla a una tabla. Como la regla vive en la base de datos, se aplica a todas las consultas que ejecuta la app.

-- A tenant-scoped table
create table projects (
  id uuid primary key default gen_random_uuid(),
  tenant_id uuid not null,
  name text not null,
  created_at timestamptz not null default now()
);

-- Every query filters on tenant_id, so index it first
create index projects_tenant_idx on projects (tenant_id, created_at);

-- Turn on RLS and apply it to the table owner too
alter table projects enable row level security;
alter table projects force row level security;

-- Rows are visible and writable only for the tenant set on the transaction
create policy tenant_isolation on projects
  using (tenant_id = current_setting('app.tenant_id', true)::uuid)
  with check (tenant_id = current_setting('app.tenant_id', true)::uuid);

-- The app connects as an ordinary role, never a superuser
create role app_user login;
grant select, insert, update, delete on projects to app_user;

La política compara el tenant de cada fila con un valor que la app establece para la transacción actual. Dos detalles separan la experiencia real de un tutorial. Los propietarios de la tabla omiten las políticas por defecto y los superusuarios siempre lo hacen, así que la tabla necesita force row level security y la app debe conectarse con un rol ordinario. La documentación de PostgreSQL sobre políticas de seguridad de filas describe ambos puntos. Cuando no hay tenant definido, la política no coincide con nada, de modo que un valor ausente devuelve cero filas en lugar de las filas de todos.

Esquema por tenant#

Cada tenant tiene su propio esquema, un conjunto separado de tablas dentro de la misma base de datos. El aislamiento es más fácil de explicar a un auditor, y mover o restaurar un tenant resulta más sencillo. El precio son las migraciones: cada cambio se ejecuta una vez por tenant, lo que exige herramientas, orden y reintentos cuando pasas de unos cientos de clientes.

Base de datos por tenant#

Cada tenant tiene su propia base de datos, a veces en su propio servidor. Es el aislamiento más fuerte, y algunos clientes empresariales o regulados lo exigen, junto con la elección de región. También es el más caro por tenant, porque el aprovisionamiento, la monitorización y las migraciones se multiplican con cada cliente.

Cómo elegir: comparación rápida#

La mayoría de los MVP B2B deberían empezar compartidos y dejar la puerta abierta. Un identificador de tenant en cada tabla desde el primer día convierte el traslado posterior de un cliente grande a su propia base de datos en un trabajo de copia, no en una reescritura. Pregunta a cualquier equipo qué lo llevaría a sacarte del modelo compartido. Una buena respuesta cita un requisito de un cliente, como la residencia de datos o el aislamiento contractual, y nunca una cuestión de gusto.

Arquitectura multi-tenant en Next.js: rutas y auth#

Tu cliente abre acme.yourapp.com y llega a su propio espacio de trabajo. Antes de leer una sola fila, el producto debe saber qué tenant es, quién es el miembro y qué puede hacer. Next.js resuelve lo primero, tu capa de autenticación lo segundo, y PostgreSQL queda como red de seguridad.

Ruta de la petición

1. 01Abrir subdominioEl cliente visita acme.yourapp.com
2. 02Resolver tenantNext.js lee el host
3. 03Revisar miembro y rolLa auth confirma el acceso
4. 04Row level securityPostgreSQL devuelve solo sus filas

Una petición pasa del subdominio de un cliente a la búsqueda del tenant y la comprobación del miembro, hasta una base de datos que devuelve solo las filas de ese tenant

Subdominios y dominios propios#

Los subdominios dan a cada cliente una dirección con su marca, con un único registro DNS comodín y un solo despliegue. Una pequeña función lee la cabecera host y devuelve el slug del tenant. Next.js la ejecuta en el archivo que intercepta las peticiones, llamado middleware en versiones anteriores y proxy en las recientes, así que consulta la documentación de Next.js para saber el nombre que usa tu versión.

// lib/tenant.ts
const ROOT_DOMAIN = process.env.ROOT_DOMAIN ?? 'yourapp.com';

// Returns the tenant slug for acme.yourapp.com, or null for other hosts
export function tenantFromHost(hostHeader: string | null): string | null {
  if (!hostHeader) return null;
  const host = hostHeader.split(':')[0].toLowerCase();
  const suffix = `.${ROOT_DOMAIN}`;
  if (!host.endsWith(suffix)) return null; // root domain or custom domain
  const slug = host.slice(0, -suffix.length);
  return /^[a-z0-9-]+$/.test(slug) && slug !== 'www' ? slug : null;
}

// proxy.ts (named middleware.ts in earlier Next.js versions)
import { NextRequest, NextResponse } from 'next/server';
import { tenantFromHost } from './lib/tenant';

// In earlier versions, export this same function as middleware
export function proxy(request: NextRequest) {
  const headers = new Headers(request.headers);
  headers.delete('x-tenant-slug'); // never trust a value sent by the browser
  const slug = tenantFromHost(request.headers.get('host'));
  if (slug) headers.set('x-tenant-slug', slug);
  return NextResponse.next({ request: { headers } });
}

La función elimina cualquier cabecera de tenant entrante antes de establecer la suya, así que un visitante no puede hacerse pasar por otro tenant. Los dominios propios, como app.customer.com, siguen el mismo camino con una adición: una tabla que asocia cada dominio verificado con un tenant. Los equipos con experiencia también planifican las comprobaciones de propiedad del dominio y los certificados automáticos, porque tus clientes los pedirán.

Organizaciones, miembros y roles#

Rara vez una persona pertenece a una sola organización. Un consultor puede ser administrador en un cliente y lector en otro, así que usuarios, organizaciones y membresías son tres cosas distintas. La membresía guarda el rol, y cada acción lo comprueba en el servidor, nunca solo en la interfaz.

Las invitaciones merecen el mismo cuidado: un enlace firmado, una caducidad, un rol elegido por quien invita y una forma de revocarlo. Los buenos equipos nombran los permisos según lo que hacen las personas, como invitar miembros o exportar datos, y asignan roles a ellos. Así el producto queda listo cuando un cliente pide un rol personalizado o inicio de sesión único.

Pasar el tenant a la base de datos con seguridad#

Una vez que la app conoce el tenant, se lo entrega a PostgreSQL dentro de una transacción. La función auxiliar siguiente abre una transacción, fija el tenant solo para esa transacción y ejecuta tus consultas. Como el valor es local a la transacción, es seguro con el connection pooling, donde muchas peticiones comparten pocas conexiones.

// lib/db.ts
import { Pool, PoolClient } from 'pg';

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

export async function withTenant<T>(
  tenantId: string,
  work: (client: PoolClient) => Promise<T>
): Promise<T> {
  const client = await pool.connect();
  try {
    await client.query('begin');
    // The third argument true keeps the setting local to this transaction
    await client.query("select set_config('app.tenant_id', $1, true)", [tenantId]);
    const result = await work(client);
    await client.query('commit');
    return result;
  } catch (error) {
    await client.query('rollback');
    throw error;
  } finally {
    client.release();
  }
}

// Usage: only this tenant's projects come back
// const rows = await withTenant(tenantId, (db) =>
//   db.query('select id, name from projects order by created_at desc'));

Toda llamada a la base de datos del producto pasa por esta función. Un revisor puede comprobarlo en minutos, y una prueba puede demostrarlo.

Facturación, medición y límites del plan#

La facturación es donde la tenencia se encuentra con los ingresos. Cada tenant tiene un plan, y el producto debe permitir, avisar o bloquear acciones según ese plan. Lo bueno es una única fuente de verdad sobre lo que cada tenant puede hacer, actualizada automáticamente cuando cambian los pagos.

Del uso al límite

1. 01Evento de uso registradoCada acción del tenant se anota
2. 02Stripe mide el usoStripe Billing lo suma por tenant
3. 03El webhook actualiza derechosUna fuente de verdad de límites

• APermitirEl tenant está dentro del plan
  1. La acción continúa
• BAvisarEl tenant se acerca al límite
  1. Mostrar aviso de mejora
• CBloquearEl tenant superó el límite
  1. Acción rechazadaSe ofrece mejorar el plan

El uso se registra, Stripe Billing lo mide y un webhook lo sincroniza con los entitlements; la app permite, avisa o bloquea, y un pago fallido pasa al tenant a estado de gracia

Planes, asientos y medidores de uso#

Decide por qué cobras antes de que alguien escriba código. Stripe Billing admite suscripciones, precios por asiento y precios por uso, y el producto debe registrar los datos correspondientes de cada tenant.

La mayoría de los productos los combinan: un plan con asientos y cupo incluidos, y después uso adicional. Los eventos de uso necesitan un identificador de tenant y una clave única, para que un reintento nunca cuente dos veces.

Hacer cumplir los límites dentro del producto#

Guarda en tu propia base de datos un pequeño registro de derechos (entitlements) por tenant: plan, límite de asientos, cupo y estado. Los webhooks de Stripe lo actualizan, y una única función responde cada pregunta, como si este tenant puede crear otro proyecto. Llamar a Stripe en cada visita a una página ralentiza el producto y lo ata a un servicio externo.

Avisa cuando un tenant alcance gran parte de su cupo, y bloquea solo en el límite con un mensaje claro y un botón para mejorar el plan. Los manejadores de webhooks deben verificar la firma y guardar los identificadores de evento, porque el mismo evento puede llegar más de una vez.

Gestionar pagos fallidos y cambios de plan#

Una tarjeta rechazada no debería dejar sin acceso a un cliente el primer día. Stripe reintenta los pagos según un calendario que configuras y envía eventos como invoice.payment_failed y customer.subscription.updated. Tu producto los lee y pasa al tenant a un estado de gracia: acceso completo con un aviso, luego solo lectura, nunca borrado.

Las mejoras de plan deben aplicarse en cuanto el pago se confirma. Las bajadas necesitan una regla para los tenants que superan los nuevos límites, por ejemplo conservar los datos existentes y bloquear elementos nuevos. Acuerda estas reglas por escrito con tu equipo, porque el soporte las aplicará a diario.

Migraciones, copias de seguridad y vecinos ruidosos#

Son problemas del día dos, y deciden si el producto sobrevive a su propio crecimiento. Un equipo con experiencia habla de ellos antes del lanzamiento.

Cambios de esquema sin tiempo de inactividad#

Cada versión puede cambiar la base de datos, y todos los tenants comparten el resultado. Los cambios seguros siguen un patrón de expandir y contraer: añade la columna nueva como opcional, despliega código que escribe en ambas, rellena las filas antiguas en lotes pequeños, cambia las lecturas y elimina la columna antigua en una versión posterior. Los índices se crean con create index concurrently para que las tablas sigan admitiendo escrituras.

Con un esquema compartido, es una sola migración. Con un esquema por tenant, el mismo cambio se ejecuta una vez por tenant, con orden, reintentos y un informe de qué tenants están terminados. Pregunta cómo es ese informe.

Restaurar un solo tenant, no a todos#

Tarde o temprano un cliente borra algo y te pide que lo recuperes. La recuperación a un punto en el tiempo restaura toda la base de datos, lo que sobrescribiría el trabajo de todos los demás. En un esquema compartido, lo habitual es restaurar una copia en una base de datos temporal y devolver a la original las filas de ese tenant por su identificador.

Debe ser un procedimiento escrito y probado. Un buen equipo lo ha ejecutado sobre copias reales y sabe decirte cuánto tarda.

Límites de tasa, cuotas y monitorización por tenant#

Un vecino ruidoso es un tenant cuya importación o informe pesado ralentiza a todos los demás. Los controles prácticos son límites de tasa por tenant, colas en segundo plano con un tope de concurrencia por tenant, tiempos máximos de consulta y límites de conexiones a la base de datos.

Etiqueta logs, errores y trazas con el identificador del tenant. Así el soporte puede responder si un problema afecta a un cliente o a todos, y las alertas pueden saltar para un solo tenant. Sin esa etiqueta, depuras a ciegas.

Forma del equipo y coste: MVP frente a escala#

El coste sigue más al alcance que al número de personas. Un equipo sénior pequeño puede entregar un MVP multi-tenant en semanas o unos pocos meses, y es el alcance lo que lo alarga: reglas de facturación, roles, integraciones y cumplimiento. Así cambia el trabajo a medida que creces.

1. Fase 1: MVP

   Una app, una base de datos

   Un equipo sénior pequeño construye una app Next.js sobre una base de datos PostgreSQL con row level security, inicio de sesión, organizaciones y uno o dos planes.

2. Fase 2: primeros clientes

   Facturación y observabilidad

   Llegan los webhooks, los entitlements, el seguimiento de errores, los logs etiquetados por tenant, las copias probadas y una rutina de migraciones disciplinada.

3. Fase 3: escala

   Más aislamiento y guardias

   Cuotas por tenant, bases de datos dedicadas para los pocos clientes que las necesitan, una rutina de guardias y simulacros de restauración periódicos.

Cómo es un equipo para un MVP#

Dos a cuatro personas suelen bastar: un ingeniero full-stack sénior que dirige la arquitectura, un segundo ingeniero, un diseñador para los flujos clave y un responsable de producto de tu lado. Mantén una sola app desplegable y una sola base de datos. Nuestro marco de decisión entre monolito y microservicios explica por qué, y cuándo empieza a compensar dividir.

Qué cambia tras los primeros clientes#

El uso real trae preguntas reales: un cliente pide una exportación, otro inicio de sesión único, un tercero una restauración. El equipo añade observabilidad, casos límite de facturación y una rutina de soporte. Es el momento en que un retainer o un plan Care pesa más que la primera construcción, porque alguien debe vigilar el producto y responder rápido.

Qué sube o baja el presupuesto#

• Roles y permisos: unos pocos roles fijos cuestan menos que roles personalizados por tenant.
• Facturación: los planes fijos son simples, mientras que la medición por uso con prorrateo exige más diseño.
• Integraciones: cada CRM, ERP o proveedor de identidad añade trabajo y pruebas.
• Cumplimiento: los registros de auditoría, la residencia de datos y las certificaciones amplían el alcance.
• Modelo de tenencia: las bases de datos dedicadas añaden coste de operación por cada cliente.

Por ejemplo (ilustrativo), toma dos productos con el mismo modelo de tenencia. El producto A tiene inicio de sesión por correo, un plan y ninguna integración. El producto B añade inicio de sesión único, tres roles, facturación por uso y una sincronización con un CRM. El producto B es mucho más que A más unos cuantos extras, porque cada adición afecta a roles, facturación y pruebas. Pide a cualquier equipo que valore estos factores por separado para que puedas ajustarlos a tu plazo.

Preguntas que revelan experiencia multi-tenant real#

Hazlas en tu primera llamada. Las buenas respuestas son específicas, mencionan compromisos y se refieren a algo que el equipo ha operado. Para las cuestiones de proceso, referencias y contrato, la guía para seleccionar una agencia Next.js cubre el resto.

• Pregunta qué modelo de tenencia recomiendan para tu etapa y qué los haría cambiarlo
• Pide ver la política de row level security y la prueba que falla sin ella
• Pregunta cómo se configura el rol de la app para que las políticas no puedan omitirse
• Pregunta cómo llega una migración nueva a todos los tenants y cómo se informan los fallos
• Pregunta cómo se restaura un tenant sin tocar a los demás
• Pregunta dónde viven los límites del plan y qué pasa cuando falla un pago
• Pregunta cómo se evita que un tenant pesado ralentice al resto
• Pregunta cómo encuentra el soporte los errores y logs de un tenant

Preguntas sobre aislamiento y datos#

Escucha si hablan de la base de datos. Una respuesta sólida dice que el tenant lo impone row level security o esquemas separados, con la app conectada con un rol limitado, y que pruebas automáticas intentan leer filas de otro tenant y deben fallar. Una respuesta débil dice que cada consulta tiene un where para el tenant. Eso funciona hasta el día en que alguien lo olvida.

Pregunta también por las copias por tenant, la exportación y el borrado de datos. Tus clientes pedirán cada una, a menudo en un cuestionario de seguridad.

Preguntas sobre operación y facturación#

Una respuesta sólida nombra el registro de entitlements, los eventos de webhook, el estado de gracia y los manejadores idempotentes. Describe el proceso de migración paso a paso y dice quién está de guardia cuando algo falla tras el lanzamiento. Si el equipo ha restaurado un tenant, pídele que te lo cuente paso a paso. Quien lo ha hecho recuerda los detalles.

Señales de alerta en las respuestas#

• Filtrado por tenant solo en el código de la aplicación, sin salvaguarda en la base de datos
• Facturación descrita como una fase posterior, con los límites escritos en la interfaz
• Ninguna prueba automática que demuestre que un tenant no puede leer los datos de otro
• Un precio y una fecha fijos sin hablar de roles, facturación o cumplimiento
• Ningún plan de copias, restauraciones o monitorización tras el lanzamiento

Una señal de alerta es motivo para preguntar más. Varias juntas son motivo para mirar a otro equipo.

Cómo werun.dev construye y opera productos SaaS#

Tú marcas el objetivo y nosotros construimos el camino. En un SaaS, ese objetivo puede ser los primeros clientes de pago, un onboarding más fluido o menos horas de soporte. Construimos aplicaciones a medida con Next.js, React y PostgreSQL y seguimos a tu lado tras el lanzamiento. El servicio de apps a medida y nuestras soluciones muestran el tipo de productos y resultados en los que trabajamos.

De tu objetivo a una primera versión#

Empezamos por tu objetivo y un resumen de tenencia de una página: quién es un tenant, qué limitan los planes y qué clientes necesitan un aislamiento más fuerte. Después construimos una app Next.js sobre una base de datos PostgreSQL, con el tenant impuesto en la base de datos, la facturación conectada a los límites del plan y pruebas de aislamiento en cada cambio. Las versiones son pequeñas, así que ves software funcionando pronto y puedes cambiar de rumbo a bajo coste.

Dejamos por escrito qué te haría pasar a otro modelo de tenencia, para que la decisión siga siendo tuya. WelcomeAI, nuestro propio SaaS de chatbot RAG, es un producto que operamos nosotros mismos, así que conocemos el trabajo de operarlo tanto como el de construirlo.

A tu lado después del lanzamiento#

Tras el lanzamiento obtienes respuesta en menos de 2 horas en días laborables, un panel de cliente para proyectos, solicitudes y facturas, y un informe mensual por escrito. Client Feedback permite a tu equipo hacer clic en cualquier parte de una página y pedir un cambio, de modo que las solicitudes nos llegan con contexto. Un plan Care o un Retainer mantiene migraciones, actualizaciones y monitorización en manos seguras.

Cuando la tenencia está sólida, las funciones de IA por tenant son el siguiente paso natural, y el aislamiento de datos importa aún más para la recuperación de información y los agentes. Nuestra guía sobre integración de IA en plataformas SaaS muestra lo que viene después.

Por dónde empezar esta semana#

Escribe un resumen de tenencia de una página. Lleva una hora aproximadamente y hace que cada propuesta que recibas sea más fácil de comparar. Responde cuatro preguntas:

1. ¿Quién es un tenant (una empresa, un equipo o una persona) y cuántos miembros tiene?
2. ¿Qué clientes podrían necesitar un aislamiento más fuerte, una región o un registro de auditoría?
3. ¿Qué limitan tus planes: asientos, uso o funciones?
4. ¿Qué debería pasar cuando falla un pago?

Envíanos la página junto con tu objetivo desde la página de contacto. Respondemos en menos de 2 horas en días laborables y te decimos con qué modelo de tenencia empezaríamos, y por qué.

Preguntas frecuentes#