TCP proxy

Microservices and Kubernetes: one proxy per database or a sidecar per pod

With many services, each with its own database access, it is hard to know what SQL reaches production. The Vericto TCP proxy is deployed inside the cluster, as a shared service in front of each database or as a sidecar next to each service, and applies the same rules to all traffic, in any language.

Start free Deploy the proxy on Kubernetes
Diagram: microservices on Kubernetes with the Vericto proxyInside a Kubernetes cluster, the orders-api and catalog-api services connect to a shared Vericto proxy, a Deployment with two replicas and its Service, which evaluates every statement before orders-db on PostgreSQL. Below, the payments-api service runs the proxy as a sidecar in its pod, on localhost:5433, in front of payments-db on MySQL. The proxy gets its rules from Vericto Cloud and sends it telemetry.Kubernetes clusterPod with a sidecarallowedallowedrules · telemetryorders-apicatalog-apiShared proxyDeployment, 2 replicasEvaluates hereorders-dbPostgreSQLpayments-apiSidecar proxylocalhost:5433Evaluates herepayments-dbMySQLVericto Cloudrules and audit trailDiagram: microservices on Kubernetes with the Vericto proxyInside a Kubernetes cluster, the orders-api and catalog-api services connect to a shared Vericto proxy, a Deployment with two replicas and its Service, which evaluates every statement before orders-db on PostgreSQL. Below, the payments-api service runs the proxy as a sidecar in its pod, on localhost:5433, in front of payments-db on MySQL. The proxy gets its rules from Vericto Cloud and sends it telemetry.Kubernetes clusterPod with a sidecarrules · telemetryVericto Cloudrules and audit trailorders-apicatalog-apiShared proxyDeployment, 2 replicasEvaluates hereorders-dbPostgreSQLpayments-apiSidecar proxylocalhost:5433Evaluates herepayments-dbMySQL
  • SQL statement path
  • Vericto Cloud: rules and telemetry
  • Where Vericto evaluates
Two patterns in the same cluster: above, a proxy shared by the services that use orders-db; below, a sidecar inside the payments-api pod. Each proxy syncs its rules with Vericto Cloud.

What it protects

The same rules and policies for every service that uses a database, without a library per language:

  • VERICTO-001, 042, 010 and 011: DELETE and UPDATE without WHERE, DROP TABLE and TRUNCATE, from whichever service.
  • VERICTO-015 to 019: risky DDL at runtime, such as ALTER TABLE … DROP COLUMN or disabling triggers and RLS.
  • VERICTO-087 (Team and Enterprise): an allowlist of tables and columns per identity. At the proxy, the identity is the session's database user: give each service its own user and its own allowlist.
  • VERICTO-085 (Team and Enterprise): sensitive columns blocked or masked in the result, for every service at once.

Latency and availability

With a sidecar, the hop between the service and the proxy is localhost inside the pod. With a shared proxy, it is one more hop inside the cluster. Either way, parsing and evaluation happen in the proxy process, with no network calls on the critical path.

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.

Recommended sizes: from 0.25 vCPU and 64 MB (up to 1,000 queries per second) to 1 vCPU and 256 MB (50,000 or more). Memory grows with connections, about 4 KB per TCP session: a sidecar per pod multiplies small instances; a shared proxy concentrates a database's traffic in a few replicas.

How to implement it

  1. Register each database and create an API key with rules:read and telemetry:write. Store it as a Kubernetes Secret.
  2. Shared proxy: a Deployment with two replicas and a Service per database (the manifest is in the guide). The services point their connection string at vericto-proxy:5433.
  3. Sidecar: add the ghcr.io/vericto/vericto-proxy container to the pod and connect the service to localhost:5433. Inside the pod, TLS between the application and the proxy can stay disabled.
  4. If the database is managed (RDS, Cloud SQL), encrypt the proxy → database hop with UPSTREAM_SSLMODE=require or verify-full: TLS.
  5. If the audit trail must not lose events, use VERICTO_TELEMETRY_BUFFER=disk with a persistent volume: telemetry buffering.
  6. Give each service its own database user, to see and limit its traffic separately. On ECS (Fargate), the guide has the task definition.

When not to use this option

  • Services on Oracle or SQL Server. Use the Runtime API, with its safety limit of 100 requests per second per API key (it can be raised if you need it).
  • A service mesh with end-to-end TLS to the database. The proxy needs to see the SQL: client TLS must terminate at the proxy (PROXY_TLS_MODE=require) and be opened again towards the database.
  • One application and one database. You need none of this: see web application.

Plan availability

FeatureFreeBuilderTeamEnterprise
TCP proxy, Runtime API, CLI and MCPYesYesYesYes
Queries per month (proxy and Runtime API)500K5M50MUnlimited
Databases1310Custom
Per-agent allowlists (VERICTO-087)——YesYes
Sensitive columns and masking (VERICTO-085)——YesYes
Rule simulator—Up to 30 daysUp to 90 daysPer contract (up to 180 days)
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