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.