"Postgres on AWS Best Practices" Recording, New Query Formatter Tool, & pganalyze's AWS Marketplace Launch
Hi there,
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 PostgresQuery 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.
All the best,
Lukas
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.
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.
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
Add support for capturing plan statistics with pg_stat_plans
This supports collecting plan statistics from the new pg_stat_plans extension on Postgres 16+ in addition to Amazon Aurora
Avoid skipping query stats in case of slow query text/schema collection
This reworks how pg_stat_statements data is retrieved, to ensure query statistics are continuously collected at 1 minute intervals, even if the full snapshot collection is slow (e.g. due to query text file size or manytables/indexes)
Improve the correctness of replication/server/backend count metrics
Previously these metrics were collected after potentially slow operations in the full snapshot, causing different collection times instead of staying close to the intended 10 minute interval
GCP Pub/Sub: Allow multiple collectors subscribing to the same topic
This adds the new gcp_pubsub_max_age / GCP_PUBSUB_MAX_AGE setting, default 0, maximum 24 hours. Keeping the age limit low is recommended,10 minutes (gcp_pubsub_max_age = 10m) is a good value to use
If set to a non-zero value, the collector returns a GCP PubSub message that's not for a configured server to the topic (by sending a "Nack" message), allowing a different collector to pick it up. This enables an architecture where one topic can be shared across multiple collectors
However, if the message is older than the max age limit, it is always acknowledged (discarded)
Improve buffer cache connection handling to avoid connection leak
Previously this may have blocked on an unconsumed channel, which could have caused the database connection to stay open longer than planned
Disable buffer cache collection for Aurora Serverless
We've had a report of a Postgres segfault caused by scanning the buffer cache during an Aurora Serverless scaling event, which was confirmed by AWS to be a current Aurora bug. For now collection of pg_buffercache is turned off until a bugfix is available
Helper: Don't require "locate" to determine the pg_controldata path
This fixes cluster ID detection (via the Postgres system identifier) for a typical PGDG-based Debian/Ubuntu install
Prune stray temporary files on collector start
Previously an out of memory crash, typically due to systemd limits, could cause temporary files to stay around and never be deleted
Now the collector will remove such files when it starts back up, avoiding potential disk space issues with the temporary file directory
Collector temporary files are now prefixed with "pganalyze_collector_" to support this functionality, and make identification easier
This setting (currently defaulting to off) can be used to require that the more efficient WebSocket connection method is used for submitting snapshots to the pganalyze server
We intend to migrate fully to WebSockets in the future, and a future collector release will change the defaulf of this setting to true, i.e. require their use by default (with this setting remaining for a while after that as a fallback, until it is fully required)
OTel Log Server: Support receiving JSON log format in addition to Protobuf
This supports using Vector instead of Fluentbit for forwarding log events from a CloudNativePG (CNPG) installation on Kubernetes
With thanks to Rauan Mayemir for the initial contribution of this fix
Log event redaction: Fix off-by-one error when redacting full lines
This caused log lines where the full line should be redacted (as is typically the case with STATEMENT lines when using log filtering) to not be redacted correctly.
Fix nap logic of "--text-explain" to actually wait the configured time
Include database name in warning when pg_stat_statements is out of date
Handle test cancellation correctly during log tests (avoid hangs)
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
