Protocol-aware
Handles PostgreSQL startup, TLS, authentication, simple queries, prepared statements, and common driver behavior on the wire.
PostgreSQL wire proxy
Enforce before PostgreSQL executes.
Place Safe Boundary between an application, ORM, psql session, or database tool and PostgreSQL. It understands the wire protocol and SQL structure, then blocks or rewrites requests before they reach the database.
PostgreSQL wire pathInspect SQL before PostgreSQL executes
Proxy pathSOURCEAPP / ORM
Wire proxySQL parse + policy
TARGETPOSTGRESQLSELECT ...
PARSEDPOLICY MATCHFORWARDED
Why this exists
Add a policy boundary without a database extension
In default passthrough mode, PostgreSQL authentication is relayed and the database still sees the caller’s upstream role. Existing grants and row-level security stay in force.
Observe mode records what policy would do while forwarding unchanged traffic. Enforce mode activates read-only blocking, masking rewrites, dangerous-function denial, and fail-closed handling.
What it does
Concrete controls, stated precisely.
RLS-safe default
Passthrough authentication preserves the PostgreSQL role, so grants and RLS remain authoritative for row access.
Fail-closed enforcement
Syntax errors, non-read-only statements, unsafe functions, and unredactable protected output are refused in enforce mode.
Compatibility check
Confirm the wire assumptions before you switch clients.
The proxy is a protocol boundary, not a generic pooler. Validate the connection features your drivers actually use.
- □Test startup, TLS, authentication, simple queries, prepared statements, and representative ORM traffic.
- □Plan for SCRAM-SHA-256-PLUS limitations when a terminating TLS proxy sits in the path.
- □Keep direct PostgreSQL endpoints private or otherwise unreachable to constrained callers.
- □Exercise observe mode with the same connection pool and driver settings used in production.
How it works
A visible enforcement sequence.
Deploy
Run the proxy beside the workload or in the same private network as PostgreSQL.
Point
Change host and port while retaining the upstream database identity.
Observe
Exercise real traffic and inspect would-block and would-mask events.
Enforce
Activate policy after the rules match the intended access path.
Protected when
- ✓PostgreSQL connections routed to the proxy
- ✓Eligible reads covered by configured masking rules
- ✓Unsafe SQL and dangerous functions recognized by the parser
Important boundaries
- •The proxy is not a connection pooler
- •Direct PostgreSQL endpoints must be isolated separately to prevent bypass
- •SCRAM-SHA-256-PLUS cannot be relayed through a terminating TLS proxy
Continue the story
Related Safe Boundary pages
Architecture →
See how the three enforcement surfaces share policy and audit semantics.
Security model →
Understand trust boundaries, credentials, identity, and bypass conditions.
Preserving RLS →
See which paths keep database row policy intact.
Test the boundary on a real access path.
Start in observe mode and validate the policy against representative traffic before you enforce it. That gives the team evidence for each decision, along with explicit bypass controls for the cases that need a deliberate exception.