--- title: Best Planet PostgreSQL posts — August 2026 | daily.dev description: The most upvoted Planet PostgreSQL posts from August 2026, curated by the daily.dev community. canonical: https://daily.dev/sources/planet-postgresql/best-of/2026/08 twitter:card: summary_large_image twitter:site: @dailydotdev og:url: https://daily.dev/sources/planet-postgresql/best-of/2026/08 og:type: website og:site_name: daily.dev og:title: Best Planet PostgreSQL posts — August 2026 | daily.dev og:description: The most upvoted Planet PostgreSQL posts from August 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 — August 2026 1. 1 [](https://daily.dev/posts/sixteen-locks-ought-to-be-enough-for-anybody-uzol2fnoq "Sixteen Locks Ought to Be Enough for Anybody") Article Planet PostgreSQL · 3w Sixteen Locks Ought to Be Enough for Anybody Every PostgreSQL query takes an AccessShareLock on every index of a table it touches, not just the ones actually used, because the planner must open each index to evaluate it. Through PostgreSQL 17, each backend's fast-path lock array (which avoids costly shared-memory lock table entries) has a fixed 16 slots; tables with more than 16 relations (table plus indexes) overflow into the contended shared lock table, causing LWLock:LockManager waits and CPU pressure at high query rates. Prepared statements sidestep this because cached generic plans only lock relations actually used, but they interact poorly with connection poolers like PgBouncer (fixed in 1.21) and are largely incompatible with RDS Proxy. PostgreSQL 18 removes the fixed 16-slot limit, sizing the fast-path array from max\_locks\_per\_transaction (default 64) instead. The underlying advice is still to avoid over-indexing tables. 22 1 2. 2 [](https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2 "PostgreSQL 18: 23x Faster Inserts With UUID V7") Article Planet PostgreSQL · 2w PostgreSQL 18: 23x Faster Inserts With UUID V7 A production migration from UUID v1/v4 to UUID v7 primary keys on PostgreSQL 18.4 delivered up to 23x faster multi-row insert performance on a heavily-queried, billion-row table. The speedup comes from v7's monotonically increasing timestamp-based values keeping recently inserted b-tree index pages hot in the buffer cache, reducing page splits, WAL, and IO. The write-up details the real-world challenge of changing a column default via \`ALTER TABLE\`, which requires an access-exclusive lock blocking all reads and writes, and walks through progressively more sophisticated mitigation: short lock/statement timeouts with manual retries, a PL/pgSQL loop with jittered backoff for the busiest table, and a fallback plan to actively cancel lock-holding queries. It closes by noting UUID v7's downside: the embedded timestamp leaks record creation time, unlike v4. 19 1 3. 3 [](https://daily.dev/posts/the-sixth-execution-a6umibut5 "The Sixth Execution") Article Planet PostgreSQL · 2w The Sixth Execution Prepared statements in PostgreSQL follow a specific rule: for the first five executions, a custom plan is built using the actual parameter values, giving the same plan quality as textual substitution. On the sixth execution, PostgreSQL builds a generic plan (no parameter values) and compares its estimated cost to the average custom plan cost; if generic wins, PostgreSQL switches to it and sticks with it until invalidation. Generic plans use blind selectivity estimates (e.g., non-null fraction divided by n\_distinct for equality, one-third of the table for inequality), which can be badly wrong on skewed data, causing queries to mysteriously slow down after the sixth execution. The decision is based purely on estimated cost, never actual runtime, and is asymmetrically sticky. Common culprits include PL/pgSQL functions, and drivers like psycopg 3 and JDBC that auto-promote to named statements after a threshold (default 5), causing the switch around the tenth or eleventh execution instead. Fixes include plan\_cache\_mode=force\_custom\_plan for skewed queries, driver-level prepare=False, query restructuring, or partial indexes on skewed columns. 10 5 4. 4 [](https://daily.dev/posts/introducing-sqlfmt-an-sql-gofmt-style-formatter-fmhcxx1lj "Introducing sqlfmt: an SQL gofmt-style formatter") Article Planet PostgreSQL · 4w Introducing sqlfmt: an SQL gofmt-style formatter sqlfmt is a new opinionated SQL formatter inspired by gofmt, implementing the 'river alignment' style from The Art of PostgreSQL. It right-pads all clause keywords (select, from, where, group by, etc.) to the same column at each nesting level, creating a vertical river with expressions flowing to the right. The tool uses a tokenizer rather than an AST for robustness and comment preservation. It ships with a CLI mirroring gofmt's interface (-w, -l, -d flags), editor plugins for Emacs and Vim/Neovim, and a WebAssembly-powered web formatter (\~130 KB compressed). Install via \`go install github.com/dimitri/sqlfmt/cmd/sqlfmt@latest\`. The style enforces lowercase keywords, trailing commas, and and/or at line starts. A correctness oracle using pganalyze/pg\_query\_go verifies formatting never changes query semantics. 10 [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/08#page","url":"https://daily.dev/sources/planet-postgresql/best-of/2026/08","name":"Best Planet PostgreSQL Posts — August 2026","description":"The most upvoted Planet PostgreSQL posts from August 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/08#items","numberOfItems":4,"itemListElement":[{"@type":"ListItem","position":1,"url":"https://daily.dev/posts/sixteen-locks-ought-to-be-enough-for-anybody-uzol2fnoq","name":"Sixteen Locks Ought to Be Enough for Anybody"},{"@type":"ListItem","position":2,"url":"https://daily.dev/posts/postgresql-18-23x-faster-inserts-with-uuid-v7-nc2q5uwx2","name":"PostgreSQL 18: 23x Faster Inserts With UUID V7"},{"@type":"ListItem","position":3,"url":"https://daily.dev/posts/the-sixth-execution-a6umibut5","name":"The Sixth Execution"},{"@type":"ListItem","position":4,"url":"https://daily.dev/posts/introducing-sqlfmt-an-sql-gofmt-style-formatter-fmhcxx1lj","name":"Introducing sqlfmt: an SQL gofmt-style formatter"}]},{"@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":"August 2026"}]}]} ```