--- title: Best Planet PostgreSQL posts — July 2026 | daily.dev description: The most upvoted Planet PostgreSQL posts from July 2026, curated by the daily.dev community. canonical: https://daily.dev/sources/planet-postgresql/best-of/2026/07 twitter:card: summary_large_image twitter:site: @dailydotdev og:url: https://daily.dev/sources/planet-postgresql/best-of/2026/07 og:type: website og:site_name: daily.dev og:title: Best Planet PostgreSQL posts — July 2026 | daily.dev og:description: The most upvoted Planet PostgreSQL posts from July 2026, curated by the daily.dev community. og:image: https://media.daily.dev/image/upload/s--VAY5ToZt--/f_auto/v1724209435/public/daily.dev%20-%20open%20graph --- # Best of Planet PostgreSQL — July 2026 1. 1 [](https://daily.dev/posts/inside-a-postgresql-checkpointer-bug-a-production-postmortem-48qml9fr8 "Inside a PostgreSQL Checkpointer Bug: A Production Postmortem") Article Planet PostgreSQL · 10w Inside a PostgreSQL Checkpointer Bug: A Production Postmortem A PostgreSQL 16.8 production database triggered an infinite retry loop in the checkpointer process due to an unbounded fsync request queue that exceeded PostgreSQL's internal 1 GB per-allocation limit. The error message 'invalid memory alloc request size' initially suggested memory exhaustion, but was actually an internal allocation ceiling being hit under heavy write workloads with large shared\_buffers. The checkpointer looped for over four hours, manual CHECKPOINT commands failed for the same reason, and a forced pod restart was the only recovery option — leading to several hours of WAL replay. The bug was fixed in PostgreSQL 16.10 by capping the fsync request queue at 10 million entries. The upgrade on Kubernetes required only swapping the container image while reusing the existing PVC. Key lessons: 'invalid memory alloc' doesn't always mean RAM exhaustion, PostgreSQL minor releases contain critical stability fixes, and checkpoint duration should be monitored like replication lag. 17 2. 2 [](https://daily.dev/posts/good-enough-beats-brilliant-poll4tz4y "Good enough beats brilliant") Article Planet PostgreSQL · 7w Good enough beats brilliant A Postgres contributor shares hard-won lessons from trying to get pioneering features into Postgres core. The central insight: Postgres succeeds not because it's the most technically brilliant database, but because it's 'good enough' — reliable, open, and maintainable. This high bar means new features must prove safety before anything else, making forks the right proving ground. The author walks through three attempts to implement parallel queries on temporary tables across two forks (Postgres Professional and Tantor Labs), detailing how each design flaw was only exposed under real production load. The honest conclusion is that the cleanest fix requires rethinking temporary table storage entirely (moving to shared buffers). The post ends with an open question: how do you turn a quiet mailing-list proposal into real community momentum when you're fully remote and unknown to the core contributors? 20 3 3. 3 [](https://daily.dev/posts/postgresql-s-mvcc-is-bad-so-is-everyone-else-s--0puk6jb2f "PostgreSQL's MVCC is bad. So is everyone else's.") Article Planet PostgreSQL · 7w PostgreSQL's MVCC is bad. So is everyone else's. PostgreSQL's MVCC design is legitimately flawed — write amplification, table bloat, vacuum babysitting, and 32-bit XID wraparound are real, demonstrable problems. But the critique always stops one question short: compared to what? Every database that supports non-blocking reads must answer four design questions about where old versions live, how version chains point, what indexes reference, and who cleans up. Oracle and InnoDB move versions to undo logs, eliminating bloat but making rollback expensive and readers of old data reconstruct versions on the fly. SQL Server bolted on optional versioning via tempdb, creating instance-wide blast radius from idle snapshots. MongoDB's WiredTiger keeps versions in RAM until cache pressure forces a history store spill. LSM-based engines like CockroachDB encode versions as timestamped keys and defer cleanup to compaction. Even etcd reproduces PostgreSQL's exact failure modes. The costs of multi-versioning are conserved across all designs — each engine only chooses who pays, when, and how it fails. PostgreSQL's choice makes garbage visible and maintenance manual, but it never cancels a reader with 'snapshot too old' and never makes you wait for rollback. The mature critique is not that Postgres got it wrong, but that it chose operationally loud failure modes. 13 4. 4 [](https://daily.dev/posts/building-the-oape-postgresql-certification-ecnfst4hw "Building the OAPE PostgreSQL Certification") Article Planet PostgreSQL · 8w Building the OAPE PostgreSQL Certification The Open Alliance for PostgreSQL Education (OAPE) is a community-founded, vendor-neutral non-profit working to create an independent PostgreSQL certification. Starting from a 2024 coffee conversation, a small group of contributors built the legal foundation, certification framework, and community infrastructure over two years. The first OAPE PostgreSQL DBA-1 exam will be held at PGConf.EU 2026 in Valencia, with additional certification levels already in development. The initiative is entirely community-owned and volunteer-driven, reflecting PostgreSQL's own values of openness, transparency, and vendor neutrality. 11 [See all Planet PostgreSQL archives](/sources/planet-postgresql/best-of) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@graph":[{"@type":"CollectionPage","@id":"https://daily.dev/sources/planet-postgresql/best-of/2026/07#page","url":"https://daily.dev/sources/planet-postgresql/best-of/2026/07","name":"Best Planet PostgreSQL Posts — July 2026","description":"The most upvoted Planet PostgreSQL posts from July 2026, curated by the daily.dev community.","isPartOf":{"@type":"WebSite","url":"https://daily.dev"}},{"@type":"ItemList","@id":"https://daily.dev/sources/planet-postgresql/best-of/2026/07#items","numberOfItems":4,"itemListElement":[{"@type":"ListItem","position":1,"url":"https://daily.dev/posts/inside-a-postgresql-checkpointer-bug-a-production-postmortem-48qml9fr8","name":"Inside a PostgreSQL Checkpointer Bug: A Production Postmortem"},{"@type":"ListItem","position":2,"url":"https://daily.dev/posts/good-enough-beats-brilliant-poll4tz4y","name":"Good enough beats brilliant"},{"@type":"ListItem","position":3,"url":"https://daily.dev/posts/postgresql-s-mvcc-is-bad-so-is-everyone-else-s--0puk6jb2f","name":"PostgreSQL's MVCC is bad. So is everyone else's."},{"@type":"ListItem","position":4,"url":"https://daily.dev/posts/building-the-oape-postgresql-certification-ecnfst4hw","name":"Building the OAPE PostgreSQL Certification"}]},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Sources","item":"https://daily.dev/sources"},{"@type":"ListItem","position":3,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":4,"name":"Best of","item":"https://daily.dev/sources/planet-postgresql/best-of"},{"@type":"ListItem","position":5,"name":"July 2026"}]}]} ```