AUGUST 2026

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

Hi Newsletters,

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

JULY 2026

Building Postgres tuning loops with Claude and pganalyze, plus three new Query Advisor insights

Hi Newsletters,

Since the pganalyze MCP Server moved to public preview, we've seen it become widely used - from data platform teams using it to streamline their processes, to engineers driving investigations across tool boundaries. But we've also gotten questions on how to use the MCP Server effectively. In our upcoming July 30 webinar we'll share what we've learned over the last 4 months, and also preview a new feature: The ability to optionally let AI tools use pganalyze Workbooks to run EXPLAIN ANALYZE, with guard rails. This helps validate query rewrites or settings changes, and enables an effective tuning loop with tools like Claude Code. Register here for the webinar.

Prefer deterministic logic that runs in the background and notifies you? We're excited to introduce three new Query Advisor recommendations. Query Advisor continuously analyzes your EXPLAIN plan data, and now detects index scans that remove too many rows with a filter (instead of an index condition), sorts and hash joins spilling to disk when work_mem is too low, and OR conditions across two joined tables that stop Postgres from using an index. Each insight comes with a recommendation that you can test in a Workbook yourself, or you can have AI tools do the benchmarking for you.

Ryan is back with Part 5 of his pg_stat_statements deep dive, this time on pg_stat_statements configuration, including how pg_stat_statements.max drives deallocations. Every time pg_stat_statements runs out of room, it drops 5% of its entries. That means 250 rows at the default max of 5,000. The pg_stat_statements_info view has a counter for this, and Ryan walks through how to read it over a 10-minute window, plus the settings and application changes that reduce the loss.

On the community side, Postgres 19 Beta 2 is now available. It is not meant for production, but testing and providing bug reports is essential, and helps us all get the best release possible later this year. And if you didn't catch last month's webinar on plan statistics and plan management (including the new PG19 pg_plan_advice module), the recording is now available.

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

Upcoming Webinar

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

The pganalyze MCP Server made it safe for AI assistants like Claude to read your Postgres monitoring data. Connecting Workbooks to the MCP Server, now in early access, lets them test fixes too: creating a workbook for a slow query, running real EXPLAIN ANALYZE executions through the collector, and comparing a rewrite against the baseline plan. Join Lukas live on Thursday, July 30 to see end-to-end tuning workflows, from first triage to a validated fix.

Product Update

New Query Advisor Insights: Inefficient index use, work_mem tuning, and OR to UNION rewrites

pganalyze Query Advisor now detects three more common Postgres problems straight from your EXPLAIN plan data: an index that scans far more rows than it returns, sorts and hash joins spilling to disk because work_mem is too low, and OR conditions across two tables that stop Postgres using an index (rewritable as a UNION). Each comes with a specific recommendation you can validate in Workbooks before shipping.

New Episode

Configuring pg_stat_statements to Reduce Deallocations (Part 5)

pg_stat_statements has only a handful of settings, but they decide how much query data you keep and how much you lose. In Part 5 of the Postgres in Production deep dive, Ryan Booz shows how to spot the loss with the deallocation counter in pg_stat_statements_info, what each of the five settings actually does (including why max requires a restart and reserves memory even when tracking is off), and why changing settings is often not enough, but application changes are required: IN lists (before Postgres 18), string concatenation, and querying with large numbers of unique roles.

Watch On Demand

Postgres Plan Monitoring & Management: Best Practices & Postgres 19

Missed it live? A plan flip is the most common reason a Postgres query goes from fast to slow without any code change, but Postgres doesn't normally show you which plan ran and when. In the June webinar recording, Lukas walks through how pg_stat_plans makes plan history visible on any modern Postgres deployment, when CREATE STATISTICS or a setting change fixes a bad plan and when you need to hint instead, and what pg_plan_advice in Postgres 19 adds for plan stability.

Product Updates

What's New in pganalyze

Query Advisor

• New Inefficient Index Use insight

  This insight detects Index Scan nodes that read many rows only to discard most of them at the filter, and reports when a different existing index exists that could be a better match.

