What's new in pganalyze

When using an API key, server and database lists no longer include databases that were dropped, or that pganalyze only saw referenced in logs (e.g., failed connection attempts). Requesting such a database by ID now returns an authorization error. Both match the behavior in the pganalyze app.

Previously, Log Insights only showed 100 log lines leading up to the selected "focus" timestamp (or the end of the window if no focus was selected). This adds the ability to load log lines older than that 100-line limit.

The Connection Traces view now links to autovacuum runs that are currently in progress. Previously they would show up as <unparsable query> and not provide any additional information.

Previously, upgrading or adjusting a plan took effect before the payment outcome was known, so a failed or abandoned 3D Secure confirmation could leave an unpaid upgrade in place. Plan changes now only apply once the payment (including any 3D Secure confirmation) has completed, and a failed payment leaves the subscription unchanged.

This makes it clear if Index Advisor was not able to run due to an internal error. Previously this would have incorrectly shown a note suggesting to pick a different configuration for the Indexing Engine.

• U141: Value out of range
• U142: Object does not exist
• U143: Row-level security violation
• U144: View check option violation
• U145: Cannot modify view
• U146: SQL/JSON error
• U147: Partitioning error
• U148: Object already exists
• U149: Wrong object type
• A69: Skipping maintenance due to permissions

Previously, tables referenced only inside an aggregate FILTER clause, an aggregate ORDER BY clause, a window definition, a VALUES list, a RETURNING clause, or an ON CONFLICT clause were not detected during query analysis. For affected queries, Index Advisor showed a "relation ... does not exist" error and could not generate index recommendations. These queries are now analyzed correctly and included in Index Advisor.

The Active Query check can now be configured to skip long-running statements that are expected to run without blocking other queries. Two new options are available on the check's configuration page, both off by default:

• "Ignore concurrent CREATE INDEX/REINDEX" skips CREATE INDEX CONCURRENTLY and REINDEX CONCURRENTLY
• "Ignore non-blocking maintenance commands" skips VACUUM (excluding VACUUM FULL) and ANALYZE

Previously collector API keys that were created in the last two years showed an empty "Last Used At" timestamp, making it seem as if the key was not in use, when in fact it was used to send statistics data. This issue was specific to collector API keys and did not affect other API key types.

The Checks & Alerts system has been reworked around the concept of Alert Rules (what triggers an alert) and Alert Destinations (where alert notifications are sent). Alert Rules can be configured to track different Checks, apply to a specific server or all servers in the organization, and target zero or more destination rules.

More changes to Checks & Alerts (including support for server groups, role-based e-mail notifications, and other destination targets) are coming soon.

Learn more in our documentation.

This insight detects joins with an OR condition that spans both joined tables, which prevents Postgres from using an index on either side and forces it to filter after joining, and reports when existing indexes could support rewriting the query as a UNION.

The selection can be reset to defaults with a full-page reload.

This allows configuring the unused index threshold to be significantly higher, to avoid incorrectly flagging indexes that are used e.g. once a year. The default remains at 35 days.

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.

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.

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.

Previously, this could lead to all query performance data being hidden, and the mechanism to choose different statement types being hidden as well. This required manually clearing browser LocalStorage for pganalyze to restore.

The change guards against all statement types being turned off, and automatically turns on SELECT statements for users who may have previously turned off all statement types.

This allows giving more space to more important columns (like query).

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.

Workbooks is now reachable from the side nav at every scope, with a New Workbook button that prompts for a server and database when needed.

When a server group is added to recents in the server dropdown, its server members are now also added for quick access. Additionally, sorting server groups in Dashboard updates the url bookmarks and sharing.

pganalyze now automatically detects server groups based on the Postgres cluster relationship, or when manually setting them in the collector. Server Groups are shown as their own distinct resource in the navigation's server dropdown, Dashboard, Query Performance, and Settings pages. Learn more in the blog post.

Here is an example of the new dashboard for Server Groups that renders clusters as a tree, with counts for open issues and databases:

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._-].

Detects Sort and Hash nodes that fall back to using temporary files because work_mem was too small. 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.

Currently, clicking "Select plans" on a plan comparison page can lead to an error when the already-selected plans have 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).

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.

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.

Invitations now expire after seven days. Invitations can be resent (before or after they expire) which resets the expiration timer.

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.

The right-alignment was accidentally dropped recently.

This allows users to navigate back to a page of sorted results (e.g., in the Query Performance list) and maintain the sort order.

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

Previously, the selected focus timestamp (the highlighted timestamp within the current date range) 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 (whether from the date picker or by dragging on the graph), if the focus timestamp falls within the new range, it remains unchanged. If it does not, it is reset to the value of the end of the range.

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.

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.

Previously the JWT token utilized by pganalyze for GraphQL requests contained a "aud" field set to "null", which can confuse some intermediary proxies. This will now always be set to "pganalyze".

Clients can complete the full OAuth flow (DCR, authorization, token exchange), but the issued tokens are not yet accepted by any endpoint. MCP client authentication will be enabled in a follow-up.

