<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Database on Gaurav.dev</title><link>/tags/database/</link><description>Recent content in Database on Gaurav.dev</description><generator>Hugo</generator><language>en-US</language><copyright>© 2026 Gaurav. Built with care and clean code.</copyright><lastBuildDate>Sun, 30 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="/tags/database/index.xml" rel="self" type="application/rss+xml"/><item><title>PostgreSQL Performance: Fix the Model Before Adding Hardware</title><link>/posts/postgresql-performance-basics/</link><pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate><guid>/posts/postgresql-performance-basics/</guid><description>&lt;p&gt;When a PostgreSQL-backed application slows down, larger infrastructure can hide the symptom while preserving the cause. A better response starts with evidence.&lt;/p&gt;&#10;&lt;h2 id="find-the-expensive-work"&gt;Find the expensive work&lt;/h2&gt;&#10;&lt;p&gt;Enable and review query statistics, then rank statements by total time—not only average duration. A moderately slow query executed thousands of times may cost more than one dramatic report. Correlate database behaviour with application endpoints, background jobs, and recent releases.&lt;/p&gt;&#10;&lt;p&gt;Use &lt;code&gt;EXPLAIN (ANALYZE, BUFFERS)&lt;/code&gt; on a safe environment with representative data. Look for large row-estimate errors, sequential scans over selective predicates, repeated nested operations, sorting that spills to disk, and far more rows removed than returned.&lt;/p&gt;</description></item></channel></rss>