Why doesn't the transaction pooler support prepared statements the way a direct connection does?

A prepared statement is parsed and planned once, then referenced by name on later executions — but that only works if every subsequent execution reuses the exact same underlying Postgres connection that did the original preparation, since the prepared statement lives in that specific backend process's session state.

Transaction-mode pooling breaks that assumption by design: a client's connection is handed a real Postgres backend only for the duration of a single transaction, and as soon as that transaction commits, the underlying connection is returned to the pool and may be handed to a completely different client next. There's no guarantee the next statement from the same logical client lands on the same backend, so a prepared statement created moments earlier may simply not exist anymore from that connection's point of view.

The practical workaround is to avoid relying on named prepared statements when using the transaction pooler — most drivers and the Supabase client library already account for this and send plain, unprepared statements over pooled connections, reserving actual prepared-statement usage for direct or session-mode connections where the same backend is guaranteed to persist for the client's session.

Invest now in Acorns!!! 🚀
Join Acorns and get your $5 bonus!

Acorns is a micro-investing app that automatically invests your "spare change" from daily purchases into diversified, expert-built portfolios of ETFs. It is designed for beginners, allowing you to start investing with as little as $5. The service automates saving and investing. Disclosure: I may receive a referral bonus.

Invest now!!! Get Free equity stock (US, UK only)!

Use Robinhood app to invest in stocks. It is safe and secure. Use the Referral link to claim your free stock when you sign up!.

The Robinhood app makes it easy to trade stocks, crypto and more.

Webull! Receive free stock by signing up using the link: Webull signup.