<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Postgres - vo.rs</title><link>https://vo.rs/tags/postgres/</link><description>Latest from the Postgres 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/postgres/" 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><item><title>Database Backups Done Right: Dumps, WAL, and PITR</title><link>https://vo.rs/story/database-backups-done-right-dumps-wal-and-pitr/</link><description>&lt;p&gt;The backup that fails is almost never the one that did not run. It is the one that ran perfectly for eight months, filled a directory with reassuring nightly files, and turned out to be a copy of a database taken mid-write that no engine will reopen. You discover this at the worst possible moment, holding a corrupt production file and a folder of corrupt backups, having learned the oldest lesson in operations the hard way: an untested backup is a rumour. This article is about making the rumour true, and doing it with the three tools that actually matter — logical dumps, write-ahead log archiving, and point-in-time recovery — so you can pick the right level of protection for each database instead of applying the same tired nightly &lt;code&gt;cp&lt;/code&gt; to all of them.&lt;/p&gt;</description><pubDate>Mon, 31 Mar 2025 15:01:00 +0000</pubDate></item><item><title>Postgres Tuning for Homelabbers: Ten Settings That Matter</title><link>https://vo.rs/story/postgres-tuning-for-homelabbers-ten-settings-that-matter/</link><description>&lt;p&gt;The first time I put a self-hosted photo library on Postgres and watched a search take four seconds, I assumed I had written a bad query. I had not. The query was fine. The database was running with the settings it shipped with, and those settings assume it is sharing a cramped virtual machine with a dozen other tenants who would all riot if Postgres grabbed a gigabyte of RAM for itself. On my own hardware, with 32 GB of memory and an NVMe drive doing nothing else, that caution is wasted. Postgres was politely refusing to use the machine I had given it.&lt;/p&gt;</description><pubDate>Sun, 02 Mar 2025 13:47:00 +0000</pubDate></item></channel></rss>