--- title: Best Planet PostgreSQL posts — June 2026 | daily.dev description: The most upvoted Planet PostgreSQL posts from June 2026, curated by the daily.dev community. canonical: https://daily.dev/sources/planet-postgresql/best-of/2026/06 twitter:card: summary_large_image twitter:site: @dailydotdev og:url: https://daily.dev/sources/planet-postgresql/best-of/2026/06 og:type: website og:site_name: daily.dev og:title: Best Planet PostgreSQL posts — June 2026 | daily.dev og:description: The most upvoted Planet PostgreSQL posts from June 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 — June 2026 1. 1 [](https://daily.dev/posts/a-thousand-postgres-branches-for-1-npf3lzd7k "A thousand Postgres branches for $1") Article Planet PostgreSQL · 13w A thousand Postgres branches for $1 Xata has reduced Postgres database branching times from 20+ seconds to 1-2 seconds through a combination of custom storage (Xatastor using ZFS over NVMe-oF) and warm pools of pre-provisioned Kubernetes pods. Branches use copy-on-write storage so you only pay for diffs to the parent. With scale-to-zero billing per minute, 1,000 short-lived branches cost roughly $1\. Real-world customers like AI coding agents and CI/CD preview environments are using thousands of branches per week for under $30/month. The architecture separates compute from storage, allowing volumes to be hot-connected to waiting pods in milliseconds. 97 3 2. 2 [](https://daily.dev/posts/optimising-polymorphic-associations-in-postgresql-help-the-planner-avoid-performance-cliffs-4b6rfxgvn "Optimising Polymorphic Associations in PostgreSQL: Help the planner avoid performance cliffs") Article Planet PostgreSQL · 12w Optimising Polymorphic Associations in PostgreSQL: Help the planner avoid performance cliffs Polymorphic associations — where a base table LEFT JOINs multiple subtype tables via a (type, id) discriminator pair — are auto-generated by ORMs like Rails, Django, and Hibernate, and cause serious PostgreSQL performance regressions at scale. The core issue is O(M×N) join probes where only O(M) are useful. Three patches under discussion on pgsql-hackers address distinct pain points: (1) Result Filter / one-sided gating skips inner-side scans when the discriminator condition is already false, eliminating fruitless buffer touches; (2) Sort Pushdown inserts a pre-sort above the base table scan so LIMIT can short-circuit the join tree without a full scan; (3) SubLink relocation pushes EXISTS-to-SEMI-JOIN transformations down to the smallest relevant subtree rather than floating them to the top of the join tree. A fourth direction — join selectivity statistics via CREATE STATISTICS — is also in prototype. None of the patches are committed yet, but each targets a specific, measurable regression source in the polymorphic query pattern. 35 3. 3 [](https://daily.dev/posts/looking-forward-to-postgres-19-logically-sequenced-achhfi4sd "Looking Forward to Postgres 19: Logically Sequenced") Article Planet PostgreSQL · 12w Looking Forward to Postgres 19: Logically Sequenced Postgres 19 finally addresses one of the longest-standing gaps in logical replication: sequences. For nearly a decade, sequences were excluded from logical replication because they are non-transactional and don't fit the WAL decode model. This forced DBAs to manually run setval() scripts before promoting a subscriber, with a safety buffer to avoid duplicate key errors. Postgres 19 introduces explicit sequence synchronization at three well-defined moments: CREATE SUBSCRIPTION, ALTER SUBSCRIPTION ... REFRESH PUBLICATION, and the new ALTER SUBSCRIPTION ... REFRESH SEQUENCES command. A new ALL SEQUENCES clause in CREATE PUBLICATION covers all sequences in a database. Supporting tooling includes the pg\_get\_sequence\_data() function and a new sync\_seq\_error\_count column in pg\_stat\_subscription\_stats. The approach mirrors what pglogical has done since its inception — periodic sync rather than real-time streaming — but is now native to Postgres. 35 2 4. 4 [](https://daily.dev/posts/sql-pgq-in-postgresql-19-graph-queries-without-the-graph-database-jjw0uthjc "SQL/PGQ in PostgreSQL 19: Graph Queries Without the Graph Database") Article Planet PostgreSQL · 15w SQL/PGQ in PostgreSQL 19: Graph Queries Without the Graph Database PostgreSQL 19 introduces GRAPH\_TABLE, an implementation of the ISO SQL/PGQ standard that lets you declare property graphs over existing relational tables and query them with Cypher-like pattern matching syntax. Rather than adding a graph storage engine, it works as a rewriter that translates graph patterns into ordinary relational joins, meaning existing indexes and the query planner work as-is. This makes Postgres competitive for shallow, fixed-depth graph queries (2-3 hops), which represent the majority of real-world graph workloads. However, variable-length path traversals are not yet supported in PG19, and the underlying relational execution model cannot match Neo4j's index-free adjacency for deep traversals over massive graphs. The practical takeaway: teams running Neo4j for graph-shaped data should evaluate whether their actual queries are shallow enough to migrate to Postgres, while genuinely deep traversal workloads still warrant a dedicated graph database. 14 2 5. 5 [](https://daily.dev/posts/all-your-gucs-in-a-row-constraint-exclusion-thbwdhnen "All Your GUCs in a Row: constraint_exclusion") Article Planet PostgreSQL · 15w All Your GUCs in a Row: constraint\_exclusion PostgreSQL's \`constraint\_exclusion\` GUC controls a planner optimization that skips table scans when a CHECK constraint contradicts the query's WHERE clause. Originally the backbone of manual inheritance-based partitioning before PostgreSQL 10, it became largely obsolete for modern declarative partitioning when PostgreSQL 11 introduced a dedicated partition pruning engine with O(log n) binary search and runtime pruning. Today, \`constraint\_exclusion\` only affects old-style inheritance trees and UNION ALL subqueries. The correct parameter for controlling partition pruning on modern declarative partitioned tables is \`enable\_partition\_pruning\`. The default value of \`partition\` remains the right setting — changing it to \`on\` wastes planning time, and \`off\` saves almost nothing. 13 6. 6 [](https://daily.dev/posts/that-guy-from-delhi-why-postgres-doesn-t-have-remote-receive-5eebvgiqc "That Guy From Delhi: Why Postgres Doesn't Have remote_receive") Article Planet PostgreSQL · 13w That Guy From Delhi: Why Postgres Doesn't Have remote\_receive A developer implemented a custom \`remote\_receive\` synchronous commit mode for PostgreSQL that acknowledges WAL receipt in the standby's memory buffer before the standby calls \`pwrite()\`. The hypothesis was that skipping the standby's disk write would yield measurable performance gains over \`remote\_write\`. On fast SSD hardware, the modes were virtually identical (0.06% difference) because \`pwrite()\` to the OS page cache is already a RAM-speed operation taking microseconds, dwarfed by network RTT. On a slow HDD replica, initial results were counterintuitive — \`remote\_write\` outperformed \`remote\_receive\` due to CPU scheduler thrashing from doubled TCP reply packets and natural flow-control effects. After overhauling the benchmarking methodology with interleaved runs, 60-second iterations, and aggressive OS cache flushing between runs, \`remote\_receive\` showed a \~4.9% median TPS gain on the HDD replica. The conclusion: the OS page cache masks physical disk latency until it fills, and \`remote\_write\` is practically as fast as a receive-only mode under normal conditions — explaining why PostgreSQL core developers never added this feature. 12 [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/06#page","url":"https://daily.dev/sources/planet-postgresql/best-of/2026/06","name":"Best Planet PostgreSQL Posts — June 2026","description":"The most upvoted Planet PostgreSQL posts from June 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/06#items","numberOfItems":6,"itemListElement":[{"@type":"ListItem","position":1,"url":"https://daily.dev/posts/a-thousand-postgres-branches-for-1-npf3lzd7k","name":"A thousand Postgres branches for $1"},{"@type":"ListItem","position":2,"url":"https://daily.dev/posts/optimising-polymorphic-associations-in-postgresql-help-the-planner-avoid-performance-cliffs-4b6rfxgvn","name":"Optimising Polymorphic Associations in PostgreSQL: Help the planner avoid performance cliffs"},{"@type":"ListItem","position":3,"url":"https://daily.dev/posts/looking-forward-to-postgres-19-logically-sequenced-achhfi4sd","name":"Looking Forward to Postgres 19: Logically Sequenced"},{"@type":"ListItem","position":4,"url":"https://daily.dev/posts/sql-pgq-in-postgresql-19-graph-queries-without-the-graph-database-jjw0uthjc","name":"SQL/PGQ in PostgreSQL 19: Graph Queries Without the Graph Database"},{"@type":"ListItem","position":5,"url":"https://daily.dev/posts/all-your-gucs-in-a-row-constraint-exclusion-thbwdhnen","name":"All Your GUCs in a Row: constraint_exclusion"},{"@type":"ListItem","position":6,"url":"https://daily.dev/posts/that-guy-from-delhi-why-postgres-doesn-t-have-remote-receive-5eebvgiqc","name":"That Guy From Delhi: Why Postgres Doesn't Have remote_receive"}]},{"@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":"June 2026"}]}]} ```