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

Description and use

Proxima Engine, a Rust proxy, validates tenant context and maps to PostgreSQL roles, adding an extra isolation layer in a multi‑tenant app.

Problem

Ensuring tenant isolation in a multi‑tenant application when using PostgreSQL, without relying solely on application‑level filters.

Outcome

The proxy adds an extra enforcement boundary, ensuring that only verified tenants can establish connections and that tenant isolation is validated through negative tests.

Workflow

• 1. Application connects to Proxima Engine using its PostgreSQL driver.
• 2. Engine accepts PostgreSQL‑protocol connections and performs the startup handshake.
• 3. Engine verifies signed tenant context (tenant ID, token expiry, signature).
• 4. On success, engine maps tenant identity to a PostgreSQL role and establishes an upstream connection.
• 5. Engine relays protocol messages between application and PostgreSQL.
• 6. Health, status, and Prometheus metrics are exposed for operational visibility.
• 7. Negative tests are run to confirm isolation (e.g., Tenant A cannot read Tenant B’s records).

Evidence

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.

Source

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.

Source

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.

Source

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?

Source