Cold Comfort: When PostgreSQL Protects Your Data by Locking You Out

Cold Comfort: When PostgreSQL Protects Your Data by Locking You Out

PostgreSQL’s MVCC architecture is designed to preserve data integrity at all costs.

But when autovacuum falls behind, that protection can come at a steep operational price: your data is still there — but you can’t write to it, and in some cases, you can’t even access it.

Over the past three years, PostgreSQL has experienced multiple production-halting outages across major cloud providers and enterprise deployments.

The root cause in every case? Vacuum lag.

Three Confirmed Outages (2024–2025)

  1. AWS RDS PostgreSQL Wraparound Incident
    Date: December 2024 (updated February 2025)
    Impact: PostgreSQL entered read-only mode
    Cause: Transaction ID wraparound protection triggered due to autovacuum lag
    Recovery: Required emergency vacuuming and downtime
    Source: AWS Blog
  2. Google Cloud SQL PostgreSQL Lockouts
    Date: Throughout 2024
    Impact: PostgreSQL refused new transactions to prevent wraparound data loss
    Cause: Missed autovacuum cycles; stale replication slots and prepared transactions
    Recovery: Required single-user mode vacuum and cleanup
    Source: Google Cloud Docs
  3. Metronome Multixact Exhaustion
    Date: May 2025
    Impact: Four outages in one week; blocked write operations across API and UI
    Cause: Multixact member exhaustion from long-lived transactions and insufficient vacuuming
    Recovery: Required emergency tuning and freeze vacuuming
    Source: Metronome Postmortem

Meanwhile: No Documented MariaDB Outages

In the same timeframe, MariaDB has had no confirmed production-halting incidents.

Its architecture avoids transaction ID wraparound and multixact exhaustion entirely. It does not rely on background vacuuming to maintain write availability.

Stewardship Risk Summary (2023–2025)

System Outages Business Impact Stewardship Risk
PostgreSQL 3 confirmed High Requires freeze monitoring, vacuum tuning, emergency playbooks
MariaDB None Low Stable, no vacuum dependencies

MariaDB has had no documented outages in the past three years.

It doesn’t rely on autovacuum, doesn’t suffer from transaction ID wraparound, and doesn’t require freeze monitoring to stay writable.

MariaDB's architecture avoids the entire class of risks that have repeatedly halted PostgreSQL workloads.

PostgreSQL’s vacuum system is not optional — it’s existential.

In high-write environments, autovacuum can consume 20–40% of CPU and I/O.

When vacuuming falls behind, PostgreSQL will halt writes or enter read-only mode to prevent corruption.

If you’re running PostgreSQL at scale, you need:

  • Freeze-age monitoring
  • Autovacuum tuning
  • Emergency vacuum playbooks
  • Contributor-safe diagnostics and alerting
“Catastrophic data loss. (Actually the data is still there, but that's cold comfort if you cannot get at it.)”
— PostgreSQL Documentation

Tags:
#PostgreSQL #Autovacuum #DatabaseOutages #MVCC #WraparoundRisk #MariaDB #Benchmarking #DatabaseStewardship #FreezeMonitoring #CloudReliability #MariaDBFoundation #OpenSource #PerformanceTesting #ContributorDriven #MySQLCompatible #CloudDatabases #LegacyDriven

Comments

Post a Comment

Popular posts from this blog

MySQL Cluster Replication

MySQL QA In the 5.1 release MySQL Cluster will support replication to another MySQL installation. The replication is handled using Row Bases Replication instead of Statement Based Replication. I have been testing it for about a year now and it has gotten really hard for me to break at this point, but I am still trying. So what is so cool about Cluster Replication? Good question! One answer: Cluster Replication really gives a company five 9's (99.999%) in up time. You can have a Master Cluster in the main site supporting the business and have another Slave Cluster in a total different site that can be used as a backup for times there are issues with main site. In addition, the Slave Cluster can also be used for reporting or data mining to take that traffic off of the main Cluster. How hard is it to setup? Another great question. Answer: Easy So to set it up, you would create two set of Clusters configured the way that you wanted them. You configure the Master MySQLD to create a bin ...
Read more

New MySQL System QA blog

Hi, It has been a while since I last posted, but I wanted to post about my teams NEW blog page. New System QA Blog As always, we look for ways to improve QA and your feedback is always welcomed. Best Wishes, /Jeb
Read more

Perl IO::Socket, how to make them talk on both ends Cient/Server

Hi, Was exploring IO::Socket for some test automation I'm looking at doing. I found a lot of examples on talking to the server side, but not really any good ones on how to recieve and process on the client side what the sever sent in response. After playing with it for a while today, I finially got the basics working and wanted to share incase others are wanting to deal with 2 way comunication. The main thing to remember is the $_ and what it is used for. Examples: Cleint Side: ----------- use IO::Socket; $sock = new IO::Socket::INET( PeerAddr => "127.0.0.1", PeerPort => 1234, Proto => 'tcp') || die "Error creating socket: $!"; print $sock "test\n"; #test coms and start a chat while ( ){ print "$_"; # The servers reponse will be in $_ if ($_ ne "MySQLD is now down\n"){ print $sock "shutdown\n"; } else{ print $sock "exit\n"; } } close($so...
Read more