Hi there, Postgres 18 Beta 1 is now available. We break down the new async I/O feature, share benchmark results, and highlight what it means for performance in production.
Welcome to the April 2025 edition of the pganalyze newsletter!
Our team had a busy month connecting with the Postgres community at PGDay Chicago and gathering in San Francisco for a team offsite.
Some big news to start: Postgres 18 Beta 1 was released today, and we’ve published a deep dive on asynchronous I/O (AIO)—the result of a multi-year effort to introduce a major architectural shift in Postgres I/O. We explain how it works, compare it to synchronous I/O in benchmarks, and unpack what it means for performance and reliability in production.
If you’ve ever wanted a behind-the-scenes look at how pganalyze works in practice, we also just released a new on-demand webinar showing the product in action.
And one last thing. We’re just 3 reviews away from qualifying for our G2 report category. To help us get there, we’re still offering a $25 reward qualifying reviews.
Check out upcoming events at the end of this email and feel free to reply if you’ll be at any of them. We'd love to say hello in person.
With the release of Postgres 18 Beta 1 today, a multi-year effort is becoming reality: Asynchronous I/O (AIO) is landing in core Postgres.
This is more than a performance tweak: it's a fundamental architectural shift in how Postgres handles I/O. While still limited to reads, AIO opens the door to significant gains in high-latency environments, especially the cloud. Now is the time to test and validate how Postgres 18 behaves in practice before the final release locks in.
In our latest post, we break down:
How AIO works under the hood
The role of the new `io_method` setting
Where we saw 2–3x throughput improvements
What changes for performance tuning and observability
Does your Postgres database feel like a black box when a performance issue hits? Are you prepared for the next high-traffic event? Last month we went on 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. Watch now to gain a clear, hands-on understanding of how to leverage pganalyze’s latest offerings to elevate your database team’s performance.
Fix color of Considered Index icons; previously, this icon did not show the index id unless hovered;
Support extensions installed in pg_catalog schema
Support schemas that include multiline CHECK constraints
Query Tuning Workbooks
Improve mechanism for passing parameters to collector workflow
This adjusts the collector workflow to use prepared statements with parameter values passed separately, instead of inlining them on the server side. This improves accuracy in some edge cases.
Allow adding parameter sets after workbook creation
Additional parameter sets can now be added on the "Parameter Set" screen of a workbook, for example to expand tests to an additional edge case. The baseline and existing variants then allow recording the additional plans for the new parameter set.
pganalyze Collector v0.66.0
Collect statistics from pg_stat_io (Postgres 16+)
Amazon Aurora: Pick up the correct oldest xmin for Aurora replication
Aurora does not include the correct replication details in pg_stat_replication, so check aurora_replica_status and use the older of the two values to track XminHorizonStandby on the platform
Amazon RDS: Also check monitoring interval for Enhanced Monitoring
Google Cloud SQL: Assume Private IP for IAM authentication-based connections
If the legacy behavior (which connects over Public IP) is required, the new `gcp_use_public_ip` / `GCP_USE_PUBLIC_IP` setting makes the collector connect over Public IP instead
Crunchy Bridge: Fetch all system metrics via API
The collector previously collected some metrics from the container itself, but this has shown to be unreliable due to recent provider changes
Instead, retrieve a more limited set of metrics from the official APIs provided by Crunchy Bridge. Setting an API key per the documentation is required for this to work
Kubernetes: Add ability to use raw environment variables maps in deployment
Better support for running EXPLAIN with pganalyze.explain_analyze helper
Improve warning when collector is paused due to a duplicate already running
Improve error messages when the monitoring user is not properly set up
Remove --no-postgres-(functions|bloat|views) flags to collector
These flags do not have any effect and are very unlikely to be in use
