Arquitectura de referencia: SaaS multi-tenant con Postgres o MySQL

SaaS multi-tenant: reglas por base de datos y por usuario de servicio

En un SaaS, el mismo código atiende a todos tus clientes, y una sentencia mal escrita puede tocar los datos de todos a la vez. El proxy TCP de Vericto aplica reglas, allowlists y enmascaramiento por base de datos y por usuario de base de datos, con un proxy por base o por grupo de tenants. No aísla tenants por sí solo: eso sigue siendo trabajo de tu modelo de datos y de los permisos de tu base.

Qué protege

Lo que Vericto aplica en un SaaS, todo en el proxy TCP:

Reglas por base de datos. Se configuran por workspace, con overrides por base, y las críticas (DELETE y UPDATE sin WHERE, DROP, TRUNCATE) bloquean por defecto: la sentencia que tocaría todas las filas de todos los tenants no llega a la base.
VERICTO-087 (Team y Enterprise): una allowlist de tablas y columnas por usuario de base de datos, en cada base. Da a cada servicio su propio usuario: la API, los workers, la herramienta de soporte. Bajo una allowlist, el DDL, SET ROLE, SET search_path y USE se deniegan.
VERICTO-085 (Team y Enterprise): columnas sensibles bloqueadas o devueltas enmascaradas. La política es por base de datos y aplica a todas sus sesiones: si la herramienta de soporte debe ver los valores enmascarados y la aplicación no, dale a soporte un proxy propio, registrado como otra base con el enmascaramiento activo.
VERICTO-019: desactivar el Row Level Security o los triggers de una tabla, la base del aislamiento por filas en Postgres.
Audit trail por workspace. Cada evento lleva su base de datos y su identidad (el usuario de base o la API key), así que ves el tráfico de cada base y de cada servicio por separado. Con la telemetría sanitizada, los literales, como los datos de tus clientes, se reemplazan antes de salir del proxy.

Qué aísla Vericto y qué no

Vericto decide sobre la forma de cada sentencia, no sobre las filas que devuelve, y no conoce el tenant de la petición que la originó. Por eso:

Sí separa las reglas, las allowlists y las columnas sensibles por base de datos, y las allowlists por usuario de base. Con un esquema o una base por tenant y un usuario por tenant, una allowlist que solo nombra su esquema deniega las tablas de los demás.
No filtra filas. En una tabla compartida con una columna tenant_id, Vericto no puede comprobar que el WHERE filtre por el tenant correcto: no sabe si a esa petición le corresponde tenant_id = 42 o 43. Para eso está el Row Level Security de Postgres, o un esquema o una base por tenant.
No autentica a tus tenants, no separa redes ni credenciales y no resuelve vistas, funciones ni triggers. Los roles, los permisos, el RLS y la separación de bases de tu modelo siguen siendo el mecanismo de aislamiento; Vericto es defensa en profundidad encima.

Latencia y disponibilidad

Cada sentencia suma el salto al proxy de su base y la evaluación en su proceso, sin llamadas de red en la ruta crítica. Las allowlists y las columnas sensibles se deciden sobre el AST, como cualquier otra regla, sin leer resultados.

Para el parsing y la evaluación de reglas, el objetivo de diseño es p99 < 2 ms. Es un objetivo, no una medición: el benchmark de latencia del proxy todavía no está publicado.

Con una base por tenant, cuenta los proxies: uno por base es lo más simple, y la memoria crece con las conexiones, unos 4 KB por sesión TCP. Las bases protegidas dependen del plan: 1 en Free, 3 en Builder, 10 en Team y a medida en Enterprise.

Cómo implementarlo

Elige el modelo: una base por tenant o por grupo de tenants (lo más fácil de aislar), un esquema por tenant, o tablas compartidas con tenant_id y RLS. Registra cada base en el workspace con su dialecto.
Despliega un proxy por base (el contenedor ghcr.io/vericto/vericto-proxy) con UPSTREAM_HOST apuntando a ella, y conecta a él los servicios que usan esa base.
Crea un usuario de base de datos por servicio (la API, los workers, la herramienta de soporte) y, en Team y Enterprise, su allowlist en observe. Simúlala contra sus queries de los últimos 7 días y pásala a enforce.
Etiqueta las columnas sensibles de cada base. Si un servicio debe verlas enmascaradas y otro no, dale un proxy propio, registrado como otra base.
Con tablas compartidas, activa el Row Level Security de Postgres y comprueba que VERICTO-019, que detecta cuando se desactiva, esté en bloqueo.
Antes de cambiar una regla de una base, simúlala contra el tráfico real de esa base (Builder, Team y Enterprise).

Cuándo no usar esta opción

Como único aislamiento entre tenants. Vericto no es un mecanismo de aislamiento de tenants: no ve el tenant de la petición ni filtra filas. Úsalo encima del RLS o de una base por tenant, no en su lugar.
Miles de bases pequeñas, una por tenant. Un proxy por base multiplica las instancias, y las bases protegidas cuentan en el plan: agrupa tenants por base, o habla con ventas sobre Enterprise.
Oracle o SQL Server. No hay proxy TCP para esos dialectos: usa la API de runtime con una API key por servicio. La allowlist pasa a ser una decisión que tu código respeta, no un control.

Disponibilidad por plan

Función	Free	Builder	Team	Enterprise
Proxy TCP (PostgreSQL y MySQL)	Sí	Sí	Sí	Sí
Queries al mes (proxy y API de runtime)	500K	5M	50M	Ilimitadas
Bases de datos	1	3	10	A medida
Reglas custom (YAML)	—	5	20	Ilimitadas
Allowlists por agente (VERICTO-087)	—	—	Sí	Sí
Columnas sensibles y enmascaramiento (VERICTO-085)	—	—	Sí	Sí
Simulador de reglas	—	Hasta 30 días	Hasta 90 días	Según contrato (hasta 180 días)

Precios y todos los límites en Precios.