JUNE 2026

Join our Plan Management webinar on June 25, Postgres in Production Part 4 on what is kept in pg_stat_statements; Enterprise Server v2026.05.0

Hi there,

For many of us on the northern half of the world, summer is (almost) here!

Later this month, on June 25, we're running a webinar on detecting and fixing bad Postgres query plans in production - including specifics on the new pg_plan_advice module coming in Postgres 19. Plan flips are one of the most puzzling reasons a query goes from fast to slow without any code change. Updated statistics, table size changes, or index bloat can cause the planner can swap to a different plan unexpectedly. You usually find out when production slows down. The talk covers what exists in Postgres today to see which plan ran when, and how to influence the planner toward the right one: pg_hint_plan, pg_plan_advice & pg_stash_advice and cloud-provider specific solutions.

Ryan Booz is back with Part 4 of his pg_stat_statements deep dive. Did you know there's a hidden per-query usage counter? It's not in the pg_stat_statements view, but it decides which entries get evicted, and every deallocation sorts the entire table by that counter. If you're missing an entry that you thought should be there, that might explain it. Ryan also flags a misconception many have: pg_stat_statements does not track cancelled queries - only completed executions are stored. If you ask ChatGPT or Claude, they will confidently give you the wrong answer on that one.

We also shipped Enterprise Server v2026.05.0 in late May. One big change for self-hosted customers is that the pganalyze MCP Server is now available in Enterprise Server, so engineers can query their pganalyze workload data directly from Claude Code, Cursor, and other MCP-aware tools running against their own instance. The release also adds Server Groups and Cluster-Wide Query Performance (more on that below), 100-day retention for system statistics, and a refreshed Collector Settings page.

And on the community side, both Ryan and I (Lukas) are speaking at PG Data 2026 at Loyola University in Chicago this week. Ryan presents "Logging with Purpose" Friday morning, and I present a talk version of the June 25 webinar Friday afternoon. We'll also be back at Chicago for DjangoCon US in late August with a booth. If you're attending either, come say hi!

As always, you can find the complete list of pganalyze product updates at the end of this newsletter.

Postgres in Production

Deep Dive into pg_stat_statements (Part 4): How pg_stat_statements Decides What to Keep

In Part 4 of the Postgres in Production deep dive series, Ryan goes into the pg_stat_statements source code: what gets stored, what gets dropped, and how. There's a hidden per-query usage counter (not in the pg_stat_statements view) that determines which entries get evicted. Eviction sorts the whole table on every deallocation, so a higher pg_stat_statements.max is not free. Each eviction touches more rows under an exclusive lock. Only completed executions are recorded, which means a timed-out query that read hundreds of thousands of buffers is not visible in pg_stat_statements today.

Upcoming Webinar

Postgres Plan Monitoring & Management: Best Practices & Postgres 19

On June 25, we'll walk through what exists today in Postgres to monitor query plans and influence the planner toward a different plan when it's picked a bad one. The talk covers the open-source extensions (pg_stat_plans, pg_hint_plan), the cloud-provider implementations (aurora_stat_plans, Aurora Query Plan Management, AlloyDB's query hint mechanism), and the new pg_plan_advice contrib module landing in Postgres 19.

Product Launch

Server Groups and Cluster-Wide Query Performance

Postgres clusters with a primary and one or more replicas now can be viewed as a single resource in pganalyze. pganalyze detects the cluster relationship automatically from collector metadata, or you can set it explicitly via collector configuration. Server Groups get their own scope across Dashboard, Query Performance, Workbooks, and Settings, so you can investigate workload patterns at the cluster level instead of jumping between primary and replica pages.

Cluster-Wide Query Performance rolls up query statistics data across all members of the group, so its easy to spot slow queries regardless of which replica they ran on. The feature is now available, with additional server group functionality (including custom server groups to support sharding use cases) coming later this year.

Product Updates

What's New in pganalyze

pganalyze Workbooks

• Browse workbooks at every scope. The Workbooks page is now reachable from the side navigation at organization, server group, server, or database scope, with a New Workbook button that prompts for a server and database when needed.
• Workbook list: Correctly show draft workbooks when "Show draft workbooks" is checked

EXPLAIN

• Consolidated metric selection between grid view and plan comparison.

Server Groups

• Refined navigation and display
  When a server group is added to recents in the server dropdown, its server members are now also added for quick access. Sorting server groups in Dashboard also updates the URL bookmarks and sharing.
• Support for custom display names

  Cluster-based server groups can now be renamed from the new Server Group Settings page. Updates to display name will not change the underlying cluster id. Empty names fall back to the cluster id.

Other improvements and changes

• Graph tooltips: Avoid showing data points that are too far from the cursor.
• Query Tags: Improve parsing and skip invalid tags

  • Tags using = as the key-value delimiter while also using : in the tag value are now properly parsed. For example /* requestId=service:job:task */ is now parsed as a requestId tag with the value service:job:task. Previously it would be parsed as a requestId=service tag with the value job:task.

     

  • Additionally, tags now have stricter requirements. Tags whose key or value are empty are now skipped. Tag keys must only contain alphanumeric characters, periods, underscores, and dashes, matching the regular expression [a-zA-Z0-9._-].

pganalyze Collector v0.70.2

• Aurora: Improved disk size reporting using the VolumeBytesUsed CloudWatch metric at the cluster level, replacing the inaccurate OS-level filesystem values
• AlloyDB and Cloud SQL: Fix IAM authentication by removing prepared statements from collector queries, allowing proxy use without configuration changes regardless of provider
• Docker image: Raise alpine/musl stack size from 2MB to 8MB (matching what glibc would typically use), fixing a crash on a very complex query making heavy use of UNION
• Log processing: Support log_error_verbosity = verbose for Log Insights (previously the inlined SQLSTATE confused the log parser)

pganalyze Enterprise Server Release v2026.05.0

• MCP Server is now available in Enterprise Server (was previously cloud-only). Enabled by default; disable per organization in Settings → API Access. Announcement · Docs.

• Server Groups for Postgres clusters and Cluster-Wide Query Performance. pganalyze automatically detects server groups based on the Postgres cluster relationship, or when manually set in the collector. Server Groups appear as their own resource in the navigation, Dashboard and Query Performance pages. Blog post.

• 100-day retention for system statistics.
• Collector Settings page (now its own page) with collector error history and connection history.
• Database Dashboard check-up widget now covers all check types, with active-issue counts.
• Automated EXPLAIN: Improved plan parsing when the auto_explain log_format is set to text (handles JIT output changes in newer Postgres and fixes worker detail parsing when auto_explain.log_timing is off).
• Bundled collector updated to v0.70.2.

• The full list of updates is available in the release notes.

Earn a $25 Now a $50! Gift Card for a Review on G2

Help us get more community feedback and qualify for a free gift card while supplies last.