--- title: PgBouncer and RLS: tenant context, SET LOCAL, shared plans description: A measured deep-dive into row-level security behind PgBouncer in transaction pooling mode reveals three distinct risks: SET leaks tenant context to the next... canonical: https://daily.dev/posts/pgbouncer-and-rls-tenant-context-set-local-shared-plans-wvpn1fj2i twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: PgBouncer and RLS: tenant context, SET LOCAL, shared plans | daily.dev og:description: A measured deep-dive into row-level security behind PgBouncer in transaction pooling mode reveals three distinct risks: SET leaks tenant context to the next... og:url: https://daily.dev/posts/pgbouncer-and-rls-tenant-context-set-local-shared-plans-wvpn1fj2i og:image: https://api.daily.dev/og/posts/wvPN1fj2i.png og:image:alt: PgBouncer and RLS: tenant context, SET LOCAL, shared plans og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # PgBouncer and RLS: tenant context, SET LOCAL, shared plans **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 10 min read · 0 upvotes · 0 comments ## Summary A measured deep-dive into row-level security behind PgBouncer in transaction pooling mode reveals three distinct risks: SET leaks tenant context to the next client on a reused connection, SET LOCAL outside an explicit transaction silently does nothing (and combined with a prior SET leak, causes a real cross-tenant data exposure), and PgBouncer's protocol-level prepared statement sharing causes tenants to reuse each other's query plans, causing up to 10x slower queries. Concrete fixes are given: wrap tenant context in explicit BEGIN/SET LOCAL/COMMIT transactions, read back the tenant setting to verify it, write RLS policies using nullif() for deterministic behavior on missing tenants, and set plan_cache_mode = force_custom_plan alongside parameterized queries to avoid shared generic plans. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does SET LOCAL do nothing when setting a tenant variable for row-level security outside a transaction? In autocommit mode every statement is its own transaction, so a standalone SET LOCAL statement runs outside any transaction block and PostgreSQL emits a warning while applying no effect. This is dangerous behind PgBouncer in transaction pooling because a subsequent query on the same connection can silently read data belonging to whichever tenant polluted the connection earlier with plain SET. _Anyone wiring tenant isolation through a pooler can track these RLS pitfalls and fixes on daily.dev._ ### Does PgBouncer share query plans between different tenants when using row-level security without query parameters? Yes, since PgBouncer 1.21 (default-on since 1.24) it tracks protocol-level prepared statements, so when multiple clients send the same SQL text on one server connection they share a single generic plan. Measured with PostgreSQL 17.10 and PgBouncer 1.25.2, a large tenant's plan reused for a small tenant caused a 10x slowdown (7.6ms vs 0.62ms), and vice versa 137ms vs 77ms. _Teams debugging inconsistent multi-tenant query latency can follow this kind of pooler-level benchmarking via daily.dev._ ### How do I fix PostgreSQL query plan sharing across tenants caused by PgBouncer prepared statement caching? Pass the tenant id as a bound parameter rather than relying solely on current_setting() in the policy, and set plan_cache_mode = force_custom_plan on the application's database role so every execution gets a plan tailored to its own tenant. Testing showed this matched the performance of an unprepared query, while plan_cache_mode alone does nothing for parameter-less queries since it only affects statements that have parameters. _Developers tuning multi-tenant query performance can keep up with practical PostgreSQL fixes like this through daily.dev._ ## Similar posts on daily.dev - [PostgreSQL row-level security for SaaS: what we measured](https://daily.dev/posts/postgresql-row-level-security-for-saas-what-we-measured-wxhmymmnr) · Planet PostgreSQL · 0 upvotes · 0 comments - [Sharing is \(not always\) caring. PgBouncer pooling modes in practice.](https://daily.dev/posts/sharing-is-not-always-caring-pgbouncer-pooling-modes-in-practice--4dfgv5c5q) · Event-Driven by Oskar Dudycz · 0 upvotes · 0 comments - [Beyond tenant\_id: Treating Multi-Tenancy as a Database Invariant](https://daily.dev/posts/beyond-tenant-id-treating-multi-tenancy-as-a-database-invariant-dpssptbwc) · RUBYLAND · 10 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#postgresql](https://daily.dev/tags/postgresql), [#multi-tenancy](https://daily.dev/tags/multi-tenancy) [View this post on daily.dev](https://daily.dev/posts/pgbouncer-and-rls-tenant-context-set-local-shared-plans-wvpn1fj2i) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"PgBouncer and RLS: tenant context, SET LOCAL, shared plans","url":"https://daily.dev/posts/pgbouncer-and-rls-tenant-context-set-local-shared-plans-wvpn1fj2i","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/pgbouncer-and-rls-tenant-context-set-local-shared-plans-wvpn1fj2i"},"datePublished":"2026-09-30T23:32:45.334Z","dateModified":"2026-09-30T23:33:10.348Z","description":"A measured deep-dive into row-level security behind PgBouncer in transaction pooling mode reveals three distinct risks: SET leaks tenant context to the next...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/fdeacaf2a945e58380479dc8aaeeee27?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/fdeacaf2a945e58380479dc8aaeeee27?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/pgbouncer-and-rls-tenant-context-set-local-shared-plans-wvpn1fj2i","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"database,postgresql,multi-tenancy","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"PgBouncer and RLS: tenant context, SET LOCAL, shared plans"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/pgbouncer-and-rls-tenant-context-set-local-shared-plans-wvpn1fj2i#faq","mainEntity":[{"@type":"Question","name":"Why does SET LOCAL do nothing when setting a tenant variable for row-level security outside a transaction?","acceptedAnswer":{"@type":"Answer","text":"In autocommit mode every statement is its own transaction, so a standalone SET LOCAL statement runs outside any transaction block and PostgreSQL emits a warning while applying no effect. This is dangerous behind PgBouncer in transaction pooling because a subsequent query on the same connection can silently read data belonging to whichever tenant polluted the connection earlier with plain SET. Anyone wiring tenant isolation through a pooler can track these RLS pitfalls and fixes on daily.dev."}},{"@type":"Question","name":"Does PgBouncer share query plans between different tenants when using row-level security without query parameters?","acceptedAnswer":{"@type":"Answer","text":"Yes, since PgBouncer 1.21 (default-on since 1.24) it tracks protocol-level prepared statements, so when multiple clients send the same SQL text on one server connection they share a single generic plan. Measured with PostgreSQL 17.10 and PgBouncer 1.25.2, a large tenant's plan reused for a small tenant caused a 10x slowdown (7.6ms vs 0.62ms), and vice versa 137ms vs 77ms. Teams debugging inconsistent multi-tenant query latency can follow this kind of pooler-level benchmarking via daily.dev."}},{"@type":"Question","name":"How do I fix PostgreSQL query plan sharing across tenants caused by PgBouncer prepared statement caching?","acceptedAnswer":{"@type":"Answer","text":"Pass the tenant id as a bound parameter rather than relying solely on current_setting() in the policy, and set plan_cache_mode = force_custom_plan on the application's database role so every execution gets a plan tailored to its own tenant. Testing showed this matched the performance of an unprepared query, while plan_cache_mode alone does nothing for parameter-less queries since it only affects statements that have parameters. Developers tuning multi-tenant query performance can keep up with practical PostgreSQL fixes like this through daily.dev."}}]} ```