SEPTEMBER 2026

Postgres 19 webinar & Bay Area meetup, Postgres monitoring for SQL Server DBAs, and the pg_stat_statements deep dive finale

Hi there,

Postgres usually releases in late September, but this year's Postgres 19 release is running a bit later, with an expected release in late October. The main reason: during the beta cycle, several key features originally planned for the release had to be reverted, including the SQL/PGQ property graph support, MERGE/SPLIT for partitions and online enabling of data checksums. Other changes have stayed in, including the new pg_plan_advice module, WAIT FOR LSN, autoscaling of I/O workers and the EXPLAIN ANALYZE timing improvements that lower the cost of measuring where a query spends its time. We'll walk through what is expected to ship, what was reverted and why, and how to test the release against your own workload in a live Postgres 19 webinar on Thursday, October 8 at 10am PT. Register here.

If you're in the Bay Area, you can get the in-person version first. Elizabeth Christensen and I are talking Postgres 19 at the San Francisco Bay Area PostgreSQL Meetup on Thursday, September 24, hosted at the Snowflake office in Menlo Park. Postgres turns 30 this year, so there will be cake. Come say hi!

If you're coming to Postgres from SQL Server, the surprising part of monitoring isn't reading the data. It's that most of it isn't recorded until you say so. Query Store captures every execution whether or not you were thinking about it. In Postgres, the log line for a lock wait or a temp file spill either got written when it happened, or it didn't, and nothing recovers it afterwards. Ryan's new article, Postgres Monitoring for SQL Server DBAs: Statistics and Logs 101, maps the day-to-day questions you'd take to DMVs and Query Store onto their Postgres counterparts (two are views, seven are the log) and walks through the decisions to make up front: enabling pg_stat_statements correctly, where logs go, what log_line_prefix should include, and which log settings to turn on.

Ryan also wraps up his deep dive into pg_stat_statements with Part 7, the final episode. We show two ways to get a usable window during an incident: diff two snapshots taken a minute apart, or reset the statistics and watch what fills back in. Ryan also makes the case for checking pg_stat_activity first, since pg_stat_statements only records a query once it has finished.

And on the community side, we're a Platinum Sponsor of PGConf.EU in Valencia, October 20 to 23. I'm co-organizing the PostgreSQL Observability Summit there, a half-day community event on what unified Postgres observability looks like across on-premise, cloud and Kubernetes, and I'll give a short talk on the stack-based instrumentation proposal for Postgres. Fittingly for this issue, Sami Imseih opens the summit with "pg_stat_statements: Scaling for the Future". If you're in Valencia, we'd be happy to meet up!

As always, you can find the complete list of pganalyze product updates, including an important security patch for pganalyze Enterprise Server, at the end of this newsletter.

Upcoming Webinar

Postgres 19 in practice: what shipped, what got cut, and how to test it

On Thursday, October 8 at 10am PT, Lukas walks through what is currently expected to ship for Postgres 19 (as of beta4 / RC1) and what it means for running it in production: the features that made it, the ones that were reverted late in the cycle and the reasoning behind those decisions, how to test a release candidate against your own workload before general availability, and how the way Postgres gets developed is changing with the use of AI tools in authoring and code reviews.

New Article

Postgres Monitoring for SQL Server DBAs: Statistics and Logs 101

Coming from SQL Server, you expect the data for query tuning to already be there: DMVs, Query Store, Extended Events. Postgres records most of it only when you ask it to, and much of it lives in the log rather than in a view. Ryan Booz maps the day-to-day questions (worst queries, lock waits, actual plans, temp file spills) to where the answer lives in each system, then walks through the decisions to make up front: enabling pg_stat_statements correctly, where logs go, what log_line_prefix should include, and which log settings to turn on before your next incident.

Postgres in Production

Deep Dive into pg_stat_statements (Part 7): Finding Slow and Expensive Queries

In the final episode of the Postgres in Production deep dive series, Ryan Booz finally queries pg_stat_statements in practice. However, he actually starts with pg_stat_activity, because pg_stat_statements only records a query once it has finished. Ryan then shows two ways to get a usable window out of cumulative counters: diffing two snapshots, or resetting and re-querying.

From there it is about what you sort by: total time finds the biggest workload, calls finds the query running most often, mean time finds the one that is slow on every run, and temp blocks written finds what spills past work_mem. He closes with what to look for in a monitoring tool, including how many tools are already querying pg_stat_statements on your server.

Community News

Upcoming Events

