Arquitectura multi-tenant con PostgreSQL en aplicaciones SaaS

Las aplicaciones SaaS modernas generalmente necesitan atender a múltiples clientes utilizando la misma infraestructura. Este modelo se conoce como arquitectura multi-tenant — donde diferentes organizaciones (tenants) comparten el mismo sistema, pero con sus datos completamente aislados. En este artículo presento cómo estructurar este patrón utilizando PostgreSQL, con enfoque en simplicidad, escalabilidad y seguridad.

Qué es una arquitectura multi-tenant

En una aplicación multi-tenant, varios clientes utilizan la misma aplicación y base de datos, pero cada cliente posee sus propios datos aislados. El sistema necesita garantizar que usuarios de una empresa nunca tengan acceso a la información de otra. Este modelo es ampliamente utilizado en productos SaaS como plataformas de gestión, CRMs, marketplaces y sistemas corporativos.

Principales estrategias de multi-tenancy

Existen tres enfoques comunes para implementar multi-tenancy en bases de datos:

Database per tenant: cada cliente posee una base de datos separada.
Schema per tenant: cada cliente posee un schema propio dentro de la misma base.
Shared database con tenant_id: todos los datos quedan en la misma base y tablas, pero cada registro posee un identificador de tenant.

En la mayoría de los productos SaaS modernos, el enfoque más utilizado es el tercero: shared database con tenant_id. Ofrece el mejor equilibrio entre escalabilidad, simplicidad operacional y costo de infraestructura.

Modelado de la base de datos

El principio básico es simple: prácticamente todas las tablas relacionadas con datos de negocio deben poseer una columna tenant_id. Este campo identifica a qué organización pertenece ese dato.

CREATE TABLE tenants (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE orders (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  tenant_id UUID NOT NULL REFERENCES tenants(id),
  total NUMERIC NOT NULL,
  created_at TIMESTAMP DEFAULT NOW()
);

Este patrón garantiza que todos los datos estén vinculados a un tenant específico. A partir de aquí, todas las consultas deben siempre filtrar por tenant_id.

SELECT * FROM orders
WHERE tenant_id = 'tenant-uuid';

Aplicando aislamiento en el backend

En el backend de la aplicación, el tenant_id normalmente se identifica a partir del usuario autenticado. Esto significa que todas las queries ejecutadas por el sistema deben automáticamente aplicar este filtro.

const orders = await db.orders.findMany({
  where: {
    tenantId: session.tenantId
  }
});

Este patrón impide que usuarios accedan a datos de otras organizaciones y mantiene el sistema consistente.

Row Level Security en PostgreSQL

Una capa adicional de seguridad puede implementarse usando Row Level Security (RLS) de PostgreSQL. Con RLS, la propia base de datos garantiza que solo registros del tenant correcto puedan ser accedidos.

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation_policy
ON orders
USING (tenant_id = current_setting('app.current_tenant')::uuid);

Con este enfoque, incluso si una query se ejecuta sin el filtro adecuado en el backend, la base de datos aún protegerá el acceso a los datos.

Escalabilidad en sistemas multi-tenant

La arquitectura basada en tenant_id también facilita escalar el sistema. Algunas estrategias comunes incluyen:

Indexación por tenant_id para mejorar el rendimiento de consultas.
Particionamiento de tablas basado en tenant_id.
Separación de tenants mayores a bases dedicadas conforme crece la plataforma.
Uso de caches por tenant para reducir carga en la base de datos.

Aplicaciones reales en productos SaaS

Este patrón se utiliza en diversos tipos de productos SaaS, como plataformas de gestión empresarial, sistemas de agendamiento, marketplaces y CRMs. En proyectos que desarrollé recientemente, la arquitectura multi-tenant permitió atender múltiples clientes manteniendo aislamiento de datos y reduciendo costos operacionales.

Conclusión

Las arquitecturas multi-tenant son la base de muchos productos SaaS modernos. Utilizando PostgreSQL y un diseño consistente basado en tenant_id, es posible construir sistemas escalables, seguros y relativamente simples de mantener. Cuando se combina con buenas prácticas de backend y seguridad en la base de datos, este enfoque se convierte en una solución robusta para plataformas multi-cliente.

Vinicius Aguiar