We recently became aware that DO's and Heroku's PgBouncer do not allow configuration as we advise, making it impossible for Prisma users to use them in front of their Postgres databases.

In an internal document we researched and documented the problem and its causes that make it necessary to have these 2 configuration options to use PgBouncer. Additionally I came up with 4 suggestion on how we could avoid having to use these configuration options, making it possible for our users to user PgBouncer of DO and Heroku.

After internal discussion we want to look into suggestions 2 and 3 deeper:

2. Clean up manually before/after each transaction
   a) We could send DEALLOCATE ALL manually after each transaction (faking what the PgBouncer configuration would do automatically).
   b) We could send DEALLOCATE ALL manually before each transaction (making sure we have a clean slate before trying to prepare the query).

3. Clean up manually if clash was detected
   We could catch the prepared statement "s2" already exists error when trying to prepare a query, manually send a DEALLOCATE ALL (or even DEALLOCATE s2) query, and then try to prepare the query again.

We are not super sure if these suggestion actually work (2a could be problematic if we can actually send the query before we lose our connection by committing a transaction, 3 could be problematic with losing the transaction (and thus connection) on the error).

Hence we need to investigate.

Comments:
If possible we prefer 3 over 2 as it affects less queries.
If 3 is not possible, 2a more mirrors the PgBouncer behavior, but 2b might be easier to achieve.