MAY 2026

pganalyze MCP Server in Public Preview, new Query Advisor work_mem insight & Deep Dive into pg_stat_statements (Part 2)

Hi there,

After almost 100 companies took part in early access, the pganalyze MCP Server moved to public preview last week. Engineers want AI agents to help triage slow queries in production, but pointing one at a live database invites real risk: leaked PII, or an expensive ad-hoc query at the worst possible moment. The pganalyze MCP Server takes a different approach. Your AI tool never directly runs database queries. It queries pganalyze for the time-series statistics and tuning recommendations you already reach for during incident response. The announcement walks through how Notion used pganalyze with Claude Code to solve a weeks-long autovacuum mystery.

Alongside the launch, Ryan Booz is back with Part 2 of his deep dive into pg_stat_statements. This episode tackles a misconception that catches almost everyone: uniqueness in pg_stat_statements is structural, not textual. Postgres parses the query, walks the parse tree, and gathers significant nodes, ignoring literal values, and hashes the result. ORM-generated queries, dynamic SQL, and multi-database setups multiply entries fast, pushing you past the 5,000-entry default ceiling and evicting the queries that matter most.

We're also excited to introduce you to a new Query Advisor insight that detects queries spilling to disk due to low work_mem, recommending a safely-scoped fix to the specific query plan that caused temporary files to be written, so you can make informed decisions based on query plan data. And in case you didn't know, you can change work_mem for individual queries, without touching your server-wide default.

On the community side, we're heading to PGConf.dev (Vancouver, May 19–22) - as every year we're excited to talk about the next Postgres release and participate in the unconference. We'll also be at PG Data 2026 (Chicago, June 4–5), where Ryan and I (Lukas) are both speaking. My talk covers Postgres plan monitoring and management. If you're attending either, come say hi!

As always, the complete list of pganalyze product updates is at the end of this newsletter.

Postgres in Production

Deep Dive into pg_stat_statements (Part 2): What Makes a Statement Unique

In Part 2 of the special "Postgres in Production" deep dive series, Ryan Booz walks through what actually makes an entry in pg_stat_statements "unique". Each entry is keyed on role, database, queryid, and whether the query was top-level — but uniqueness is based on the query's structure, not its text. Postgres parses the query, walks the parse tree, strips out literal values, and hashes what's left (a process called "jumbling"). Ryan covers why this matters, how ORMs and dynamic SQL can multiply entries fast, and why the default 5,000-entry ceiling can quietly cost you visibility into your most important queries.

Product Launch

pganalyze MCP Server is now in Public Preview

After almost 100 companies took part in early access, the pganalyze MCP Server moves to public preview today. It works with Claude Code, Codex, Cursor, and other MCP-compatible clients, exposing curated access to the production database statistics pganalyze already collects. There is no direct connection to your database involved, so query parameters and result rows cannot leak into the model's context. The announcement covers what an LLM actually needs to debug Postgres safely, why generic database MCPs fall short, and a dive into how Notion uses Claude Code with pganalyze.

Community News

Upcoming events

We're heading to two Postgres community events in the next month:

First, PGConf.dev in Vancouver from May 19–22. The pganalyze team is looking forward to participating in the unconference and discussing changes coming in the next Postgres release cycle, such as how a future version of pg_stat_statements could look. Lukas's recent Postgres 19 work on lower-overhead EXPLAIN ANALYZE timing (with Andres Freund and David Geier) is bound to come up too.

Then PG Data 2026 at Loyola University in Chicago on June 4–5, where both Ryan and Lukas are speaking. Ryan presents "Logging with Purpose: A Framework for Finding and Fixing Slow Queries in Postgres" (Friday, 9:25 am), and Lukas presents "Postgres plan monitoring and management in practice" (Friday, 1:55 pm), covering pg_stat_plans, pg_hint_plan, cloud-specific implementations like Aurora Query Plan Management and AlloyDB query hints, plus the upcoming pg_plan_advice module in Postgres 19.

If you're attending either event, we'd be happy to meet up!

Product Updates

What's New in pganalyze

MCP Server & AI Tools

• Introduce pganalyze MCP Server (Public Preview)
  • The new MCP Server is now available for everyone on current Production, Scale and Enterprise plans, allowing you to easily query pganalyze data from AI tools of choice, such as Claude Code.
  • It is enabled by default on new accounts, and can be enabled for existing accounts by going to "Settings", "API Access".
  • Learn more details in the announcement and documentation.

Query Advisor

• New insight: Disk Spill Due To Low work_mem
  • Detects Sort and Hash nodes that fall back to using temporary files because work_mem was too small.
  • Surfaces the actual size of the spilled data, the current work_mem setting, and a recommended target value bounded by a safe ceiling (computed from total memory, shared_buffers, and typical active connection count).
  • The legacy "Sort Spills to Disk" and "Too Many Hash Batches" annotations on EXPLAIN plans are now hidden for Query Advisor users to avoid duplication.
• Support rewriting for more complex expressions and queries
• Improve page load time for Query Advisor insight page

EXPLAIN

• Fix occasional errors in plan comparison when "Select plans" is clicked
  • Previously, clicking "Select plans" on a plan comparison page could lead to an error when the already-selected plans had aged out of the selected date range. This change fixes that error and omits pre-selecting the existing plans in the list in that case (selection can be canceled to return to the previously-selected plans).

Collector Settings

• Add collector settings page, with error and connection history
  • The collector settings previously lived on the server settings page. Now on their own page, we also show a history of collector or data processing errors, as well as a connection history to make it easier to see if there are issues with your collector.

Other Improvements and Bug Fixes

• System statistics: Support 100 day retention for Enterprise plans
• Index Advisor: Fix multiple issues where query analysis fails with "internal error"
• VACUUM Advisor: Fix missing bloat data / incorrect last autovacuum date in per-table bloat table

pganalyze Collector v0.70.1 and v0.70.2

• Aurora: Improve disk size reporting
  • Use the VolumeBytesUsed CloudWatch metric at the cluster level
  • Previously, the collector reported OS-level filesystem values that were inaccurate regardless of the actual cluster storage in use
• AlloyDB/Cloud SQL: Fix IAM authentication by removing prepared statements
  • Previously, explicit prepared statements broke when AlloyDB/Cloud SQL was configured with IAM authentication if the proxy was not configured for prepared statements
  • This removes all prepared statement usage from collector queries independent of the provider in use, allowing proxy use without changes
• Docker image: Raise alpine/musl stack size from 2MB to 8MB
  • This matches what glibc would typically use, and fixes a crash on a very complex query making heavy use of UNION
• Log processing: Support log_error_verbosity = verbose
  • Previously using Log Insights was not supported when log_error_verbosity was set to "verbose", as log messages get the SQLSTATE inlined into them, confusing the parser. This is now special-cased and supported, and the checks for the setting are removed
• Fix compatibility with existing pganalyze Enterprise Server releases
  • Version 0.70.0 added tracking of nested query statistics using the toplevel field, which broke compatibility with Enterprise Server when using pg_stat_statements.track = all.
  • This change detects whether the pganalyze server supports nested query statistics so that new collector versions can be used without upgrading the server.

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.