> Markdown version of [/videos/1951-we-gave-every-tenant-a-postgres-connection-string?t=1049](https://www.wearedevelopers.com/videos/1951-we-gave-every-tenant-a-postgres-connection-string?t=1049). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# We Gave Every Tenant a Postgres Connection String

How do you give SaaS tenants a raw Postgres connection string without leaking shared metadata? Learn how a custom TCP proxy achieves virtual single tenancy at the protocol level.

- **Speakers:** [Mert Ersoy](https://www.wearedevelopers.com/@mert-ersoy)
- **Event:** World Congress 2026 Europe - Virtual Stage
- **Published:** July 1, 2026
- **Duration:** 22:19
- **URL:** https://www.wearedevelopers.com/videos/1951-we-gave-every-tenant-a-postgres-connection-string

## Summary

Enterprise SaaS customers increasingly demand direct SQL access for their business intelligence tools, as standard REST APIs cannot efficiently handle complex joins or data aggregations. To prevent users from churning to self-hosted alternatives, this engineering team made the unconventional choice to provide a permanent, read-only Postgres connection string to every customer—despite running a heavily sharded, multi-tenant cloud environment where hundreds of tenants share a single database.

The primary technical challenge was metadata leakage. While native Postgres read-only roles effectively restrict data access, they still allow users to view other tenants' schema and table names via system catalogs, which row-level security cannot completely hide. Rather than taking on the operational nightmare of provisioning a single-tenant database for every customer, the team achieved “virtual single tenancy at the protocol level” by building a custom TCP proxy. Sitting between the client and the shared database server, this man-in-the-middle proxy speaks the Postgres wire protocol, parsing and rewriting query catalogs so that clients strictly see their own schemas.

This architecture relies on a robust two-layer security model: native database roles enforce what can be queried, while the proxy controls what is visible. The proxy successfully handles both simple queries and prepared statement protocols by comprehensively reassembling TCP packets. Crucially, it operates on a strict fail-closed security posture; any query that cannot be parsed and definitively proven safe is instantly rejected. Although the approach introduces engineering trade-offs—such as breaking `pg_dump` compatibility and requiring ongoing deny-list maintenance for new Postgres versions—shipping this pragmatic SQL endpoint successfully retained enterprise customers without sacrificing the efficiency of shared multi-tenant infrastructure.

**Keywords:** postgres wire protocol, multi-tenant database architecture, virtual single tenancy, database tcp proxy, system catalog isolation, fail closed security, read-only database roles, row-level security limitations, prepared statement protocol, query parsing and rewriting, business intelligence database access, pg_dump compatibility

## Chapters

1. **Giving multi-tenant customers direct Postgres connections** (00:01) — Connecting to a shared database natively exposes schemas across tenants, creating a security issue that requires a proxy solution.
1. **Why data workflows require raw SQL over REST APIs** (01:38) — Providing direct database access prevents customers from self-hosting by allowing custom joins and aggregations directly in standard tooling.
1. **Native Postgres security gaps in multi-tenant environments** (03:01) — Traditional read-only roles and row-level security still expose global system catalogs to all tenants on a shared server.
1. **The operational cost of single-tenant databases** (05:27) — Provisioning isolated databases for individual customers creates significant overhead for infrastructure setup, idle computing, and backup management.
1. **Implementing virtual single tenancy via TCP proxying** (06:11) — A man-in-the-middle TCP proxy sits between clients and the database to rewrite traffic and provide catalog isolation.
1. **Processing client connections and mapping workspace identifiers** (08:17) — The proxy reads initial connection configurations to validate customer records and logically route traffic to the correct underlying physical database.
1. **The proxy pipeline for parsing and rewriting queries** (09:49) — Incoming requests are checked against a configured blocklist, parsed into syntax trees, and injected with subqueries to hide unauthorized tables.
1. **Handling the Postgres prepared statement protocol** (12:16) — Reassembling and reframing cross-packet execution steps is necessary to properly intercept and modify persistent database statements.
1. **Failing closed to prevent undiscovered security bypasses** (13:12) — Rejecting unrecognized query shapes and strictly dropping administrative functions eliminates privilege escalation and internal reconnaissance risks.
1. **Enforcing query limits and execution timeouts per session** (14:54) — Applying strict rate limits and layered transaction timeouts ensures public SQL endpoints remain cheap to run and resistant to abuse.
1. **Configuring native Postgres roles for read-only workspaces** (15:56) — Revoking default permissions and explicitly granting selective schema access acts as a secure native backup layer behind the TCP proxy.
1. **Seamless business intelligence integration with raw connections** (16:47) — Providing standard protocol credentials allows external utilities to immediately analyze database records without specialized SDKs or data pipelines.
1. **Identifying technical tradeoffs in database proxy architectures** (17:29) — Enforced catalog isolation breaks standard dump utilities and requires ongoing parser maintenance whenever new Postgres protocol surfaces are released.
1. **Choosing pragmatic proxy architectures to retain cloud customers** (20:01) — Accepting minor capability gaps over perfect database isolation successfully prevents customer churn while providing practical analytics integrations.

## Related Moments

- [Deployment architectures for scalable multi-tenant database environments](https://www.wearedevelopers.com/videos/1552-building-multi-tenant-asp-net-core-applications-best-practices-and-real-world-solutions) (from "Building Multi-Tenant ASP.NET Core Applications: Best Practices and Real-World Solutions")
- [Choosing relational databases over NoSQL for most workloads](https://www.wearedevelopers.com/videos/100135-the-new-shiny-syndrome-how-to-avoid-tech-hype-traps) (from "The New Shiny Syndrome: How to Avoid Tech Hype Traps")
- [Migrating moving data targets without disrupting active engineering teams](https://www.wearedevelopers.com/videos/100311-swapping-a-data-warehouse-at-runtime-zero-downtime-migration-without-changing-a-single-client) (from "Swapping a Data Warehouse at Runtime: Zero-Downtime Migration Without Changing a Single Client")
- [Making Postgres databases stateless using cloud-native storage systems](https://www.wearedevelopers.com/videos/1042-postgres-in-the-age-of-ai-and-devin) (from "Postgres in the Age of AI (and Devin)")
- [Advantages and challenges of multi-tenant application architecture](https://www.wearedevelopers.com/videos/1552-building-multi-tenant-asp-net-core-applications-best-practices-and-real-world-solutions) (from "Building Multi-Tenant ASP.NET Core Applications: Best Practices and Real-World Solutions")
- [Embracing high opinionation to simplify web application architecture](https://www.wearedevelopers.com/videos/112-is-django-too-complicated) (from "Is Django too Complicated?")

## Related Articles

- [Making Data Warehouses Fast: A Developer’s Story](https://www.wearedevelopers.com/magazine/107-making-data-warehouses-fast-a-developer-s-story)
- [Dev Digest 168: Hacking Postgres, Blocking Meta and Fixing CSS](https://www.wearedevelopers.com/magazine/588-dev-digest-168-hacking-postgres-blocking-meta-and-fixing-css)
- [Effortlessly Scale Prometheus With The Telemetry Data Platform – And Keep your Grafana Dashboards, Too!](https://www.wearedevelopers.com/magazine/3-effortlessly-scale-prometheus-with-the-telemetry-data-platform-and-keep-your-grafana-dashboards-too)
- [Everything a Developer Needs to Know About MCP with Neo4j](https://www.wearedevelopers.com/magazine/604-everything-a-developer-needs-to-know-about-mcp-with-neo4j)

## Related Jobs

- [Lead Software Engineer - Data Engineering](https://www.wearedevelopers.com/jobs/ext/2000968-lead-software-engineer-data-engineering) at **Dynatrace**
- [Staff Software Engineer](https://www.wearedevelopers.com/jobs/ext/1425755-staff-software-engineer) at **GitHub**
- [Senior Backend Developer — AI: MCP & Agent Engine](https://www.wearedevelopers.com/jobs/48297-senior-backend-developer-ai-mcp-agent-engine) at **basebox GmbH**
- [Principal Software Engineer, Database Infrastructure](https://www.wearedevelopers.com/jobs/ext/1465908-principal-software-engineer-database-infrastructure) at **GitHub**
- [Staff Business Intelligence Engineer](https://www.wearedevelopers.com/jobs/ext/626164-staff-business-intelligence-engineer) at **Twilio**
- [Cloud Engineer (Tenant)](https://www.wearedevelopers.com/jobs/48331-cloud-engineer-tenant) at **Riverty**