# Prepared Statements and pgbouncer

DevFeed: [Prepared Statements and pgbouncer](<https://devfeed.tech/articles/prepared-statements-and-pgbouncer-34342.md>)

Original publisher: [Read original article](<https://tapoueh.org/blog/2009/05/prepared-statements-and-pgbouncer/>)

Author: Dimitri Fontaine PostgreSQL Major Contributor; Author

Published: 2009-05-13T22:00:00Z

Content type: article

Language: en

Sources: [Dimitri Fontaine](<https://devfeed.tech/sources/dimitri-fontaine.md>)

Topics: [PostgreSQL](<https://devfeed.tech/topics/postgresql.md>), [Scalability](<https://devfeed.tech/topics/scalability.md>), [backends](<https://devfeed.tech/topics/backends.md>)

Tags: [connection-pool](<https://devfeed.tech/tags/connection-pool.md>), [performance](<https://devfeed.tech/tags/performance.md>), [postgresql](<https://devfeed.tech/tags/postgresql.md>), [scalability](<https://devfeed.tech/tags/scalability.md>)

## AI overview

The article discusses using PgBouncer connection pooling with PostgreSQL prepared statements to improve scalability for applications serving many concurrent clients. It describes an application-side preparation check and the preprepare project, which provides a function to prepare statements from a table at connection creation time.

## Source excerpt

On the performance mailing list, a recent thread drew my attention. It devired to be about using a connection pool software and prepared statements in order to increase scalability of PostgreSQL when confronted to a lot of concurrent clients all doing simple select queries. The advantage of the pooler is to reduce the number of backends needed to serve the queries, thus reducing PostgreSQL internal bookkeeping. Of course, my choice of software here is clear: PgBouncer is an excellent top grade solution, performs real well (it won't parse queries), reliable, flexible.