AUGUST 2026

pganalyze supports Supabase & Neon, how to diagnose high cardinality workloads, our AI tuning webinar + Enterprise Server v2026.08.0

Hi there,

New Postgres databases are increasingly created by AI agents rather than humans: over 80 percent of new databases on Neon, and more than 60 percent on Supabase. But once those databases grow up, they experience performance problems just the same. To help with that, pganalyze now supports Supabase and Neon as monitored system types. Connect the collector to your project and you get the same workflow you already use on RDS/Aurora, GCP, Azure or self-managed Postgres: query statistics from pg_stat_statements, Log Insights, and on Supabase, EXPLAIN plans collected through auto_explain. Ryan's announcement post walks through how monitoring works on both platforms and the setup for each.

For self-managed installations, Enterprise Server v2026.08.0 is now available. The biggest change is a rework of Checks & Alerts around Alert Rules and Alert Destinations (which also recently landed on cloud), separating what triggers an alert from where the notification is sent. Existing alert policies are migrated automatically during the upgrade. The release also brings the two new Query Advisor insights to Enterprise Server, adds log line and log statistics tools to the pganalyze MCP Server, and the container image is now published for both x86-64 and ARM64.

Almost every Postgres tuning conversation starts from pg_stat_statements, so it's worth asking a question most of us skip: is the extension actually keeping the queries that matter, or has your workload already outrun it? Ryan is back with Part 6 of the pg_stat_statements deep dive: Diagnosing High Cardinality Workloads, which digs into exactly this. ORMs, dynamic SQL, and increasingly AI-assisted development tools all generate more distinct queryids than you might expect. Once those outrun pg_stat_statements.max, the statistics you need start quietly disappearing. Ryan runs the same workload side by side on Postgres 17 and Postgres 18, and walks through the concrete checks that tell you whether this is happening on your database.

And if you didn't catch our July webinar, pganalyze MCP in Action: Optimizing Postgres with Claude Code and other AI Tools, the replay is now available to watch on demand and we're actively testing the new MCP + Workbooks integration with early access participants.

On the community side, we're sponsoring two conferences in the coming weeks: DjangoCon US in Chicago, and Postgres Summit US (formerly PGConf NYC) in New York City, where we'll also give a sponsor talk. 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. Oh, and in case you missed this morning's Postgres minor releases: Its worth taking a look, because there are a lot of important security fixes included.

Announcement

pganalyze now supports Supabase and Neon

pganalyze now supports Supabase and Neon as monitored system types, starting with collector v0.72.0. Run the collector on your own infrastructure, point it at your project, and you get continuous query statistics from pg_stat_statements, Log Insights delivered over OpenTelemetry, and, on Supabase, EXPLAIN plan collection through auto_explain. Ryan's announcement covers how monitoring works on each platform and the concrete setup steps.

Enterprise Server

Enterprise Server v2026.08.0: Reworked Checks & Alerts, new Query Advisor insights & ARM64 support

Enterprise Server v2026.08.0 is now available. In this release we reworked Checks & Alerts configuration, which is now built around Alert Rules (what triggers an alert, and for which servers) and Alert Destinations (where notifications are sent), with existing alert policies migrated automatically during the upgrade. The release also brings the two new Query Advisor insights (Inefficient Index Use, and Late Join Filter with OR) to self-managed installations, adds log line and log statistics tools to the pganalyze MCP Server, adds Neon and Supabase as supported system types, and publishes the container image for both x86-64 and ARM64.

Postgres in Production

Deep Dive into pg_stat_statements (Part 6): Diagnosing High Cardinality Workloads

In Part 6 of the Postgres in Production deep dive series, Ryan Booz asks the question that determines how useful pg_stat_statements can be for you at all: do you have a high cardinality workload? The episode covers where unique queries come from (ORMs, dynamic SQL, and AI-assisted development tools generate more of them than you might expect), a side by side demo of the same workload on Postgres 17 and Postgres 18, and the concrete checks that tell you whether pg_stat_statements is losing the data you need for query tuning.

Webinar Replay

pganalyze MCP in Action: Optimizing Postgres with Claude Code and other AI Tools

We walk through the Postgres tuning loop using Claude Code and the pganalyze MCP Server, which now includes Workbooks benchmarking. Have your AI tool check a proposed rewrite with EXPLAIN ANALYZE and iterate on improvements with actual measurements from production, safely collected through pganalyze.

Product Updates

What's New in pganalyze

Index Advisor

• Fix "relation does not exist" errors for tables referenced inside certain clauses (aggregate FILTER and ORDER BY, window definitions, VALUES lists, RETURNING, and ON CONFLICT). Affected queries are now analyzed correctly and included in Index Advisor.

pganalyze MCP Server

• Add new tools for accessing Log Insights data
• Early access for optionally allowing Workbooks use (as shown in the recent webinar)
• Add title annotations to tools

Checks & Alerts

• Revamped alert configuration around Alert Rules (what triggers an alert) and Alert Destinations (where notifications are sent). Rules can track different Checks, apply to one server or all servers in the organization, and target zero or more destinations. More changes (server group support, role-based e-mail notifications, other destination targets) are coming soon. Learn more in the documentation.
• New options on the Active Queries check to skip long-running statements that are expected to run without blocking other queries: "Ignore concurrent CREATE INDEX/REINDEX" and "Ignore non-blocking maintenance commands" (VACUUM excluding VACUUM FULL, and ANALYZE). Both off by default.

EXPLAIN

• Fix error when viewing large EXPLAIN plans

Workbooks

• Allow creating a new parameter set by copying an existing one

Other improvements

• Fix reporting of "Last Used At" date for newer collector API keys (keys created in the last two years showed an empty timestamp even when actively sending statistics data)
• Render longer database names in the database menu
• Speed up initial app loading time for organizations with many servers
• Drop use of JWT tokens for API access by the app itself

pganalyze-collector 0.72.0

• Add Supabase and Neon as supported system types, including OpenTelemetry log collection for both
• Allow adjusting the log download interval up to 10 minutes per server (AWS, PlanetScale, self-hosted), reducing rate limit problems for less active servers
• EXPLAIN normalization: accept fractional Actual Rows for Postgres 18+
• Use SHA-256 digests for RPM packages, enabling installation on FIPS systems
• Postgres settings: fix parsing of array values in config (e.g. search_path)

pganalyze Enterprise Server v2026.08.0

• Checks & Alerts reworked around Alert Rules and Alert Destinations; existing alert policies are migrated automatically
• Query Advisor: new Inefficient Index Use and Late Join Filter with OR insights
• pganalyze MCP Server: new log line and log statistics tools, and support for extra OAuth redirect hosts via OAUTH_ALLOWED_REDIRECT_HOSTS
• Neon and Supabase added as supported system types
• Workbooks: the New Workbook page now suggests your top queries by runtime as starting points, and parameter sets can be created by copying an existing one
• Server Groups: support for custom display names
• Container image now published for both x86-64 and ARM64; combined collector updated to v0.72.0
• This release requires a database migration; be sure to follow the recommended upgrade steps