Зависит от pool_mode.
В режиме session баунсер прозрачен для приложения: не налагает каких-то явных ограничений на использование, но один клиент к баунсеру = один коннект к базе. Соединение с базой сможет быть передано другому клиенту только после того как предыдущий клиент отключится. Поэтому этот режим используется очень редко.
В режиме transaction пула коннект к базе выдаётся клиенту только на время транзакции. Самый распространённый режим работы, любим именно за то, что сколько бы тысяч коннектов не открыло приложение к баунсеру, на базе открыто небольшое число действительно потребовавшихся соединений.
Но этот режим пула налагает ограничения на работу приложения. Вы не сможете нормально использовать ничего, что меняет состояние коннекта, потому что следующий ваш запрос с высокой вероятностью попадёт в другой коннект. То есть курсоры, временные таблицы, set (кроме set local), prepared statements (где parse, bind и execute могут разойтись по 3 разным коннектам)
С prepared statements в transaction pool mode с недавних пор может помочь настройка max_prepared_statements, но только если prepare и deallocate выполняются именно командами протокола, но не SQL запросами. Тут многие широкоиспользуемые библиотеки оказались в пролёте.
Средний
