<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
    <channel>
        <title></title>
        <link>https://postgres.ai/blog</link>
        <description></description>
        <lastBuildDate>Thu, 17 Sep 2026 00:00:00 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <language>en</language>
        <copyright>PostgresAI</copyright>
        <item>
            <title><![CDATA[DBLab 4.2: clone upgrades, simplified install, retention, and more]]></title>
            <link>https://postgres.ai/blog/20260917-dblab-engine-4-2-released</link>
            <guid>https://postgres.ai/blog/20260917-dblab-engine-4-2-released</guid>
            <pubDate>Thu, 17 Sep 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[DBLab 4.0 made database branching instant. 4.1 added the controls around it — protection leases, Teleport, metrics. 4.2 closes the last item on 4.1's own roadmap — testing a Postgres major version upgrade on a clone — and removes the two remaining points of friction around it: getting configured in the first place, and cleaning up what accumulates afterwards.]]></description>
            <author>denis@postgres.ai (Denis Morozov)</author>
            <category>Product announcements</category>
            <category>DBLab Engine</category>
            <category>Database Lab Engine</category>
        </item>
        <item>
            <title><![CDATA[DBLab 4.1: protection leases, Teleport, Prometheus, and more]]></title>
            <link>https://postgres.ai/blog/20260408-dblab-engine-4-1-released</link>
            <guid>https://postgres.ai/blog/20260408-dblab-engine-4-1-released</guid>
            <pubDate>Wed, 08 Apr 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[DBLab 4.0 introduced instant database branching with O(1) economics. With 4.1, we're making it safe to hand off to a platform team: automatic resource governance, enterprise access control, production-safe data refresh, and native observability.]]></description>
            <author>denis@postgres.ai (Denis Morozov)</author>
            <category>Product announcements</category>
            <category>DBLab Engine</category>
            <category>Database Lab Engine</category>
        </item>
        <item>
            <title><![CDATA[PG18 preserves planner statistics on upgrade — even from PG14]]></title>
            <link>https://postgres.ai/blog/20260324-pg18-stats-upgrade-across-versions</link>
            <guid>https://postgres.ai/blog/20260324-pg18-stats-upgrade-across-versions</guid>
            <pubDate>Tue, 24 Mar 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[Postgres 18 can preserve planner statistics during major version upgrades. But can it work when upgrading from an older version to PG18 — which many plan to do soon? Let's test and see.]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>PostgreSQL</category>
            <category>pg_upgrade</category>
            <category>performance</category>
            <category>major upgrades</category>
        </item>
        <item>
            <title><![CDATA[How moving one word can speed up a query 10–50x]]></title>
            <link>https://postgres.ai/blog/20260311-not-exists-vs-exists-partial-index</link>
            <guid>https://postgres.ai/blog/20260311-not-exists-vs-exists-partial-index</guid>
            <pubDate>Wed, 11 Mar 2026 12:00:00 GMT</pubDate>
            <description><![CDATA[One of these queries is 32x faster than the other. Which one, and why?]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>performance</category>
            <category>indexing</category>
            <category>SQL</category>
            <category>partial index</category>
        </item>
        <item>
            <title><![CDATA[The hidden cost of invalid indexes in Postgres (yes, even on Supabase/RDS/Neon)]]></title>
            <link>https://postgres.ai/blog/20260106-invalid-index-overhead</link>
            <guid>https://postgres.ai/blog/20260106-invalid-index-overhead</guid>
            <pubDate>Tue, 06 Jan 2026 01:23:45 GMT</pubDate>
            <description><![CDATA[When CREATE INDEX CONCURRENTLY or REINDEX INDEX CONCURRENTLY fails, Postgres leaves behind an invalid index. Many engineers assume these indexes are harmless placeholders waiting to be cleaned up. After all, the planner won't use them for queries, right?]]></description>
            <author>dmitry@postgres.ai (Dmitry Fomin)</author>
            <category>Postgres</category>
            <category>indexes</category>
            <category>performance</category>
            <category>internals</category>
            <category>maintenance</category>
            <category>HealthyPostgres</category>
            <category>Index maintenance</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-013: Why keep your index set lean]]></title>
            <link>https://postgres.ai/blog/20251110-postgres-marathon-2-013-why-keep-your-index-set-lean</link>
            <guid>https://postgres.ai/blog/20251110-postgres-marathon-2-013-why-keep-your-index-set-lean</guid>
            <pubDate>Mon, 10 Nov 2025 23:59:59 GMT</pubDate>
            <description><![CDATA[Your API is slowing down. You check your database and find 42 indexes on your users table. Which ones can you safely drop? How much performance are they costing you? Let's look at what actually happens in Postgres when you have too many indexes.]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>indexes</category>
            <category>performance</category>
            <category>maintenance</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-012: Ultra-fast replica creation with pgBackRest]]></title>
            <link>https://postgres.ai/blog/20251105-postgres-marathon-2-012-ultra-fast-replica-creation-pgbackrest</link>
            <guid>https://postgres.ai/blog/20251105-postgres-marathon-2-012-ultra-fast-replica-creation-pgbackrest</guid>
            <pubDate>Wed, 05 Nov 2025 23:59:59 GMT</pubDate>
            <description><![CDATA[Suppose you need to create a replica for a 1 TiB database. You have a fast server with NVMe storage and 75 Gbps network, but pg_basebackup typically delivers only 300-500 MiB/s due to its single-threaded architecture — regardless of how powerful your hardware is (though PG18 brings a surprise we'll discuss later).]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>cloning</category>
            <category>pgBackRest</category>
            <category>performance</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-011: Prepared statements and partitioned tables — the paradox, part 3]]></title>
            <link>https://postgres.ai/blog/20251030-postgres-marathon-2-011</link>
            <guid>https://postgres.ai/blog/20251030-postgres-marathon-2-011</guid>
            <pubDate>Thu, 30 Oct 2025 23:59:59 GMT</pubDate>
            <description><![CDATA[In #PostgresMarathon 2-009 and #PostgresMarathon 2-010, we explored why execution 6 causes a lock explosion when building a generic plan for partitioned tables — the planner must lock all 52 relations because it can't prune without parameter values.]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
            <category>prepared statements</category>
            <category>partitioning</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-010: Prepared statements and partitioned table lock explosion, part 2]]></title>
            <link>https://postgres.ai/blog/20251029-postgres-marathon-2-010</link>
            <guid>https://postgres.ai/blog/20251029-postgres-marathon-2-010</guid>
            <pubDate>Wed, 29 Oct 2025 23:59:59 GMT</pubDate>
            <description><![CDATA[In #PostgresMarathon 2-009, we focused on Lock Manager's behavior when dealing with prepared statements and partitioned tables.]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
            <category>prepared statements</category>
            <category>partitioning</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-009: Prepared statements and partitioned table lock explosion, part 1]]></title>
            <link>https://postgres.ai/blog/20251028-postgres-marathon-2-009</link>
            <guid>https://postgres.ai/blog/20251028-postgres-marathon-2-009</guid>
            <pubDate>Tue, 28 Oct 2025 12:00:00 GMT</pubDate>
            <description><![CDATA[In #PostgresMarathon 2-008, we discovered that prepared statements can dramatically reduce LWLock:LockManager contention by switching from planner locks (which lock everything) to executor locks (which lock only what's actually used). Starting with execution 7, we saw locks drop from 6 (table + 5 indexes) to just 1 (table only).]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
            <category>prepared statements</category>
            <category>partitioning</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-008: LWLock:LockManager and prepared statements]]></title>
            <link>https://postgres.ai/blog/20251014-postgres-marathon-2-008</link>
            <guid>https://postgres.ai/blog/20251014-postgres-marathon-2-008</guid>
            <pubDate>Tue, 14 Oct 2025 23:59:59 GMT</pubDate>
            <description><![CDATA[As was discussed in #PostgresMarathon 2-002, for a simple SELECT from a table, at planning time, Postgres locks the table and all of its indexes with AccessShareLock. A simple demo to remind it (let me be a bit weird here and save some bytes when typing SQL):]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
            <category>prepared statements</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-007: Should we worry about pg_blocking_pids()'s observer effect?]]></title>
            <link>https://postgres.ai/blog/20251013-postgres-marathon-2-007</link>
            <guid>https://postgres.ai/blog/20251013-postgres-marathon-2-007</guid>
            <pubDate>Mon, 13 Oct 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[Many years ago, when developing complex automated procedures for a large company, I realized that my automation needs monitoring components. Including understanding heavyweight lock contention – for example, to recognize situations when a poorly designed change is blocked by things like autovacuum running in transaction ID wraparound prevention mode (it doesn't yield to anybody, when in this mode).]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
            <category>monitoring</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-006: Mysterious max_locks_per_transaction]]></title>
            <link>https://postgres.ai/blog/20251010-postgres-marathon-2-006</link>
            <guid>https://postgres.ai/blog/20251010-postgres-marathon-2-006</guid>
            <pubDate>Fri, 10 Oct 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[The setting maxlockspertransaction is mysterious, it is a good illustration of Socrates' "I know that I know nothing". This is the main fact to memorize about maxlockspertransaction. Don't try to remember details. Unless you touch it often, you'll forget (I do). Instead, let's rely on the docs:]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-005: More LWLock:LockManager benchmarks for Postgres 18]]></title>
            <link>https://postgres.ai/blog/20251009-postgres-marathon-2-005</link>
            <guid>https://postgres.ai/blog/20251009-postgres-marathon-2-005</guid>
            <pubDate>Thu, 09 Oct 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[In 2023-2024, after incidents that multiple customers of PostgresAI experienced, when production nodes were down because of LWLock:LockManager contention, we studied it in synthetic environments.]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-004: Fast-path locking explained]]></title>
            <link>https://postgres.ai/blog/20251008-postgres-marathon-2-004</link>
            <guid>https://postgres.ai/blog/20251008-postgres-marathon-2-004</guid>
            <pubDate>Wed, 08 Oct 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[After 2-003, @ninjouz asked on X:]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-003: The roots of LWLock:LockManager]]></title>
            <link>https://postgres.ai/blog/20251007-postgres-marathon-2-003</link>
            <guid>https://postgres.ai/blog/20251007-postgres-marathon-2-003</guid>
            <pubDate>Tue, 07 Oct 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[As we discussed, Lock Manager manages heavyweight locks – various kinds of them (various modes, various levels of granularity). These locks are released only at the end of the transaction.]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-002: Relation-level locks]]></title>
            <link>https://postgres.ai/blog/20251005-postgres-marathon-2-002</link>
            <guid>https://postgres.ai/blog/20251005-postgres-marathon-2-002</guid>
            <pubDate>Mon, 06 Oct 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[Let's talk about relation-level locks and various confusions, surprises and what is worth to remember in practice.]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
        </item>
        <item>
            <title><![CDATA[#PostgresMarathon 2-001: Lightweight and heavyweight locks]]></title>
            <link>https://postgres.ai/blog/20251005-postgres-marathon-2-001</link>
            <guid>https://postgres.ai/blog/20251005-postgres-marathon-2-001</guid>
            <pubDate>Sun, 05 Oct 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[To warm up, let's talk about lightweight and heavyweight locks (or "regular locks" or just "locks").]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Postgres insights</category>
            <category>PostgresMarathon</category>
            <category>internals</category>
            <category>locks</category>
            <category>lockmanager</category>
        </item>
        <item>
            <title><![CDATA[Self-driving Postgres]]></title>
            <link>https://postgres.ai/blog/20250725-self-driving-postgres</link>
            <guid>https://postgres.ai/blog/20250725-self-driving-postgres</guid>
            <pubDate>Fri, 25 Jul 2025 20:00:00 GMT</pubDate>
            <description><![CDATA[Building the first truly self-driving PostgreSQL: zero downtime upgrades, AI-powered automation, and a roadmap to full database autonomy.]]></description>
            <author>nik@postgres.ai (Nikolay Samokhvalov)</author>
            <category>Product announcements</category>
            <category>Launch Week</category>
            <category>automation</category>
            <category>postgres</category>
            <category>database-management</category>
            <category>ai</category>
            <category>self-driving</category>
        </item>
        <item>
            <title><![CDATA[Full-stack preview environments with DBLab 4.0: isolated databases for every pull request]]></title>
            <link>https://postgres.ai/blog/20250724-full-stack-preview-environments-with-dblab</link>
            <guid>https://postgres.ai/blog/20250724-full-stack-preview-environments-with-dblab</guid>
            <pubDate>Thu, 24 Jul 2025 20:00:00 GMT</pubDate>
            <description><![CDATA[Learn how DBLab 4.0 database branching enables instant, cost-effective preview environments with isolated Postgres clones for every pull request. Includes practical implementation examples with CI/CD integration.]]></description>
            <author>bogdan@postgres.ai (Bogdan Tsechoev)</author>
            <category>Launch week</category>
            <category>DBLab Engine</category>
            <category>Preview environments</category>
            <category>CI/CD</category>
            <category>Full-stack preview environments</category>
            <category>Database branching</category>
            <category>O(1) economics</category>
        </item>
    </channel>
</rss>