• New Late Join Filter with OR insight. Detects joins with an OR condition spanning both joined tables, which prevents Postgres from using an index on either side, and flags when existing indexes could support rewriting the query as a UNION. (See this month's feature above for all three new insights that were recently launched.)

Index Advisor

• Support uppercase column names for captured extended statistics.
• Unused index check: raise the maximum look-back period from 35 to 400 days, so indexes used only occasionally (for example once a year) are not incorrectly flagged. The default is kept at 35 days.

Other improvements & bug fixes

• Workbooks: Suggest queries to start from on the New Workbook page

  Previously the New Workbook page showed only an empty SQL editor, leaving users without a query in mind to figure out the next step on their own. The page now lists the database's top 10 SELECT queries by % of total runtime over the last 24 hours; clicking any row starts a workbook pre-filled with that query.

• Persist series selection from the legend across navigation, for example when narrowing the selected time range on the Connections page. Resets to defaults with a full-page reload.
• Fix search box losing focus while typing

  Searching the query list no longer drops focus after each keystroke, and a search with no matches now shows an empty table instead of an unrelated setup hint.

• System: Graph WAL size on WAL & Replication tab
• Server Groups: Support custom display names
• Fixed Slack integration setup, and table sorting on the Connections page

   

• Add ability to hide columns in some tables

pganalyze Collector v0.71.0

• Track temporary file usage per database (temp_files and temp_bytes from pg_stat_database), and track IO worker backends on Postgres 18+
• Fix unbounded memory growth when stitching multi-line log events, such as large auto_explain JSON plans: stitched content is now capped at 10MB with a warning, preventing collector OOMs
• Fix a collector hang on config reload (SIGHUP), and prevent file and goroutine leaks during self-hosted log tailing
• Faster schema collection on databases with many partitions, and correct ignore_schema_regexp filtering for large partitioned catalogs

Earn 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.

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 Newsletters,

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.

MAY 2026

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

Hi Newsletters,

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.

APRIL 2026

Faster EXPLAIN ANALYZE in Postgres 19 & New Deep Dive Series into pg_stat_statements

Hi Newsletters,

Last week, Postgres 19 hit feature freeze — meaning the window for new features is now closed, and the community shifts into stabilization mode ahead of the release later this year. Over the next weeks you'll hear more from us on new exciting feature in the upcoming Postgres release.

For today, I wanted to highlight a feature I worked on myself, together with Andres Freund and David Geier: Lower overhead for taking timing measurements in EXPLAIN ANALYZE. I'm sure you've run EXPLAIN ANALYZE before, and wondered why the query seems slower than it actually is. It depends on the query, but the most common cause of slowness is repeated instrumentation start/stop calls as nodes are entered (and measured) during execution. In the upcoming Postgres 19 release, you will see noticeably less overhead from timing, thanks to using the RDTSC instruction directly on x86-64 CPUs. Learn more in 5mins of Postgres episode 122.

We're also kicking off a new special series on Postgres in Production with Ryan Booz: a deep dive into pg_stat_statements. If you've ever relied on this extension for query performance monitoring (and most of us have), this series digs into what it actually tracks, what it doesn't, and the misconceptions that can leave you flying blind when it matters most. Part 1 covering the fundamentals is out now.

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

Waiting for Postgres 19

Lower overhead for EXPLAIN ANALYZE in Postgres 19

In this episode we talk about a change in the upcoming Postgres 19 release that will lower timing overhead for EXPLAIN ANALYZE. This is a change that the community has worked on for a couple of years now, but for this release we finally figured out all the little details that make this work. The core of how timing got faster: By allowing out-of-order execution of timing measurements through the RDTSC instruction (x86-64), instead of the standard RDTSCP instruction through clock_gettime. Learn all the details through the transcript, or by watching the video:

New Series

pg_stat_statements: Where Postgres Performance Monitoring Begins

In this special series of "Postgres in Production", Ryan Booz takes a deep dive into pg_stat_statements — the essential Postgres extension for tracking query performance.

In Part 1, Ryan covers what pg_stat_statements is, how to enable it, what it tracks (45+ columns as of Postgres 18), and critically — what it doesn't track and why that matters. You'll learn why all metrics are cumulative, what happens when the 5,000 unique query limit is reached, and why treating it as the single source of truth for query performance history can leave you flying blind.

Community News

Upcoming Events

We've just wrapped up a busy stretch on the European conference circuit. It was great connecting with the Postgres community and customers at Nordic PGDay and pgDay Paris, and Ryan's talk on actionable observability was well received. Next up, Ryan is speaking at Postgres Conference 2026 in San Jose, CA (April 21–23), with multiple talks spanning everything from Postgres to beekeeping. In May, the team heads north to PGConf.dev in Vancouver (May 19–22), to talk all things Postgres development. We love meeting community members at these events, so come find us if you'll be there!

Product Updates

What's New in pganalyze

MCP Server (early access)

• Switch to TSV output format for timeseries data
• Introduce tool call rate limiting, see documentation
• Allow API key authentication in addition to OAuth
• Support for Claude on Web, ChatGPT and Cursor clients

pganalyze-collector 0.70.0

• Track nested query statistics separately based on toplevel field
  • This matters when pg_stat_statements.track is set to "all", and allows pganalyze to consider query activity from inside functions, or other nested cases (e.g. EXPLAIN) separately from top level activity (direct query execution)
• Allow resetting pg_stat_statements when nearly full
  • Due to pg_stat_statements deallocating 5% of the least used queries when full (i.e. number of entries hits the pg_stat_statements.max), certain workloads can experience a high rate of <query text unavailable> in pganalyze, due to very old queries with high call counts taking priority over more recent query activity.
  • In such situations, a recurring pg_stat_statements_reset() call can avoid the situation by clearing 100% of entries, so that there is more space for fresh entries
  • This reworks the existing reset mechanism to reset pg_stat_statements when (1) it has utilized most of its entries, and a dealloc is likely occurring soon (2) the returned query text exceeds 250MB
  • Resets are optional and turned off by default. When the helper function exists, and the reset interval is configured through pganalyze, it is now taken as the highest permitted reset frequency, i.e. with this change resets will likely occur less often than before (previously it was a fixed interval that would always reset)
• Keep per-query information on whether a query / query sample was normalized
  • This lets the pganalyze application be informed whether PII filtering was applied to a particular snapshot being submitted.
• Allow multiplexed use of OpenTelemetry logs server
  • Multiple servers can now share the same db_log_otel_server configuration
  • This is safe to do in certain circumstances, specifically when a Kubernetes pod or label filter is in place, and the log message has sufficient details (i.e. is annotated with Kubernetes metadata)
  • If configured without a pod/label filter the collector will emit a warning, and send received logs to each server sharing the same db_log_otel_server
• Kubernetes label matching: Ensure selected labels are present for equality
  • Previously a label specified in the selector, but not actually present in the data would lead to that part of the selector being skipped, not counting it as a mismatch. Instead count it as a mismatch for equality, but a match for inequality.
• Diff pg_stat_statements_info dealloc counter correctly on initial collector start
• Rework OpenTelemetry logs handler to be OTLP spec compliant
• Crunchy Bridge: Don't crash when metrics retrieval fails
• AlloyDB/Cloud SQL:
  • Allow IAM authentication to use private service connect endpoint
    • This is enabled by setting the new gcp_use_psc / GCP_USE_PSC to true
  • Avoid accidental use of prepared statements when IAM authentication is in use
• AlloyDB: Add back support for follower statistics
  • This revises the change added in 0.69.0 to more specifically skip the problematic function on a replica

Query Performance

• Persist table sort order in query string

  • This allows users to navigate back to a page of sorted results (e.g., in the Query Performance list) and maintain the sort order.
• Change statement type filter to exclude DML when only SELECT is checked

  • Previously, any queries that included a SELECT component (like "INSERT ... SELECT" or even "INSERT ... VALUES") were returned. Limiting to SELECT-only is more in line with what users expect from a filter like this.

Automated EXPLAIN

• Improve plan parsing when auto_explain.log_format=text

  • This adds support for JIT output changes in newer Postgres versions and fixes worker detail parsing when auto_explain.log_timing is disabled.

Connections

• Improve how Connection Traces listing responds to date range selection

  • Previously, the selected focus timestamp had inconsistent behavior when the date range is updated, or the focus timestamp itself is updated by clicking on the Wait Events or Connection States graphs.
  • This standardizes its behavior: when a labeled date range is selected (e.g., Last 24h), the selected focus timestamp for the Connection Traces listing is cleared. When an unlabeled date range is selected, if the focus timestamp falls within the new range, it remains unchanged. If it does not, it is reset to the end of the range.

Other Improvements

• Database Dashboard: Show check-up status of all available checks
  • The check-up widget on the database dashboard now covers all check types. Previously, only some checks were shown. Each check group now also displays the number of active issues.
• Checks & Alerts: Do not alert about AlloyDB replicas with fsync=off

  • Also downgrade the alert to a warning if running on a non-AlloyDB replica: this is still worth addressing (since an untimely crash could lead to having to rebuild the replica), but it's unlikely to be a critical issue.

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.

MARCH 2026

The 'AI DBA' Dilemma, Postgres Tuning with Honeycomb + pganalyze MCP Server in Action

Hi Newsletters,

Welcome! I wanted to start this month's newsletter on a topic that's been top of mind for many. My perspective on AI tools has shifted considerably over the past year — from "this doesn't really solve complex tasks for me" to "this actually works pretty well for certain use cases." But the more capable these tools become, the sharper one dilemma gets: you can hand off the work, but an AI agent won't be responsible at 2am when the database goes down. The 'AI DBA' framing is becoming a real marketing buzzword, and I think it's missing the mark in ways that matter when things go wrong in production. In today's article I dig into why, and what I think we should be doing instead.

The session we recorded last month gets into the practical side of that. I walk through a real investigation using APM tracing data from Honeycomb alongside pganalyze data — using Claude Code and the pganalyze MCP Server (now in early access) to drive the analysis, without needing direct access to production and risk exposing anything the LLM shouldn't see. Worth watching if you're curious what this kind of workflow looks like day-to-day.

Interested what's going on with Postgres? This month is the final commitfest (1 month review cycles in Postgres development) for Postgres 19. With feature freeze coming up in early April, now is the time the final features get shaped. More on what got merged in next month's newsletter!

As always, you can find the complete list of pganalyze product updates at the end, including the availability of cluster-aware indexing recommendation for those on pganalyze Enterprise Server.

New Article

The Dilemma of the 'AI DBA'

AI tools are getting better at database work, but aiming to have an 'AI DBA' is setting the wrong goal. In this article, we explore why handing off the work to an AI agent doesn't mean handing off responsibility, and what a more grounded approach looks like for teams running Postgres in production.

Demo Recording

Postgres Performance Tuning with Honeycomb, Claude Code, and the pganalyze MCP Server

In this session, we walk through investigations using Claude Code alongside Honeycomb and pganalyze: tracing slow requests from APM spans all the way to EXPLAIN plans, without exposing sensitive data or connecting AI tools directly to your database. To request early access to the pganalyze MCP Server feel free to reply to this email - we're doing a phased rollout & we'd happy to put you on the list!

Community News

Upcoming events

We're heading to two Postgres community events this month. Ryan will be presenting at Nordic PGDay in Helsinki on March 24 and pgDay Paris on March 26, covering how to build a practical observability framework for Postgres that cuts through the noise and actually helps you find the queries worth investigating. Let us know if we'll see you there! We'll also be at PG Data 2026 in Chicago this June — more details on talks there soon.

Product Updates

What's New in pganalyze

Index Advisor

• Support schema names with uppercase letters

  • Previously, when the referenced tables or functions are in the schema with uppercase letters, we were unable to run the query analysis of the query, therefore the Index Advisor was failing to run with such queries.
• Fix handling of fully qualified table names not in search path

  Previously the query analysis process (part of Index Advisor) did not correctly handle such cases, leading to errors because the referenced tables could not be found.

• Fix handling of table names that need quoting (uppercase, special characters, etc)

MCP Server & AI Tools

• GraphQL API: Add getQueryExplainFromTrace resolver to get EXPLAIN plans from "db.postgresql.plan" trace spans
  • When the pganalyze OpenTelemetry tracing integration is utilized, the pganalyze-collector will insert special links into the respective traces to link back to the full EXPLAIN plan in pganalyze.
  • These links can be easily followed with a browser, but can be challenging for AI tools to resolve.
  • To assist AI tools / MCP servers, provide a dedicated getQueryExplainFromTrace GraphQL resolver that takes the necessary arguments from the link (datname, timestamp, fingerprint) and returns an EXPLAIN plan.

Other Improvements & Bug Fixes

• Improve performance with many connections
  • When the connection count at a given time exceeds thousands, the page was very slow or sometimes unable to load. Now it supports rendering multiple thousands of connections.
• Query Details Page: Fix visual indication of times when query was not run, but other queries had activity
  • This was incorrectly showing as missing data (dashed grey area) due to a recent change, when it should have been showing as zero calls instead. This also avoids the graph becoming unreadable for infrequently run queries.
• Single Sign-On: Support SAML certificate update
  • When a SAML Identity Provider certificate is rotated or approaching expiration, it can now be updated directly from the Integrations page without needing to reconfigure the entire SAML integration.
  • A warning banner is shown when the certificate expires within 14 days (or has already expired).
• Improve server and database dropdown navigation to better support long server names
  • The server dropdown now dynamically sizes its width based on the longest server name, expanding up to the right edge of the database select. Primary and replica badges are visually distinct and always fully visible alongside server names.
• Ensure JWT tokens generated by application use integers for "exp" field
• The "exp" field was previously incorrectly serialized as a string in the JWT token, which is a violation of the JWT spec, and may cause issues with proxies between the application and the end-user browser.

pganalyze Collector v0.69.0

• Improve query text collection to reduce missing query texts
  • Add a fingerprint cache that retains known query IDs across collection cycles, increasing collector memory use by up to about 9 MB per monitored server whilst reducing CPU overhead
  • For data from pg_stat_activity (Connections page in pganalyze), this reduces the occurrence of <truncated query>
  • For data from pg_stat_statements (Query Performance page in pganalyze), this reduces the likelihood of "query text unavailable" by re-using previous query texts already stored on the server side
• PlanetScale: Paginate log fetching to ensure freshness
  • Previously, only a single page of up to 1,000 log entries was fetched, which proved insufficient for high-traffic servers. The collector now paginates through all available entries
• AlloyDB: Skip collecting replication stats to avoid errors
• Helm chart: Allow setting pod labels and pulling images by digest
• Syslog handler: Add UDP listener
• Add packages for Debian 13 (Trixie)

pganalyze Enterprise Server Release v2026.02.0

• pganalyze Enterprise Server release v2026.02.0 is now available and 

  does not require a database migration when coming from v2026.01.0

  • If upgrading from older releases, review the migration notes on the v2026.01.0 release notes

• Postgres 14+ is now required for the internal statistics database used by Enterprise Server

• pganalyze Index Advisor now analyzes Postgres clusters as a whole rather than treating each server in isolation, combining workloads from primary and replica servers to make unified index recommendations across the entire cluster

• This release changes some private GraphQL API fields

• The full list of updates is available in the release notes including more information on the GraphQL API changes at the end

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.

FEBRUARY 2026

Index Advisor Goes Cluster-Aware, Better Planner Hints, Plus New MCP Webinar

Hi Newsletters,

We made it to February! We started this month with shipping a big upgrade to Index Advisor: it's now cluster-aware, combining workloads across primaries and replicas so you get one unified set of index recommendations instead of conflicting advice per server.

Are you wondering if you could fix slow queries faster with AI tools? Whilst "AI" is certainly not the one-size-fits-all solution that we are often promised, there are use cases where AI code assistants like Claude Code work pretty well. And thanks to MCP servers, we can implement specific workflows, like optimizing a Postgres database query. In our upcoming February 26th webinar, I'll share how we can safely provide Postgres production statistics to AI tools, when (not) to use them, and what the upcoming pganalyze MCP server offers.

These days, one thing that often comes too short is code reviews. To do my own part, over the holiday break, I sat down and reviewed a series of Postgres patches by Robert Haas, that intend to give Postgres better planner hints. And the first patch ("allow plugin control over path generation strategies"), is now committed to Postgres 19. Watch the new 5mins of Postgres episode to learn more, including how it will help future maintenance of pg_hint_plan.

One more thing: our own Ryan Booz is co-leading a full-day, in-person PostgreSQL training at SCaLE 23x on March 5th in Pasadena, alongside Elizabeth Christensen and Devrim Gunduz. It's great for anyone new to Postgres or looking to sharpen their performance tuning and administration skills. Use the code PGSQL for 40% off registration.

As always, you can find the complete list of pganalyze product updates at the end. And we look forward to seeing you at pgDay Paris and PG Day Nordic next month if you're attending.

 Live Session

Can AI + MCP Fix Your Slow Postgres Queries Faster?

5min of Postgres

Waiting for Postgres 19: Plan Generation Strategies

Product News

pganalyze Index Advisor is Now Cluster-Aware

Ever dropped an index that looked unused only to find out it was serving queries on a read replica? That's the problem with analyzing Postgres servers in isolation. To address this challenge, we're announcing the updated pganalyze Index Advisor, which is now cluster-aware. It combines workloads across primaries and replicas to produce one unified set of recommendations. No more conflicting insights. No more guesswork about what's actually in use.

Available now for Scale and Enterprise cloud plans. Enterprise Server coming in the next release.

Product Updates

What's New in pganalyze

Query Performance

• Query Advisor: Avoid internal error when referenced EXPLAIN plans have aged out
  • On resolved Query Advisor issues you may not be able to access the associated EXPLAIN plan anymore (which is only retained for 7 days currently).
  • Instead of showing an error, show a notice explaining this.
• Workbooks: Fix bug preventing use of manually created parameter sets
  • This bug in a recent change incorrectly prevented the creation of Workbooks that were using manually added parameters instead of query samples with an error like "Either parameterSet, queryText, or querySampleIds is required".
• Persist search input in query string
  • This allows navigating back to a page of filtered results (e.g., in the Query Performance list) and maintain the filtered list

Schema & Plan Statistics

• Fix tree map links to tables and indexes to preserve date range selection
• Improve display for queries that run infrequently
  • Previously the plan statistics graphs would show data points where the query didn't run with the dashed area marker, typically used for missing data for the whole database/server.
  • Instead, the graphs now show zero at such points when there were other queries with activity on that database.

Collector WebSocket Connection

• Show warning when the collector WebSocket connection is unhealthy

  • In 2024 the collector moved to a persistent WebSocket connection to reduce overhead and enable two-way communication.

  • If your servers haven't been updated to a recent collector version or have networking issues that don't allow the connection to stay alive for at least an hour, you will now see an in-app warning.

  • Later in 2026 we plan to drop the legacy API and require a WebSocket connection, so please reach out to support if you see this warning.

Postgres 17 & 18 Updates

• Show autovacuum_vacuum_max_threshold value for Postgres 18+

  • The dead rows graph now takes autovacuum_vacuum_max_threshold into account when available, improving visibility into when autovacuum is expected to run.

• Config Settings: Update bundled Postgres documentation to include Postgres 18

• Connections: Update wait event name list to support Postgres 18
  • Previously, some wait event names were not appearing correctly on the Connections page and were shown as Unknown (e.g. Activity / Unknown instead of Activity / BgwriterMain).
• Support showing EXPLAIN plans containing JIT info using new (Postgres 17) format

pganalyze Collector v0.68.0, v0.68.1 and v0.68.2

• Add support for PlanetScale databases
  • This adds PlanetScale as a new supported server type, including log fetching from PlanetScale's log services
  • New configuration settings: planetscale_org / PLANETSCALE_ORG,
    planetscale_database / PLANETSCALE_DATABASE, and
    planetscale_branch / PLANETSCALE_BRANCH for identifying instances
• Improve collector log analysis
  • Add matching for autovacuum messages produced by newer AlloyDB versions and Postgres 18
  • Handle terminology changes in Postgres 14+ where "misses" became "reads" in buffer usage reporting
  • Capture SLRU and LSN information from checkpoint completion messages
  • Add new log event type for connection authenticated messages
  • Expand patterns for connection failure scenarios
• Add Vector OTLP export configuration example to contrib/vector
  • This supports using Vector instead of Fluentbit for forwarding log events
    via OpenTelemetry Protocol
• Fix infrequent crash in query normalization when encountering certain utility statements
• Do not fail snapshot collection when pg_stat_statements is missing with Postgres 14+ 
  • In such situations we now report a snapshot with an error state, as was the case
• Allow explicitly setting Cluster ID
  • The new api_cluster_id / API_CLUSTER_ID setting enables overriding the automatically detected cluster ID, or set it on platforms that don't have built-in detection.
  • This value is stored by pganalyze for each server, and used for grouping servers together. Alternate mechanisms to create server groups in pganalyze will be offered in a future release.

Other Bug Fixes & Improvements

• Fix links on some Index Advisor pages that had incorrectly-generated links to the queries involved
• Fix "Replication - High Lag" check-up graph rendering issue
• Fix occasional issues that caused parts of the app to be shown with

  limited seven day retention instead of normal retention

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.

JANUARY 2026

Extended Data Retention for 100 days, Enterprise Server v2026.01.0 & a Thank You from pganalyze

Hi Newsletters,

Welcome to 2026! First, I wanted to say thank you to everyone who responded to my email request for product roadmap feedback earlier this week. The amount of replies with thoughtful comments and suggestions was incredibly helpful as we dive into planning for the upcoming year!

As a sign of our gratitude for the support over the years, we'd like to send you a pganalyze swag package. Request one here.

In product news, we're announcing the release of pganalyze Enterprise v2026.01.0 today, which now includes the Query Advisor feature we launched last quarter for Cloud as well as the just announced 100-day retention time for query, table and index statistics. Something many of you have been requesting, and we're excited to deliver!

We're also looking forward to be back in Europe in March where we will have booths at both PGDay Nordic and pgDay Paris. Please reply here if you plan to be at either event, so we can connect.

As always, you can find the complete list of pganalyze product updates, including the Enterprise release details, at the end.

Product News

100 Day Retention Now Available for Enterprise plans

Today, we're excited to announce extended 100 day retention time for query, table and index statistics in pganalyze. In our announcement post you'll get a quick overview on the new feature, and some details on how we made it work behind the scenes, and how our timeseries storage format has evolved over time, and is now utilizing the pco compression library.

Product News

v2026.01.0 Enterprise Release with Query Advisor

If you've been waiting for an Enterprise Server release with the new Query Advisor: The wait is over!

Go head to our release changelog page, learn all the details about the release, you can also find a short summary at the end of this email. Query Advisor, Workbooks in GA, 100 day retention & more!

We also recommend reading about how the migration to the pco-based storage format (that supports the longer retention) may impact your upgrade process, especially when monitoring 100+ database servers with pganalyze.

After upgrading all new EXPLAIN plans coming into pganalyze will be analyzed automatically for Query Advisor - and if we find a problematic query plan pattern, our new alert for bad query plan patterns will tell you right away!

Community

A Small Thank You to Start 2026 from pganalyze

To start 2026, we want to say thank you to the Postgres community that has supported and shaped pganalyze over the years. We are sending out a limited run of pganalyze swag as a small token of appreciation. Depending on availability, this may include stickers, pens, or other pganalyze-branded items.

If you would like one, share your mailing address and we will take care of the rest. Domestic US and international shipping is available, with some country restrictions. Your address will only be used to send this package.

Upcoming Events

Closing out 2025 at re:Invent & Kicking Off 2026 at PGDay's in Helsinki & Paris

We wrapped up 2025 at AWS re:Invent with a great few days of conversations with Postgres practitioners working on real production challenges. One theme was impossible to miss: AI was everywhere. We had thoughtful discussions about why pganalyze does not rely on AI for its advisors today, especially when it comes to trust, explainability, and actionable insights. At the same time, your feedback has us thinking more deeply about where integrating with AI tooling could genuinely be useful, and we are actively exploring options, including an MCP Server integration.

To kick off the year, we are continuing these conversations to Europe. We will have booths at Nordic PGDay in Helsinki on March 24, 2026, and pgDay Paris on March 26, 2026. If you are attending either event, we would love to connect in person and continue the discussion around Postgres performance, operating in production, and what is coming next.

Product Updates

What's New in pganalyze

Extended retention times for query, table and index statistics

• Enable 100-day retention for query and schema statistics on Enterprise plans
• pganalyze Scale plan now stores 35 days of history
• The date picker interface has been updated to reflect the additional retention time and to allow selecting longer time frames.
• Read details in our blog post

Schema Statistics

• Show View detail page when a view is loaded through the Table detail page

Logical Date Ranges

• Currently, when a period like "Last 24h" is selected in the date picker, this is only resolved to a concrete date range (e.g., "2025-12-04 00:00:00 to 2025-12-05 00:00:00") once.

• If you use the app for an extended period of time, that resolved date range is stuck in the past and grows stale.

• Instead, re-resolve the date range periodically (only when navigating to a new page) to ensure fresh data is always loaded.

Product Updates

pganalyze Enterprise Release v2026.01.0 

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.

DECEMBER 2025

"Postgres on AWS Best Practices" Recording,  New Query Formatter Tool, & pganalyze's AWS Marketplace Launch

Hi Newsletters,

Welcome! We just wrapped up our first AWS re:Invent as an exhibitor, and it was a huge success. It was great meeting so many teams running Postgres at scale and hearing firsthand about the challenges you’re solving every day - and we're glad to have had multiple customers join us at the booth to discuss how pganalyze enables their engineering teams to work better.

This month’s edition brings together several updates shaped by those conversations. First, we’re sharing the recording of our deep dive webinar on how RDS, Aurora, and alternatives like CloudNativePG on EKS implement key PostgreSQL internals, what these differences mean for performance optimization and monitoring, and what's new (Database Savings Plans!).

Today, we’re also launching a new free Postgres Query Formatter built on our libpg_query library, available at pganalyze.com/format. This is the same formatter we use in pganalyze Workbooks to help you benchmark and diff queries, and its now available as a standalone tool that runs fully in your browser - with more customization options (max line length, etc) on the way.

We’ve also released the new pganalyze collector version 0.67.0 with support for pg_stat_plans, more reliable 1-minute pg_stat_statements collection, and several stability improvements informed by production workloads. As usual, you can find all the product updates at the end.

And finally, pganalyze is now available on the AWS Marketplace, giving teams on AWS a straightforward way to purchase pganalyze. Looking to monitor many RDS/Aurora clusters? Private offers are available by reaching out to us.

Webinar Recording

Running Postgres on AWS: What’s New & How It Impacts Performance

RDS and Aurora simplify operations, but they also abstract away important parts of PostgreSQL’s internals. In this recorded webinar with slides and extra resources, we walk through how these services implement query execution, storage, logging, and vacuum behavior, where they diverge from upstream Postgres, and what engineers should monitor to keep workloads stable. We also look at alternative deployment models like using the CloudNativePG Kubernetes operator with EKS. If you work with production Postgres on AWS, this will give you a grounded understanding of what’s happening under the hood and which Postgres setup might be right for you.

Free Tool

Make Sense of Confusing Queries with Better Formatting

We’ve made a new standalone Query Formatter available for anyone to use. It’s powered by libpg_query, the PostgreSQL parsing library we maintain, and uses the same formatting engine we built for pganalyze Workbooks to support benchmarking and diffing workflows.

All formatting runs locally in your browser via WebAssembly, so your queries never leave your machine or get sent to pganalyze.

News

pganalyze Now Available in the AWS Marketplace

We’re excited to share that pganalyze is now live on the AWS Marketplace! While the deployment model remains the same, being on Marketplace gives organizations another way to source pganalyze, including teams with committed AWS budgets who can now apply their subscription toward those commitments. You can purchase via SaaS or request a private offer through your AWS account team.

How it works:

• Install the pganalyze collector in your AWS environment
• Collect pg_stat_statements, query plans, logs, wait events, and system metrics
• Analyze workload patterns over time and surface issues in query performance, indexing, locking, and vacuum behavior

Product Updates

What's New in pganalyze

pganalyze Collector v0.67.0

Workbooks

• Add an ability to see the list of workbooks related to the query in the query details page
• Show "Run EXPLAIN" option on the overview page when upload is incomplete
  • Now you can resume the upload directly from the overview, instead of having to go to the variant page
• Default to grid view when showing EXPLAIN plans in pganalyze
  • It is more compact and is generally a better way to examine EXPLAIN plans.
  • The old "node tree" view may be retired at some point.
  • Please reach out if you find features of the node tree view that you would like to see in the grid view, or any other EXPLAIN display feedback.

Alerts & Reports

• Weekly Performance Report: Fix incorrect order of the day in Query Activity By Server graph
• Relax pganalyze:no-alert check
  • Previously, to skip Active Query and Blocking Query alerts for a specific query, the string "pganalyze:no-alert" was required to be embedded in a properly formatted comment.
  • Now, the string can occur anywhere in the query text to avoid an issue being created.

Bug Fixes & Other Improvements

• Show estimated row count for partitions on table list view
• Fix over-counting table sizes in table overview stats per database

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.

NOVEMBER 2025

Robinhood's pganalyze-based MCP Server & AWS Deprecates Performance Insights

Hi Newsletters,

Welcome! It’s been a busy month across the Postgres ecosystem, with significant changes coming from AWS, community events, and new workflows emerging from teams building on top of pganalyze. Below you’ll find our breakdown of the AWS Performance Insights deprecation, a look at how Robinhood has built an MCP server on top of pganalyze to power AI-driven developer workflows, and the latest improvements rolling out in Query Advisor.

The Postgres for All meetup also published my talk on pg_stat_plans, a new extension we published that enables capturing Postgres plan statistics, even on busy production systems. We've had good conversations with community members on the new extension at last month's PGConf.EU in Riga, with more news to come soon, including its inclusion in official package repositories.

Also, if you'll be at AWS Re:invent this year we have a booth near Yugabyte & Atlassian in the expo hall (booth #1433). Reply to this email if you'll be there, and we can connect in person!

Behind the scenes, we've recently completed migrating pganalyze's internal query statistics storage to a new storage format based on pco. If you are a pganalyze cloud customer you will notice the faster loading times, for example when viewing Query Performance data for the last 30 days. As usual, you can find all product updates at the end of the newsletter.

New Blog

AWS Performance Insights Deprecation: What to Know about CloudWatch Database Insights

AWS is retiring Performance Insights for RDS and Aurora at the end of November 2025, with all customers expected to migrate to CloudWatch Database Insights by June 2026.

We’ve heard a lot of questions about what this means in practice, so this month’s article breaks down the differences: what stays the same, what disappears, how Standard vs. Advanced Mode work, and where hidden costs show up, especially when enabling CloudWatch Log exports or the paid Advanced tier.

If your team relies on AWS’ built-in monitoring or is planning a migration, this will help you understand the real impact of the deprecation and how Database Insights compares.

We're also happy to set up a conversation and product demo if you'd like to fully switch to pganalyze for a better experience with lower cost.

Customer Story

How Robinhood Uses MCP + pganalyze for AI-Driven Developer Workflows

Robinhood recently published a deep dive into their new MCP-powered platform for automating storage workflows across hundreds of Aurora Postgres databases.

The team at Robinhood built a custom MCP server on top of pganalyze’s statistics captured from production databases, and available through the pganalyze GraphQL API. This enables engineers to see schema and performance context directly in GitHub PR checks, reduce manual review cycles, and even troubleshoot via a Slack assistant — all without touching user data.

It’s a fascinating blueprint for how AI agents can safely augment Postgres operations in complex environments.

Product News

Query Advisor Update: Early User Feedback & New Insights Coming Soon

During Early Access, teams consistently told us Query Advisor was catching issues they didn’t realize were slowing down production. Ben from Tanda put it best: “Have already used this. So good. Query went from 60s to 140ms — an ORDER BY with LIMIT meant Postgres did a seq scan instead of using the existing indexes.”

As more teams adopt Query Advisor, we’re continuing to expand its library of anti-patterns, including new improvements around work_mem tuning and plan misestimates. We're happy to see companies adopting Query Advisor as an essential part of the toolkit for using Postgres in production.

Events

Upcoming PostgreSQL & Database Events

It’s been a packed stretch of events, and we’re not done yet. We’ll be in Seattle for the PASS Data Community Summit (Nov. 17–21), including a pre-conference workshop, and then heading straight to Las Vegas for AWS re:Invent (Dec. 1–5). We’re looking forward to meeting teams thinking deeply about Postgres performance inside modern AWS workloads.

If you’ll be at re:Invent, reply to this email and let us know!

Product Updates

What's New in pganalyze

Workbooks

• Show "Run EXPLAIN" option on the overview page when upload is incomplete
  • Now you can resume the upload directly from the overview, instead of having to go to the variant page
• Support choosing parameter sets from query samples even if parameters are merged
  • Previously, merging or renaming parameters caused a "Failed to create a parameter set" error when query samples are selected as parameter sets.
• Fix parameter type inference when IN lists are used

Connections

• Add ability to select time range in Connection States History graph by dragging with the mouse
  • This matches the behavior already available on the "Wait Events" graph and makes it easier to investigate spikes in activity

Bug Fixes & Other Improvements

• Improved performance for pages showing Query Performance statistics
• Add support for converting text plans collected with EXPLAIN (COSTS OFF) to JSON

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.

SEPTEMBER 2025

Query Advisor Release, Rewriting Queries with pg_query, & Postgres 18 Webinar Recording

Hi Newsletters,

Welcome! This month, we’re focusing on how to make query optimization in Postgres both proactive and practical. We’ve released pganalyze Query Advisor, a new feature that automatically detects inefficient query patterns and helps you understand the why behind them.

We also take you behind the scenes in how we used pg_query to rewrite queries, showing how our open source parser lets us safely transform SQL without breaking semantics.

And if you’re catching up on what’s new in PostgreSQL 18, our Hands-on Postgres 18 webinar recording is available and walks through async I/O, B-tree Skip Scan, and other performance-focused improvements.

New Feature

Introducing pganalyze Query Advisor: Proactive Query Plan Optimization for Postgres

Postgres teams know the pain of one slow query snowballing into latency or downtime. GenAI analysis is too expensive to run continuously, and general monitoring tools can’t detect Postgres-specific plan issues. What’s been missing is a purpose-built, cost-effective solution that understands Postgres deeply and gives you actionable guidance.

Query Advisor continuously analyzes EXPLAIN plans, detects problematic patterns, and provides clear query rewrites you can test and apply with confidence. By identifying inefficient nested loops, poor index usage, and other anti-patterns automatically, it helps you fix performance problems before they affect production.

New Blog

How We Used pg_query to Rewrite Queries to Fix Bad Query Plans

Rewriting SQL programmatically sounds simple—but doing it safely is surprisingly complex. Regex-based rewrites miss edge cases, and AI-generated fixes can’t guarantee correctness. As we built Query Advisor, we needed a way to suggest alternative query patterns without changing semantics.

Using our open source pg_query library, we can parse queries into syntax trees, adjust them at the tree level, and regenerate valid SQL deterministically. The latest update adds pretty-printing options, making rewrites easier to read and reason about. In this post, we show how to apply pg_query to real-world examples where query rewrites lead to better plans.

Webinar Recording

Hands on Postgres 18: Async I/O, B-tree Skip Scan, UUIDv7, and More

With the release of PostgreSQL 18, performance takes another big leap forward. The new asynchronous I/O subsystem changes how Postgres interacts with disk in both cloud and on-prem environments, and B-tree Skip Scan improves index efficiency for selective queries.

Other updates include planner optimizations, UUIDv7 support, and new EXPLAIN and statistics improvements that make tuning production workloads easier. Catch up on what’s new and see these features in action in our latest webinar.

Events

Upcoming PostgreSQL & Database Events

The team had a great time at PGConf NYC, and we're excited to be at PGConf EU in Riga (Oct. 21-24) next. After that, join us at the PASS Data Community Summit in Seattle (Nov. 17 – 21) for more conversations and a pre-conference workshop. And for the first time ever, pganalyze will be at AWS re:Invent in Las Vegas (Dec. 1 – 5). We’re excited to connect with the broader cloud community and highlight how Postgres performance tuning fits into modern AWS workloads. 

Product Updates

What's New in pganalyze

Query Advisor

• Proactive query plan optimization for Postgres is now generally available
• Query Advisor continuously analyzes EXPLAIN plans in the background to detect problematic patterns and provide actionable query rewrites. Detected issues appear in the Query Advisor landing page, Workbooks, and query detail views

Index Advisor

• Improve support of tables with many scans or columns
• When a table has many scans or columns, the number of possible indexes to consider can be very large, which was causing OOM and prevented the Index Advisor from running on such tables.
• This change improves memory usage and increases the support for these cases.
• Note: There are still tables with a high number of scans or columns that we are not able to run the Index Advisor on, and we continue to work on supporting more of them.

Alerts & Check-ups

• System / Replication: Improve loading performance of replication follower list
• Improve "Replication: High Replication Lag" check-up
• This adds a graph of the replication lag to the Issue page, and clarifies which IP address the affected replica is using, instead of naming the follower by internal UUID.

Workbooks

• Add query tuning parameters to autocomplete list

Bug Fixes & Other Improvements

• Update the sidebar insight listing for the Grid view in EXPLAIN plan views
• Update overview of Log Insights
  • Use consistent colors for each category
  • Give more space to classification labels so they are readable without hovering
  • Drop classification codes to give the labels more space (the codes still show on hover)
  • Allow collapsing categories, and collapse some categories by default (the selection will persist)
  • Drop some unnecessary borders

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.

AUGUST 2025

Hands on Postgres 18, New Video Series, & Platform Engineering at Autotrader UK

Hi Newsletters,

Sept. 25 Webinar

Hands on Postgres 18: Async I/O, B-tree Skip Scan, UUIDv7, and More

With the release of PostgreSQL 18 around the corner (the first release candidate was released today), now is the time to discuss the significant changes that directly influence performance at scale.

From the introduction of asynchronous I/O, which changes how Postgres interacts with the disk both in the cloud and on-premise, to new planner optimizations that can make queries faster. Indexing capabilities also expand with B-tree Skip Scan, while the EXPLAIN command and statistics tables gain new information for tuning production workloads.

New Video Series

Postgres in Production: Episode 1
Different Kinds of Bloat and How to Fix It (Part 1)

We are excited to launch Postgres in Production, a new video series hosted by Ryan Booz, a longtime Postgres community member and Solutions Engineer at pganalyze. Each episode is designed to help you understand the real issues that come up in production environments and show you step by step how to address them.

Ryan will start with foundational concepts and then move into live demos on a real Postgres database, so you can apply what is discussed easily to your own database. The goal is to equip you with practical knowledge that helps you run Postgres reliably and efficiently at scale.

In Episode 1, Ryan covers one of the most common and persistent challenges: bloat. You will learn:

• What bloat is and how it affects performance

• How VACUUM maintains your tables over time

• Which configuration settings matter most for efficiency

• How to detect bloat using views like pg_stat_user_tables and extensions like pgstattuple

• A demo showing the real impact of table bloat

New Customer Story

How Autotrader UK Became a Platform Engineering Leader with Google Cloud Postgres & pganalyze

From its early days as a print classifieds magazine to becoming a digital-first business serving millions, Autotrader UK has always embraced change. Their latest evolution is an ambitious internal app delivery platform on Google Cloud, where more than 300 developers run hundreds of production-grade Postgres databases without relying on a centralized DBA team.

The platform team knew this autonomy came with risk. Without the right guardrails, issues like bloat, unexpected autovacuum behavior, and query regressions could quietly erode performance. By weaving pganalyze directly into their delivery platform, they gave every developer the visibility and confidence to solve performance problems at the source, turning what used to be black box mysteries into actionable insights.

Read how Autotrader UK cut critical imports from nearly a week to under 24 hours, scaled developer ownership safely, and built a model for platform engineering that keeps Postgres fast and reliable at scale.

Events

Upcoming PostgreSQL & Database Events

The fall conference season is here, and the pganalyze team will be out in full force. Don't forget the Postgres for All virtual meetup next week, where we'll discuss the new pg_stat_plan extension.

Additionally, we'll be at PGConf NYC (Sept. 29 – Oct. 1), quickly followed by PGConf EU in Riga (Oct. 21-24), where we'll have a booth and several talks at both. After that, join us at the PASS Data Community Summit in Seattle (Nov. 17 – 21) for more conversations and a pre-conference workshop. 

Product Updates

What's New in pganalyze

Earn a $25 Gift Card for a Review on G2

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

Hi Newsletters,

Webinar Recording: Detect and Fix Slow Postgres Queries with pganalyze Query Advisor

Missed the live session? You can now watch the recording on demand to see how Query Advisor, a purpose-built query optimization workflow coming soon to pganalyze, helps detect and fix slow Postgres queries using your real query plans.

We walk through how it works, share real-world examples (including a 1000x improvement), and demo how you can confidently rewrite queries with side-by-side plan comparisons in pganalyze Workbooks. You can reply to this email if you haven't already expressed interest in the early access program, which starts next week for cloud customers.

Postgres Performance Workshops for Teams New to pganalyze

We’re now offering dedicated Postgres Performance Workshops to help engineering teams confidently tune their own database. In this hands-on session, you’ll learn how to:

• Rewrite slow queries with actionable guidance

• Minimize indexing overhead

• Set up alerting and maintenance workflows for production

Workshops are open to those with a significant Postgres footprint and new to pganalyze. Availability may book up fast, so request your spot today.

Brush Up on Query Tuning Fundamentals with Lukas' Talk from Posette

Watch this 20-minute talk, where Lukas shares what he’s learned tuning slow Postgres queries over the years. You’ll get a quick refresher on EXPLAIN ANALYZE, then dive into his iterative process for identifying the root cause of slowness, including common planner pitfalls and how to evaluate alternate plans with tools like pg_hint_plan.

Upcoming PostgreSQL Community Events

We’re excited to be participating in several Postgres community events throughout 2025! Ryan's talk is coming up quickly at PGDay Austria, the new pg_stat_plan extension is being featured at the Postgres for All virtual meetup on Sept. 11th. And in November, Lukas & Ryan will be leading a pre-conference workshop at PASS Summit on how to port your SQL Server tuning skills to Postgres. Hope to see you there!

Product updates

• Optionally support PostGIS in Index Advisor for Enterprise Server deployments
  
  • Due to PostGIS licensing restrictions, PostGIS is not bundled with pganalyze Enterprise Server, but this release now allows adding in the required files to a custom image
  • Reach out to us via a support ticket for details
• Update bundled collector from 0.65.0 to 0.66.2
  • Note that some of the new functionality (e.g. pg_stat_io tracking) is not yet enabled in this Enterprise Server release, as this update is mainly aimed to pull in collector-side bugfixes.
• Enforce correct search_path for internal corrections 
  
  • This ensures the partition creation changes in 2025.03.3 do not cause problems on systems where a "pganalyze" user is used, and a "pganalyze" schema is present
  • Resolves errors like "no partition of relation ... found for row" that caused missing data in some cases
• Immediately create internal table partitions on boot
• Log details when there are partition creation problems
• Dependency security updates and other routine security updates to packages in the base image

Earn a $25 Gift Card for a Review on G2

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

Hi Newsletters,

Introducing Query Advisor: Detect and Fix Slow Postgres Queries with pganalyze

Tuning slow queries is one of the most impactful ways to improve PostgreSQL performance, but finding and fixing inefficiencies is often manual, error-prone, and time-consuming. pganalyze Query Advisor changes that by introducing the first end-to-end query optimization workflow purpose-built for PostgreSQL, bringing automated detection of common query plan problems, actionable rewrite recommendations, and impact tracking together in a single tool.

Whether you’re a DBA managing hundreds of Postgres instances, a platform engineer looking to scale reliably, or a developer wanting to ship performant code, Query Advisor gives you a faster, more confident path to optimized queries.

PGConf.dev Recording: Tracking Plan Shapes Over Time with Plan IDs & pg_stat_plans

In case you missed it, we recently shared a behind-the-scenes look at a new open-source extension we’re building to capture per-plan statistics, which is similar to Aurora’s aurora_stat_plans, but designed to work anywhere you run Postgres.

This extension builds on pg_stat_statements to track when plans change and how different execution plans for the same query perform over time. Compared to auto_explain, which is great for catching outliers, this gives a complete picture of all the plans in use, with minimal overhead that makes it practical for production.

We talked through our early prototype at PGConf.Dev, and the recording is now available. Check it out to see how we’re shaping this extension ahead of the Postgres 18 release — and what it could mean for understanding your query performance at an entirely new level.

pganalyze Recognized by G2 for Fast Implementation and Estimated ROI

Thanks to your support, we just landed in G2’s Summer 2025 database monitoring reports for the first time ever, earning badges for Best Estimated ROI in the Results Index and Fastest Implementation in the Implementation Index.

We asked in our last newsletter for your help to get us there, and you delivered. Huge thanks to everyone who shared reviews and feedback. It means a lot, and we’re always up for hearing more. Check out our interactive product tour to learn more about the features delivering ROI for your database.

Upcoming PostgreSQL Community Events

We’re excited to be participating in several Postgres community events throughout 2025! We're wrapping up the week here in Philadelphia for RailsConf, and Ryan from our team will be speaking at PGDay Austria.

We’re looking forward to more great conversations and knowledge sharing at upcoming events across the Postgres community!

Product updates

• Amazon Aurora: Add support for Postgres 17 when aurora_stat_plans is enabled.
  • Previously, Amazon Aurora users on Postgres 17 that also had plan statistics enabled were unable to collect query statistics due to a column "blk_read_time" does not exist error.
• Log Insights: Improve parsing Heroku auto_explain logs using JSON format.
  • Support newlines in the middle of the EXPLAIN query with the JSON format.

• Add additional LDAP authentication settings for SSL certificate verification
  • Adds LDAP_ENCRYPTION_CA_FILE to set the path to CA file to validate server certificate (use a volume mount to provide this file to the container)
  • Adds LDAP_ENCRYPTION_VERIFY_MODE to set whether to verify the server certificate ("peer", the default) or not ("none")
  • Note that LDAP_ENCRYPTION_VERIFY_MODE=none restores the historic behavior of not verifying the server side certificate, as it was before v2024.10.0.
• Update bundled collector from 0.65.0 to 0.66.2
  • Note that some of the new functionality (e.g. pg_stat_io tracking) is not yet enabled in this Enterprise Server release, as this update is mainly aimed to pull in collector-side bugfixes.
• Improve reliability of partition creation for internal statistics tables
  • This replaces the mechanism that runs in the background to create daily partition for the internal database, with a more reliable method that runs directly in the statistics snapshot workers
  • Resolves errors like "no partition of relation ... found for row" that caused missing data in some cases
• Improve LDAP self-test to accurately report SSL connection problems
• Connection tracing: Don't show incorrect information from newer backends
• Index Advisor: Don't fail with "internal error" in certain cases when handling queries involving 2 or more tables
• Dependency security updates and other routine security updates to packages in the base image

Earn a $25 Gift Card for a Review on G2

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

Hi Newsletters,

Upcoming Webinar: Walk Through The Latest pganalyze Features for Tuning Postgres

Does your Postgres database feel like a black box when a performance issue hits? Are you prepared for the next high-traffic event? Join us on Wednesday, April 16 for a deep dive into the latest pganalyze features that make it easy to tune slow queries, identify plan regressions, and keep your Postgres environment running at its best.

In this webinar with Q&A, we’ll walk through specific use cases that demonstrate how pganalyze can streamline slow query analysis, help you select the right indexes, and provide insights into critical parts of Postgres. By the end of the webinar, you’ll have a clear, hands-on understanding of how to leverage pganalyze’s latest offerings to elevate your database team’s performance.

Postgres vs. SQL Server: B-Tree Index Differences & the Benefit of Deduplication

Curious how PostgreSQL and SQL Server really compare when it comes to indexing? In our latest blog post, we break down the structural differences between B-Tree implementations, explore how PostgreSQL’s deduplication feature reduces index size by up to 90%, and share real benchmarks from both systems. Whether you’re planning a migration or tuning performance, this side-by-side comparison highlights what matters most for engineers working with production databases.

Webinar Recording: Proactive Postgres Practices to Prevent Performance Bottlenecks

Missed our recent webinar? The full recording is now available to watch on demand, as well as the presentation slides and resources. In this session, we covered practical strategies for staying ahead of performance issues, including how to identify early warning signs, optimize queries before they become bottlenecks, and make the most of Postgres monitoring tools. Whether you're running a small deployment or managing production at scale, you'll come away with actionable insights to keep your database fast and reliable. 

Upcoming PostgreSQL community events

We’re excited to be taking part in these Postgres community events in 2025. Reply to this email if we'll see you there!

Product updates

• Improved SQL editor in Query Tuning Workbooks (beta) with syntax highlighting and basic auto-completion
• Highlight parameter names in query when editing their name
• EXPLAIN Comparison: Improve ellision of overlong text

• Index Advisor: Added support for analyzing queries referencing names with tildes (e.g., table names, index names)
  • Fixes previous issue where such queries caused the Index Advisor to fail

• Email validation is now required during application signup and email updates

  • Accounts must be confirmed via a link before activation or applying email changes

  • Users invited via sharable link will now be prompted to send a confirmation email before accessing the pganalyze application

• Improve loading times of per-query query tags page
• When first logging in, redirect to last-visited organization
  • This makes it easier to use pganalyze when working with different organization (previously the first organization would always open)
• Add in-app option to retry failed subscription payments
• New documentation page: PII filtering
  • This new page in the pganalyze docs explains in detail the impact of collector PII Filtering settings and which data they affect

pganalyze Enterprise Server v2025.03.1 & v2025.03.2

• These are patch releases on top of v2025.03.0
  • These releases does not have any new database migrations, and are easy to apply (or rollback) if you are already on v2025.03.0
  • If you're upgrading from a release before v2025.03.0, be sure to read the earlier release notes, and follow the recommended upgrade steps

Earn a $25 Gift Card for a Review on G2

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

Hi Newsletters,

Upcoming Webinar: Proactive Postgres Practices to Prevent Performance Bottlenecks

As your PostgreSQL database grows, slow queries, bloat, and connection limits can quietly build up, leading to unexpected performance issues. 

In this webinar, we’ll walk through key strategies for staying ahead of these challenges, from using pg_stat_io and pg_stat_statements to detect early warning signs to managing bloat with tools like REINDEX and pg_repack.

We’ll also discuss how tuning checkpoint settings can improve Write-Ahead Logging (WAL) performance and why analyzing Postgres logs is essential for catching slow queries and deadlocks before they become major issues. Join us to learn practical, proactive techniques to keep your database efficient and reliable.

How Notion Runs PostgreSQL at Scale on Amazon RDS with pganalyze

Rapid growth can expose hidden bottlenecks in your database infrastructure. For Notion, the explosive surge in users led to performance issues on their Postgres database on Amazon RDS. Facing slow queries and complex scaling challenges, they turned to pganalyze for deeper insights.

The result? Improved query performance, streamlined indexing, and a significant reduction in reliance on infrastructure specialists. By providing engineers with the right tools, Notion accelerates incident resolution and proactively tunes Postgres, catching issues before they impact production. Read the full story from our chat with Arka Ganguli & Ben Hughes.

Upcoming PostgreSQL community events

The Postgres community is kicking off 2025 with some great events, and we’re excited to be taking part.

In addition to PGConf.dev and the virtual POSETTE conference, PGDay Chicago has released its full schedule. If you’re attending, be sure to check out Keiko's talk on practical query tuning.

Stuck on a Slow Query? Sign Up for Office Hours

Struggling with a slow or complex Postgres query? Sign up for a 1-hour office hour session with Lukas and get hands-on query tuning help. Whether you’re troubleshooting performance bottlenecks, optimizing indexing strategies, or trying to understand execution plans, this is a great opportunity to get expert insights tailored to your workload.

Product updates

• See the release notes for full details

• Google Cloud SQL: Support IAM Authentication
• Start collecting and report pg_stat_statements_info stats
• Multiple bugfixes, see full release notes

• Parameter handling
• Add ability to merge parameter names
• Support all Postgres types for parameter type selection
• Variants
• Correctly delete temporarily created variants
• Add max_parallel_workers_per_gather to planner settings
• Remove EXPLAIN prefix from a provided input query if exists
• Fix unintentional normalization of partition names in plans

• Include EXPLAIN node relation or function name in comparison view
• Add Buffers as a metric for plan comparison  
• Fix comparison of CTE Scan nodes 
• Improve detail text color in comparison view

• Add Postgres 17 in-app documentation

• Index Advisor: Fix handling of tables that use domain columns

• Fix bug when updating the VAT ID on file for billing information

Earn a $25 Gift Card for a Review on G2

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

Hi Newsletters,

Comparing EXPLAIN plans is hard (& how pganalyze does it)

In this post, Maciek walks through EXPLAIN plan fundamentals, why it’s helpful to compare EXPLAIN plans and the challenges presented by existing tools such as EXPLAIN itself, and how that influenced our product roadmap at pganalyze to create a text-based diff interface, which we first rolled out as part of an earlier beta release. Now, we’re expanding that same functionality to the EXPLAIN plan list under query details and adding a new comparison metric, buffers.

Replacing Oracle Hints: Best Practices with pg_hint_plan on PostgreSQL

If you are moving from Oracle Database to PostgreSQL, you are likely accustomed to using hints to optimize queries. Unlike Oracle, hints are not built-in to Postgres, but there is a community-built extension called pg_hint_plan. It may be tempting to replicate every hint with a pg_hint_plan equivalent, but in this post, we'll walk through why that may be overkill, how to map Oracle hints to pg_hint_plan equivalents, and how to debug and test when to use hints in your Postgres environment.

Upcoming PostgreSQL community events

We're excited to be sponsoring both PGDay Chicago and PGConf.dev this year. The schedules haven't been released yet, but it's a great time to secure your ticket. More news to come, including talks by Lukas and Keiko from our team at the events. We hope to see you there:

• PGDay Chicago: early bird tickets on sale until February 20th
• PGConf.dev: register here with student discounts available

Subscribe on YouTube

We publish weekly videos on Postgres, our conference talks, tutorials, product walk-throughs, and more.

Product updates

• Support extracting parameters from queries that re-use parameter references
• Add ability to rename parameter names
• Allow changing all planner-related settings when creating a query variant
• Allow editing parameter settings for new parameters added when creating a variant
• Enable going back to earlier steps (and discarding progress), e.g. to edit the query after an EXPLAIN ANALYZE failure
• Support editing variant names and descriptions after variants were created

• Automated EXPLAIN: Link to plan comparison from per-query EXPLAIN plan sample list
• Support parsing WindowAgg node with Run Condition with text format EXPLAIN result

• Support custom extension schemas
• This ensures query analysis can complete when extension data types are utilized where the extension is installed in a custom (i.e. non "public") schema.
• Fix edge cases where query analysis did not succeed on Postgres 16 or 17
• Fix highlight of menu item when some tabs are selected 

• Active query alert: Ignore connections from pg_repack - Fix bug with setting up new Slack connections for alerting (introduced in December 2024)

• Organization Dashboard: Show inactive servers if no active servers present

• The Organization Dashboard includes a list of servers, with a toggle for showing servers with no recent snapshots recorded. This sets the toggle to on by default if no servers have recent snapshots.

• Improve main menu layout for users who belong to many organizations

• Server Settings: Show pg_stat_statements info data in Debug Info panel when available

• These stastistics will be shown starting with the next collector release

• We have retired the pganalyze demo hosted at demo.pganalyze.com

• This demo had recurring maintenance issues and only showed a pgbench workload, which is not representative for how pganalyze is used on production systems

• For a self-directed demo of pganalyze visit our product tour instead (based on real-world examples from our own databases), or reach out to our team for a demo call.

Earn a $25 Gift Card for a Review on G2

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

Hi Newsletters,