<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Pgbouncer - vo.rs</title><link>https://vo.rs/tags/pgbouncer/</link><description>Latest from the Pgbouncer desk at vo.rs.</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.</copyright><lastBuildDate>Tue, 29 Apr 2025 08:15:00 +0000</lastBuildDate><atom:link href="https://vo.rs/tags/pgbouncer/" rel="self" type="application/rss+xml"/><item><title>PgBouncer: Connection Pooling Before You Think You Need It</title><link>https://vo.rs/story/pgbouncer-connection-pooling-before-you-think-you-need-it/</link><description>&lt;p&gt;There is a specific way Postgres falls over that catches homelabbers by surprise, because it strikes when nothing is obviously wrong. The database is not slow, the queries are fine, the disk is idle, and yet the app starts throwing &lt;code&gt;FATAL: sorry, too many clients already&lt;/code&gt; and refusing connections. You raise &lt;code&gt;max_connections&lt;/code&gt;, it works for a week, then it happens again, worse, and eventually the whole box grinds because Postgres is drowning in connections that are each doing almost nothing. This is a problem a connection pooler solves completely, and PgBouncer is the small, boring, twenty-year-old tool that does it. The reason to learn it before you are firefighting is that the failure looks like a scaling problem and is actually a connection-management problem, and the two have opposite fixes.&lt;/p&gt;</description><pubDate>Tue, 29 Apr 2025 08:15:00 +0000</pubDate></item></channel></rss>