Arquitectura de referencia: aplicación web con Postgres o MySQL

Aplicación web clásica: el proxy TCP entre tu aplicación y la base de datos

En una aplicación web, un camino del código, un script de soporte o un ORM mal configurado puede enviar un DELETE sin WHERE a producción. El proxy TCP de Vericto se instala entre el pool de conexiones y Postgres o MySQL y evalúa cada sentencia antes de que llegue a la base, sin cambiar tu código: solo cambia el host del connection string.

Qué protege

Las reglas estándar se aplican a cada sentencia que pasa por el proxy. En una aplicación web, las que más suelen dispararse:

VERICTO-001 y VERICTO-042: DELETE y UPDATE sin WHERE, el error más caro de un script o de un ORM.
VERICTO-010, VERICTO-011 y VERICTO-012: DROP TABLE, TRUNCATE y DROP SCHEMA en producción.
VERICTO-090: tautologías como OR 1=1 en un WHERE, el patrón típico de una inyección SQL.
VERICTO-085 (Team y Enterprise): las columnas que etiquetas como sensibles se bloquean o se devuelven enmascaradas.

Una sentencia bloqueada no llega a la base: la aplicación recibe el error nativo de su driver, SQLSTATE 42501 en Postgres y ERROR 1142 en MySQL, con la regla que la bloqueó.

Latencia y disponibilidad

El proxy añade un salto de red, de la aplicación al proxy, y el parsing y la evaluación de cada sentencia, que ocurren en su propio proceso, sin llamadas de red en la ruta crítica. Ponlo en la misma red que la aplicación (mismo host, subred o VPC) para que ese salto sea corto.

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.

La disponibilidad del proxy depende de tu despliegue, porque corre en tu infraestructura. Las reglas se sincronizan cada 5 minutos por defecto (VERICTO_RULES_SYNC_INTERVAL_SECS, mínimo 30 s) y la telemetría nunca retrasa la evaluación: se envía de forma asíncrona, después de decidir.

Cómo implementarlo

Crea un workspace, registra la base de datos con su dialecto (PostgreSQL o MySQL) y copia su Database ID: guía de integración.
Crea una API key con los scopes rules:read y telemetry:write: es lo único que el proxy necesita.
Despliega el contenedor ghcr.io/vericto/vericto-proxy junto a tu aplicación (Docker, Kubernetes o ECS), con UPSTREAM_HOST apuntando a tu base.
Cambia el host y el puerto del connection string al proxy (5433 en Postgres, 3307 en MySQL). Las credenciales no cambian: referencia de configuración.
Empieza en modo observación: revisa en el dashboard lo que se habría bloqueado y luego aplica las reglas.
Antes de cambiar una regla, simúlala contra tu tráfico real (Builder, Team y Enterprise).

Cuándo no usar esta opción

Oracle o SQL Server. No hay proxy TCP para esos dialectos: usa la API de runtime antes de ejecutar cada query.
No puedes cambiar el host al que se conecta la aplicación. La API de runtime evalúa por HTTP sin tocar la red; tu código ejecuta la query solo si la respuesta no es BLOCKED.
TLS opaco de extremo a extremo. El channel binding de SCRAM (SCRAM-SHA-256-PLUS) y la autenticación cert del cliente final no funcionan a través de un proxy que inspecciona el SQL, por diseño.
Frenar el SQL antes del merge. Eso es la CLI en CI: ver CI/CD y migraciones. La mayoría de los equipos usan los dos.

Disponibilidad por plan

Función	Free	Builder	Team	Enterprise
Proxy TCP, API de runtime, CLI y MCP	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
Simulador de reglas	—	Hasta 30 días	Hasta 90 días	Según contrato (hasta 180 días)
Columnas sensibles y enmascaramiento (VERICTO-085)	—	—	Sí	Sí
Despliegue en tu VPC	—	—	—	Sí

Precios y todos los límites en Precios.