TCP proxy

Classic web application: the TCP proxy between your app and the database

In a web application, one code path, a support script or a misconfigured ORM can send a DELETE without WHERE to production. The Vericto TCP proxy sits between the connection pool and Postgres or MySQL and evaluates every statement before it reaches the database, without changing your code: only the host in the connection string changes.

Start free TCP proxy guide
Diagram: web application with the Vericto TCP proxyUsers call the web application; its connection pool sends SQL to the Vericto proxy, which runs in your infrastructure and evaluates every statement. Allowed ones go on to PostgreSQL or MySQL; a blocked one returns to the application as a SQLSTATE 42501 or ERROR 1142 error. The proxy gets its rules from Vericto Cloud and sends it telemetry.Your infrastructurerules · telemetryblocked: SQLSTATE 42501 · ERROR 1142UsersWeb applicationconnection poolVericto proxyTCP · port 5433Evaluates hereDatabasePostgreSQL or MySQLVericto Cloudrules and audit trailDiagram: web application with the Vericto TCP proxyUsers call the web application; its connection pool sends SQL to the Vericto proxy, which runs in your infrastructure and evaluates every statement. Allowed ones go on to PostgreSQL or MySQL; a blocked one returns to the application as a SQLSTATE 42501 or ERROR 1142 error. The proxy gets its rules from Vericto Cloud and sends it telemetry.Your infrastructureSQL, same credentialsallowedUsersWeb applicationconnection poolVericto proxyTCP · port 5433Evaluates hereDatabasePostgreSQL or MySQLVericto Cloudrules and audit trail
  • SQL statement path
  • Vericto Cloud: rules and telemetry
  • Blocked statement: an error comes back
  • Where Vericto evaluates
The proxy runs in your infrastructure and evaluates in its own process; Vericto Cloud only sends it the rules and receives telemetry. Your credentials never leave your network.

What it protects

The standard rules apply to every statement that goes through the proxy. In a web application, the ones that most often fire:

A blocked statement never reaches the database: the application gets its driver's native error, SQLSTATE 42501 on Postgres and ERROR 1142 on MySQL, with the rule that blocked it.

Latency and availability

The proxy adds one network hop, from the application to the proxy, plus the parsing and evaluation of each statement, which happen in its own process with no network calls on the critical path. Put it on the same network as the application (same host, subnet or VPC) so that hop stays short.

For parsing and rule evaluation, the design target is p99 < 2 ms. It is a target, not a measurement: the proxy latency benchmark is not published yet.

The proxy's availability depends on your deployment, because it runs in your infrastructure. Rules sync every 5 minutes by default (VERICTO_RULES_SYNC_INTERVAL_SECS, 30 s minimum) and telemetry never delays evaluation: it is sent asynchronously, after the decision.

How to implement it

  1. Create a workspace, register the database with its dialect (PostgreSQL or MySQL) and copy its Database ID: integration guide.
  2. Create an API key with the rules:read and telemetry:write scopes: that is all the proxy needs.
  3. Deploy the container ghcr.io/vericto/vericto-proxy next to your application (Docker, Kubernetes or ECS), with UPSTREAM_HOST pointing at your database.
  4. Point the host and port of the connection string at the proxy (5433 on Postgres, 3307 on MySQL). The credentials do not change: configuration reference.
  5. Start in observe mode: check in the dashboard what would have been blocked, then enforce the rules.
  6. Before changing a rule, simulate it against your real traffic (Builder, Team and Enterprise).

When not to use this option

  • Oracle or SQL Server. There is no TCP proxy for those dialects: use the Runtime API before running each query.
  • You cannot change the host the application connects to. The Runtime API evaluates over HTTP without touching the network; your code runs the query only if the answer is not BLOCKED.
  • Opaque end-to-end TLS. SCRAM channel binding (SCRAM-SHA-256-PLUS) and end-client cert authentication do not work through a proxy that inspects the SQL, by design.
  • Stopping SQL before the merge. That is the CLI in CI: see CI/CD and migrations. Most teams use both.

Plan availability

FeatureFreeBuilderTeamEnterprise
TCP proxy, Runtime API, CLI and MCPYesYesYesYes
Queries per month (proxy and Runtime API)500K5M50MUnlimited
Databases1310Custom
Custom rules (YAML)—520Unlimited
Rule simulator—Up to 30 daysUp to 90 daysPer contract (up to 180 days)
Sensitive columns and masking (VERICTO-085)——YesYes
VPC deployment———Yes

Prices and every limit on Pricing.

Try it with your own SQL

The Free plan includes 500K queries a month and 1,000 CLI and MCP validations, with no credit card. For deployments in your VPC, SSO and dedicated SLAs, talk to sales.

Start free Talk to sales