Jan Piotrowski

https://github.com/prisma/prisma/issues/7790 until recently also included the "rename table (model)" use case, but there might be value in tracking these separately @zomars so I renamed that issue and reopened yours 👍

Did anyone try running their test suites against a this new PgBouncer version and `max_prepared_statements` configured, either with or without `pgbouncer=true`? That would probably be a good first data point.

We actually have reports now that _with_ `pgbouncer=true` you will get an error: https://github.com/prisma/prisma/issues/21635 That conflicts with your observations @MorenoMdz, correct? What error message exactly are you getting in your...

That might be the problem: The new functionality is only enabled when `max_prepared_statements` is set to a non `0` value. Otherwise 1.21 behaves exactly like older PgBouncer versions (which would...

Unfortunately not. I have not looked deeper into this.

Can you also test running Introspection and/or Migration via the PgBouncer you setup? Thanks @jineshshah36. (We are now also starting to test this, but any help is welcome in figuring...

Hm, after reading https://www.pgbouncer.org/config.html#max_prepared_statements in detail I would actually be surprised if this _just works_ without `pgbouncer=true`. Multiple instances of Prisma Client would probably try to prepare different queries with...

> Also asked about it: https://github.com/pgbouncer/pgbouncer/discussions/973 Seems that part is probably fine as PgBouncer deals with that properly. A problem we found already is when you use `schema=foo` in your...

> Isn't the search_path problem an issue with pgbouncer=true as well? Exactly @JelteF, my comment means that upgrading to PgBouncer 1.21.0 does not magically make `pgbouncer=true` (for our own PgBouncer...

Ah, understood: `pgbouncer=true` makes Prisma skip the `SET search_path = ...` query basically only. We qualify tables by default - except for user-provided raw queries, which might not work as...