Since when there are no calls to a query, these values cannot be calculated, this was previously displayed in the same way as missing data, which could be confusing. Now we interpolate based on query stats before and after these periods of inactivity.

Before:

After:

The getQueryTagSummaryForQuery resolver has been removed. Query tag summary is now available as a field on QueryType, so you can fetch it via getQueryDetails instead:

getQueryDetails(databaseId: "1234", queryId: "5678") {
  normalizedQuery
  queryTagSummary(startTs: 1767193200, endTs: 1767196800) {
    key
    values {
      value
      count
    }
  }
}

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.

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.

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.

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.

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

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.

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.

Index Advisor now aggregates scan data across all servers in a cluster when generating index recommendations. This provides more accurate recommendations by considering query stats from both primary and replica servers.

A bug in the internal detection of which server is the primary in a cluster may have caused wrong data to show for Index Advisor running on a cluster.

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

In passing, update bundled collector from 0.67.0 to 0.68.1. See the collector changelog for full details.

This allows users to navigate back to a page of filtered results (e.g., in the Query Performance list) and maintain the filtered list.

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.

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

limited seven day retention instead of normal retention.

This fixes some Index Advisor pages that had incorrectly-generated links to the queries involved.

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

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.

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.

Enterprise plans now store 100 days (increased from 30 days) of history for query statistics and table/index statistics. The Scale plan now stores 35 days of history, the Production plan 14 days of history. The date picker interface has been updated to reflect the additional retention time and to allow selecting longer time frames.

This was broken by accident in a recent change related to improving the handling of symbolic time ranges (like "24h").

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.

The Table detail page shows some view information, but it does not show the view SQL and shows some irrelevant information. Some internal links (e.g., from query texts) inadvertently link to the table page even for views, so this improves the experience when following those.

The grid view for displaying EXPLAIN plans in pganalyze is now the default. 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.

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.

Previously, merging or renaming parameters caused a "Failed to create a parameter set" error when query samples are selected as parameter sets.

Now you can resume the upload directly from the overview, instead of having to go to the variant page.

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.

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.

Learn more in the announcement post

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.

• 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

This change helps improve request performance. Note that searching by query text is still fully supported.

This provides better consistency across the app.

As part of the beta testing process, and looking ahead for future navigation changes with the upcoming Query Advisor, we are dropping the "Query Tuning" prefix from Workbooks for clarity. The previous menu item "Query Tuning" has now been renamed to "Workbooks". We are also making this change to support future use cases for pganalyze Workbooks that may not involve query tuning directly, for example testing index changes, etc.

Adds a "What's New" menu item that shows a list of recent user-visible changes to pganalyze.

Previously, when the JSON format view is selected, it was dropping the information like "Planning Time", "Execution Time", "Query Identifier", etc.. With this change, the JSON format view will show all information captured with the auto_explain. If the auto_explain is using a text format, it's converted to the JSON format with the best effort.

When running the upcoming Postgres 18 release, you will see columns marked as NOT NULL on each table's "Columns" tab, as well as the automatically created named NOT NULL constraints on the "Constraints" tab.

For failed payments, customers can either pay within the pganalyze app using "Pay Now" button, or using the external payment page to pay.

Currently, the parameter value exceeding 20 characters is truncated. With a new "Show full values" button, it'll expand the truncated part and show full values when available. Note that the full value still might not be available depending on the log_parameter_max_length setting.

Previously if a query was run by multiple Postgres roles, a duplicate query would exist in pganalyze for each role. Those duplicates are now merged into a single query, making pganalyze easier to use if many roles call the same queries. The call count for each role can be viewed on the Query Tags page when viewing a specific query.

This fixes a problem that could occur on issue detail pages for the New Slow Query check that would cause stats for the associated query to fail to load.

Previously, this icon did not show the index id unless hovered.

Adds syntax highlighting and some auto-completion.

Email validation is now enforced during signup and when updating an email address. A confirmation link must be clicked before the account is activated or the email change is applied. Users invited via a sharable link will be redirected to a page to send a confirmation email.

Previously, when the query is referencing some names (e.g. table names, index names) with tildes, the query analysis was failing and the Index Advisor was unable to process.

Update the Xmin Horizon Check to format full (64-bit) transaction IDs specially. Currently, they are formatted as numbers, but that makes it hard to read the lower 32-bit transaction ID Postgres sometimes uses (e.g., backend_xmin in pg_stat_activity). Instead, separate the lower 32 bits and the "epoch" (the upper 32 bits).

This has no effect if you are a member of only a single organization.

Support 3D Secure authentication when upgrading or changing plans. Additionally, outstanding invoices can be paid directly from the Billing page.

The previous fix did not resolve the issue, and query analysis for these queries was still failing.

Previously, when a query had many associated tags, the Query Tags tab displayed an arbitrary limited subset, typically showing the oldest tags seen within the last 7 days. We now prioritize the most recently seen tags.

Normalization is used in plan fingerprinting, but it should not have affected displayed plans.

Check https://pganalyze.com/product-tour instead in the future.

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.

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.