I Put a Rust Proxy Between My App and PostgreSQL. Here's What Happens to Every Connection.

A PostgreSQL connection succeeds.

Your application runs a query.

Everything looks normal.

But how do you know that connection is operating under the correct tenant's permissions?

That's the problem I've been exploring while building Agata Proxima.

Instead of relying entirely on application-level tenant filters, I built an open-source Rust proxy that sits between an application and its existing PostgreSQL database.

Here's how it works.

1. The application connects to the proxy

Your application keeps its PostgreSQL driver. Instead of connecting directly to PostgreSQL, it connects to Proxima Engine.

The engine accepts PostgreSQL-protocol connections and handles the connection startup process.

1. Tenant identity is verified

When tenant enforcement is configured, the engine validates signed tenant context.

That includes checking the tenant identifier, token expiry, and signature.

Invalid or missing tenant context is rejected.

The important distinction: the engine doesn't simply trust a tenant ID supplied by the client.

1. Verified tenants are mapped to database roles

After successful verification, the engine maps the tenant identity to a PostgreSQL role.

PostgreSQL grants and Row-Level Security policies remain responsible for restricting database access.

The proxy adds another enforcement boundary. It doesn't replace PostgreSQL's own security model.

1. Database traffic passes through the engine

The engine establishes an upstream PostgreSQL connection and relays protocol messages.

It also exposes health, status, and Prometheus metrics for operational visibility.

1. Isolation needs to be tested, not assumed

This is the part I find most important.

A successful database connection doesn't prove tenant isolation.

You need negative tests.

Can Tenant A read Tenant B's records? What happens when tenant context is missing, expired, or invalid?

The repository includes a tenant isolation lab demonstrating allowed and denied access using PostgreSQL roles and RLS.

Try the open-source engine

The engine can be started locally using Docker Compose:

git clone https://github.com/Agata-Proxima/proxima-engine.git
cd proxima-engine
docker compose -f compose.dev.yaml up --build -d

From there, you can run the documented quickstart and tenant isolation tests.

GitHub: https://github.com/Agata-Proxima/proxima-engine

Platform: https://agataproxima.com

One question for backend engineers

Would you prefer tenant isolation enforced exclusively through application code and PostgreSQL RLS, or woul
d you consider an additional proxy-level verification boundary?

I'm especially interested in the trade-offs: latency, connection pooling, operational complexity, and failure handling.