2 posts tagged with "pgbouncer"

Every database connection costs memory. PostgreSQL forks a backend process per connection (roughly 5-10 MB each), and MySQL allocates per-thread buffers that scale with your buffer configuration. At 200 concurrent connections, the overhead is manageable. At 2,000, you are spending gigabytes of RAM on connection state instead of query execution.

Connection pooling sits between your application and the database, multiplexing many client connections over a small number of backend connections. FoundryDB provides PgBouncer for PostgreSQL and ProxySQL for MySQL, both managed through the API with no manual SSH or config file editing required.

Most PostgreSQL workloads are read-heavy. Dashboards, reporting queries, search, and API endpoints that serve cached-but-still-queried data all put pressure on a single primary. Vertical scaling helps, but at some point you are paying for CPU that only writes use while reads compete for the same connections.

Read replicas solve this by giving you additional PostgreSQL nodes that serve read queries from a continuously updated copy of your data. On FoundryDB, adding a replica takes one API call and a few minutes of provisioning time.