Postgres 19 In Person in Menlo Park, Thursday, September 24, 6 to 8pm PT. Elizabeth Christensen and Lukas Fittl walk through Postgres 19 at the San Francisco Bay Area PostgreSQL Meetup, hosted at the Snowflake office (135 Constitution Drive, Menlo Park): the new features, including pg_plan_advice, the features that were reverted and why, how to test the release, and how Postgres development is changing. pganalyze is bringing food and drinks, and since Postgres turns 30 this year there will be cake and stickers. RSVP on Meetup. If you're nearby, come say hi!

Postgres Summit US, New York, September 30 to October 2. pganalyze is a Gold sponsor. Lukas and Maciek present "Optimizing Postgres Queries with Visualizations and LLMs", and Ryan co-teaches the three-part Beginner Postgres Workshop with Devrim Gündüz. If you're there, come say hi!

PGConf.EU 2026, Valencia, October 20 to 23. pganalyze is a Platinum Sponsor this year, and Lukas is co-organizing the PostgreSQL Observability Summit, a half-day community event on the last conference day. The lineup includes Sami Imseih on "pg_stat_statements: Scaling for the Future", Gülçin Yıldırım Jelínek on what's new with monitoring in Postgres 19, and Lukas on stack-based instrumentation for Postgres, followed by a panel.

KubeCon + CloudNativeCon North America, Salt Lake City, November 9 to 12. pganalyze is a Silver sponsor this year. If you run Postgres on Kubernetes, come find us at booth 324 in Hall 4 and talk through finding slow queries across your clusters.

Product Updates

What's New in pganalyze

Index Advisor

• Show an error message on the per-table run page when Index Advisor could not run due to an internal error. Previously this incorrectly suggested picking a different configuration for the Indexing Engine.

pganalyze MCP Server

• Allow connecting through Composio

Log Insights

• New setup wizard for Neon and Supabase
• Support for new event types (value out of range, object does not exist, row-level security violation, view check option violation, cannot modify view, SQL/JSON errors, partitioning errors, object already exists, wrong object type, and skipping maintenance due to permissions), and the "Autovacuum" category is renamed to "Maintenance"

Other improvements

• API Access: support naming API keys
• Billing: plan changes now apply only after the payment succeeds, including 3D Secure confirmation. A failed or abandoned payment leaves the subscription unchanged.

pganalyze Enterprise Server v2026.08.1, v2026.05.1, v2026.02.1, v2026.01.1, v2025.03.6

• This is a patch release containing an important security fix for the pganalyze application (already applied for cloud-based customers), upgrading is highly recommended
• Upgrade to the patch release that is closest to your current version to keep it simple - releases that only bump the last digit don't require any database migrations when upgrading (just an image update)
• The v2026.08.1 patch release includes additional bugfixes and minor feature improvements, as well as the latest collector release

pganalyze-collector 0.74.0

• Stop supporting Amazon Linux 2, RHEL 7, Debian 11 (Bullseye) and Ubuntu 20.04 (Focal), which are end of life; the minimum glibc is now 2.28 (RHEL-based) and 2.34 (Debian-based)
• Allow disabling WebSocket uploads via the new api_disable_websocket setting, as an interim workaround for environments where the WebSocket connection can't be used at all
• WebSocket: add a 30 second timeout for opening connections, and avoid full snapshots and test runs stalling when the endpoint is unreachable (fall back to HTTP after at most 10 seconds)
• Support the PGA_API_SYSTEM_ID_FALLBACK and PGA_API_SYSTEM_TYPE_FALLBACK environment variables, matching the existing config file settings

pganalyze-collector 0.73.0

• AWS: Cache RDS describe results and API sessions per AWS account to avoid rate limits when monitoring hundreds of servers, and correctly detect the 256 TB max storage size for new Aurora versions
• Avoid disrupting snapshot collection when uploads are slow or delayed: snapshots are now queued to the upload routine with a buffer, so collection continues and a full queue is visible as an explicit error in the logs
• WebSocket: detect dead connections via write deadlines and ping/pong, so a silently dropped TCP session no longer stalls uploads for 15+ minutes before falling back to HTTP
• Improve statistics diffing on restarts and failovers: the collector records which instance and postmaster it connected to and resets the statistics reference point when that changes
• Log Insights: add classifications for additional Postgres log events, improve log line matching for existing ones, and rename the "Autovacuum" log category to "Maintenance"
• Fix race conditions affecting skip_if_replica reloads and the Workbooks Collector Workflow, and ensure stalled 1 minute stats collection can't delay full snapshots