We Gave Every Tenant a Postgres Connection String

Enterprise customers kept choosing self-hosting over our cloud for one reason: they needed direct database access. Their BI tools, scripts and workflows all depended on SQL, something REST APIs couldn’t replace. Most SaaS products moving to cloud remove direct SQL access. We went the other way.

Postgres roles control what you can query, not what you can see. Row-level security doesn’t apply to system catalogs. A database per tenant would fix visibility BUT at 165K+ schemas across 800+ databases, that’s not an option.

Instead I built virtual single-tenancy at the protocol level. A TCP proxy that speaks the wire protocol, sits between every client and their shared database, parses every query into an AST and rewrites system catalogs at both the text and OID level so tenants see only their own objects. Dangerous operations that can’t be verified get blocked before they even reach Postgres. But why? Postgres isn’t broken. System catalogs expose every schema on the instance, a readonly user can ALTER ROLE to change their own password. Both behaviors are correct in a single-tenant database but they’re security gaps in ours.

Live demo: a direct connection to a shared Postgres, thousands of schemas flooding the client. Then the same database through the proxy, scoped to one tenant. The difference is the entire talk in 30 seconds.

Now each tenant gets a permanent, read-only Postgres connection string, compatible with psql, Metabase, Power BI or any tool that speaks SQL. It works… until it doesn’t. Some SQL statements don’t survive the rewrite cleanly. For example pg_dump doesn’t work at all because it requires permissions that break tenant isolation. Tenants fall back to SQL queries for export, which works but isn’t the zero-friction experience we wanted. The rest of the talk is about everything that goes wrong and why we shipped it anyway.