Just in time for the PostgreSQL 19 betas, I'm excited to announce release 1.2 of pg_statviz, the minimalist extension and utility pair for time series analysis and visualization of PostgreSQL internal statistics.

This release adds support for the upcoming PostgreSQL 19:

• pg_statviz now captures the new wal_fpi_bytes counter from pg_stat_wal.
• The PG18/19 I/O worker, effective WAL level, and autovacuum scoring settings are captured in snapshot_conf.
• The release has been tested against 19 beta3, and across the whole PostgreSQL 13 to 19 range.

It also introduces a new blocking locks analysis module:

• Each snapshot now records the number of blocked and blocking sessions, along with a breakdown by lock type (relation, transactionid, tuple, and so on).
• Detection is built on pg_blocking_pids(), so even soft blocks (sessions that are just ahead in the lock wait queue) are counted, not just hard conflicts.
• Storage stays lightweight: table size is independent of how many sessions were involved in the blocking.
• The module produces charts and AI verdicts like every other module, and the deterministic severity floor applies here too: sustained blocking can never be reported as healthy.

Also new is the openai AI provider:

• --ai openai uses the OpenAI API, so the same flag works with OpenAI itself and with any other service or local server that implements that API.
• You can select the endpoint and model with the OPENAI_BASE_URL and OPENAI_MODEL environment variables.
• The openai package has been added to the [ai] extras, and zero-dependency installs remain unchanged.

Finally, this release also updates the default AI models to claude-sonnet-5 for Claude and gemini-3.7-flash for Gemini.

pg_statviz takes the view that everything should be light and minimal. Unlike commercial monitoring platforms, it doesn't require invasive agents or open connections to the database: it all lives inside your database. The extension is plain SQL and PL/pgSQL and doesn't require modules to be loaded, the visualization utility is separate and can be run from anywhere, and your data is free and easy to export. The AI analysis remains fully optional and opt-in: if you don't pass --ai, pg_statviz behaves exactly as before, with no extra dependencies and no calls to anything outside your machine.

• You can download and install pg_statviz from the PostgreSQL repositories or PGXN.
• The utility can also be installed from PyPi; for the AI features use pip install pg_statviz[ai].
• Manual installation is also possible.

LibreDB Studio is an MIT-licensed, self-hosted SQL IDE for PostgreSQL that runs in the browser and deploys as a container or Helm chart.

It is deployed next to the database it manages, as a container, a Helm chart or an npm package, rather than installed on each developer's machine. PostgreSQL is its reference implementation: the provider is built on node-postgres, and the other supported engines follow the patterns established there.

On a PostgreSQL connection the editor uses pooled connections, explicit BEGIN/COMMIT/ROLLBACK transactions with an auto-rollback timeout, and query cancellation through pg_cancel_backend on the tracked backend PID. Schema introspection is written to stay responsive on databases with hundreds of tables: the table tree renders from a first pass while relationships stream in from a second. Monitoring reads the pg_stat_* views, including pg_stat_statements where the extension is installed, and degrades to what the connected role can actually see instead of failing when superuser-only views are unavailable.

The optional query assistant is constrained by the database rather than by prompt text. A run is given the real schema of the connected database before its first turn, so a drafted statement names objects that exist, and read-only runs execute inside BEGIN READ ONLY as a single statement over the extended protocol. Authentication is local accounts or OIDC, with role-based access control in front of every API route.

The current release is 0.12.0. Source, documentation and the PostgreSQL provider reference are at github.com/libredb/libredb-studio and libredb.org.

We have a new architecture on apt.postgresql.org: Loongson loong64, a Chinese processor architecture.

The build host for the architecture is running on a Loongson 3B6000 board provided by the loongfans.cn community.

Bootstrapping the PostgreSQL packages was completed earlier this month and everything is in place to be used via apt.postgresql.org.

The exception is the GIS stack of packages (postgis, pgrouting, mobilitydb, pgsql-ogr-fdw) which are currently still waiting for the next postgis release.

Enjoy, Christoph

Tainan, Taiwan - Sun 16 Aug 2026

powa-archivist 5.3.0

The PoWA team is pleased to announce the release of the version 5.3.0 of powa-archivist, the core extension of the PoWA project.

PoWA (PostgreSQL Workload Analyzer) is a performance tool, compatible with all supported PostgreSQL versions. It allows to collect and aggregate metrics gathered from multiple PostgreSQL instances using various extensions covering all parts of PostgreSQL and provides real-time charts and graphs to help monitor and tune your servers. It also suggest optimizations, like global or per-query index suggestions, to easily improve performances.

• Misc
  • Fix pg19 compatibility with pg19beta2 pg_stat_lock.wait_time datatype change (Julien Rouhaud)

Links & Credits

Thank to the users who reported bugs or submitted patches, they are all cited in the CHANGELOG file and the CONTRIBUTORS file.

powa-archivist is an open project. Any contribution to build a better tool is welcome. You just have to send your ideas, features requests or patches using the github repository at github.com/powa-team/powa-archivist.

Links

• Documentation: powa.readthedocs.io/
• Download: github.com/powa-team/powa-archivist/releases
• Bug tracker: github.com/powa-team/powa-archivist/issues

The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 18.6, 17.11, 16.15, 15.19, and 14.24, as well as the third beta release of PostgreSQL 19. This release fixes 28 security vulnerabilities and over 110 bugs reported over the last several months.

This release skips PostgreSQL 18 versions from PostgreSQL 18.4 to 18.6. 18.5 was not shipped due to a regression.

There are three issues that may require you to take extra steps after updating, which are described in detail below. These issues are related to:

• Parallel GIN index builds
• btree_gist
• ltree

For the full list of changes, please review the release notes.

PostgreSQL 14 EOL Notice

PostgreSQL 14 will stop receiving fixes on November 12, 2026. If you are running PostgreSQL 14 in a production environment, we suggest that you make plans to upgrade to a newer, supported version of PostgreSQL. Please see our versioning policy for more information.

Security Issues

The following security vulnerabilities are closed across in this update release. You can find more details about the vulnerabilities and their affected versions in the links below:

• CVE-2026-6464: psql COPY FROM STDIN early failure processes data lines as psql commands (CVSS v3.1: 8.1)
• CVE-2026-6469: ALTER TABLE ALTER TYPE resets extended statistics ownership (CVSS v3.1: 3.8)
• CVE-2026-6470: Fails to check type USAGE privilege (CVSS v3.1: 4.3)
• CVE-2026-6471: Logical decoding can dlopen arbitrary file (CVSS v3.1: 7.2)
• CVE-2026-14662: tsvector and tsquery undersize allocations, via integer wraparound (CVSS v3.1: 8.8)
• CVE-2026-14663: pgcrypto, for OpenSSL-disabled ciphers, silently encrypts to and decrypts from cleartext (CVSS v3.1: 6.5)
• CVE-2026-14664: Regexp heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14666: Row security caching disregards role modifications (CVSS v3.1: 4.2)
• CVE-2026-14668: ctid type confusion in selectivity estimator discloses derivative of arbitrary read (CVSS v3.1: 8.1)
• CVE-2026-14669: to_char heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14670: plperl tied object heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14671: refint plan cache type confusion executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14672: Observable response discrepancy with non-default scram_iterations provides user existence oracle (CVSS v3.1: 5.3)
• CVE-2026-14673: amcheck does not clear untrusted search path (CVSS v3.1: 3.8)
• CVE-2026-14676: pg_stat_statements heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-14677: 32-bit pltcl and plperl undersize allocations, via integer wraparound (CVSS v3.1: 8.8)
• CVE-2026-14678: pg_trgm picksplit reads past end of buffer (CVSS v3.1: 4.3)
• CVE-2026-14679: Stack buffer overflow in argument match writes 0x0 and 0x1 to server memory (CVSS v3.1: 8.2)
• CVE-2026-14680: Type confusion via "internal" arguments (CVSS v3.1: 8.8)
• CVE-2026-14681: Improper enforcement of GSSAPI encryption when coupled with SSL (CVSS v3.1: 4.2)
• CVE-2026-15741: Expression deparse allows SQL injection via EXTRACT argument (CVSS v3.1: 8.8)
• CVE-2026-15742: fuzzystrmatch writes effectively-arbitrary addresses, via integer wraparound (CVSS v3.1: 8.8)
• CVE-2026-16238: Type confusion in pg_restore_attribute_stats() executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-16239: Type confusion in cursor CLOSE + DECLARE executes arbitrary code (CVSS v3.1: 8.8)
• CVE-2026-16241: ECPG integer underflow can crash the client (CVSS v3.1: 3.8)
• CVE-2026-18024: ascii() function reads past end of buffer (CVSS v3.1: 4.3)
• CVE-2026-18408: psql \unrestrict lets superuser of pg_dump origin server execute arbitrary code in psql client (CVSS v3.1: 8.8)
• CVE-2026-19385: pg_dump heap buffer overflow executes arbitrary code (CVSS v3.1: 8.8)

Bug Fixes and Improvements

This update fixes over 110 bugs that were reported in the last several months.

This specific issue only affects PostgreSQL 14, 15, and 16, but we're highlighting it in the release announcement due to its severity:

• Fix a self-deadlock that could occur while replaying WAL generated by an older minor version. This regression, introduced in the previous set of minor releases, could cause a standby server following a primary running an older minor version to become stuck.

The remainder of issues listed below affect PostgreSQL 18. Many of these issues also affect other supported versions of PostgreSQL.

• Fix parallel GIN index builds to correctly update the table's reltuples value in pg_class. Previously, a parallel worker could report an uninitialized row count, leaving reltuples set to a bogus value (including Infinity or NaN). Such a value can cause autovacuum and autoanalyze to not process the table, and this situation will not self-correct. If you have any tables with GIN indexes, we recommend checking that their reltuples values look reasonable after updating. See the "Updating" section for how to identify and repair affected tables.
• Several fixes to btree_gist, including for NaN handling for float4/float8 that could give wrong answers for columns containing NaN and correct sorting of bit/bit varying values during index building. You may need to reindex btree_gist indexes on float or bit columns after updating. See the "Updating" section.
• Fix an integer overflow in ltree comparisons. ltree values containing more than about 14,653 labels could compare incorrectly, which could present as a corrupt B-tree index. If you use ltree, you may need to reindex affected indexes after updating. See the "Updating" section.
• Fix partition pruning for RANGE-partitioned tables so the DEFAULT partition is no longer skipped in cases where it should be scanned. Previously this could cause rows to be missing from query results.
• Several fixes for partitioned tables that have foreign-table partitions, including when run-time partition pruning determined that some partitions don't need to be scanned, in-flight requests to foreign servers were not always handled correctly, leading to failures.
• Several fixes to RETURNING with OLD and NEW.
• Improve hash join performance when there are multiple join keys and many NULL values.
• Several fixes to the planner that could produce wrong query results, including value IN (array) tests where the array might be empty, and COUNT() window functions that use an EXCLUDE clause or lack ORDER BY.
• Add missing checks for the hashability of equality comparisons on container types (arrays, composite types, and ranges). Without these checks, the planner could choose a hash-based plan that then failed at execution with a "could not identify a hash function" error.
• Fix attaching partitions of indexes that are exclusion constraints, which also fixes dump/restore of partitioned exclusion constraints.
• Fix REINDEX CONCURRENTLY on an index backing a deferred uniqueness constraint, which could cause false constraint-violation reports.
• Restore an index-scan optimization that converts a LIKE or regular-expression exact-match pattern into an equality index condition when the index and expression collations differ.
• Several fixes to jsonpath, including that the @? and @@ operators now correctly raise an error for an undefined variable in the path expression. Previously, because these operators cannot supply variable values, an undefined variable was treated as a JSON null rather than an error, which could also lead to unbounded memory consumption.
• Ensure access is blocked to other sessions' temporary tables, which could lead to silently incorrect results.
• Fix "no empty local buffer available" errors during temporary table access when a large effective_io_concurrency setting could allow a single read stream to consume all local buffers.
• Prevent autovacuum from processing databases in the wrong order (lowest-priority first instead of highest).
• Restore VACUUM's wraparound failsafe mode to use the full shared buffer pool as intended, which had slowed down emergency vacuuming.
• Fix possible incorrect decoding of index tuples during GiST and SP-GiST index-only scans, which could emit corrupted data.
• Fix a race condition in conflict detection under SERIALIZABLE isolation. A conflict could be missed when examining an initially-empty btree index, allowing conflicting transactions to commit and breaking serializability.
• Fix WAL logging of operations that clear bits in table visibility maps. This could lead to producing incorrect incremental backups or potentially leaving torn-page writes uncorrected.
• Fix logical decoding of empty prepared transactions. A prepared transaction with no decodable changes could send COMMIT PREPARED or ROLLBACK PREPARED to the output plugin with no preceding PREPARE, which breaks replication for the built-in subscriber.
• Several fixes to libpq, including ensuring it drains all pending bytes from the SSL or GSS decryption buffer when reading data, avoiding cases where a client waits for data that has already arrived.
• Fix pg_createsubscriber to clean up objects left on a publisher after failure, including a replication slot.
• Fix pg_restore with --statistics or --statistics-only so that, when combined with other selective-restore options such as --schema, it restores the expected items, matching the behavior of pg_dump.

This release also updates time zone data files to tzdata release 2026c, in which Alberta (America/Edmonton) will be on year-round UTC-06 (effectively, permanent DST) beginning in November 2026. This release assumes that their TZ abbreviation will be CST from that time forward (though this could change). It also reflects that Morocco (Africa/Casablanca) will move to permanent UTC+00, without daylight saving transitions, on September 20, 2026.

Updating

All PostgreSQL update releases are cumulative. As with other minor releases, users are not required to dump and reload their database or use pg_upgrade in order to apply this update release; you may simply stop PostgreSQL and update its binaries.

If you have any tables with GIN indexes, we recommend checking their reltuples values after updating. A prior bug in parallel GIN index builds could have left reltuples set to a bogus value (including Infinity or NaN) that prevents autovacuum and autoanalyze from ever processing the table. The following query lists the tables that have a GIN index, along with their current reltuples:

SELECT DISTINCT t.oid::regclass, t.reltuples FROM pg_class t JOIN pg_index i ON t.oid = i.indrelid JOIN pg_class ic ON i.indexrelid = ic.oid WHERE t.relhasindex AND ic.relam = 2742;

For any table whose reltuples value looks incorrect, run ANALYZE on it (or create another index) to reset the value.

If you use btree_gist, you should reindex btree_gist indexes on float4 or float8 columns that might contain NaN values, as well as btree_gist indexes on bit or bit varying columns, for example:

REINDEX INDEX your_index_name;

If you use ltree and have btree indexes over ltree values with very many labels (more than about 14,653), you should reindex those indexes, since they may be corrupt, for example:

REINDEX INDEX your_index_name;

Users who have skipped one or more update releases may need to run additional post-update steps; please see the release notes from earlier versions for details.

For more details, please see the release notes.

A Note on the PostgreSQL 19 Beta

This release marks the third beta release of PostgreSQL 19.

In the spirit of the open source PostgreSQL community, we strongly encourage you to test the new features of PostgreSQL 19 on your systems to help us eliminate bugs and other issues. While we do not advise you to run PostgreSQL 19 Beta 3 in production environments, we encourage you to find ways to run your typical application workloads against this beta release.

Your testing and feedback helps the community ensure that PostgreSQL 19 upholds our standards of delivering a stable, reliable release of the world's most advanced open source relational database. Please read more about our beta testing process and how you can contribute:

https://www.postgresql.org/developer/beta/

Upgrading to PostgreSQL 19 Beta 3

To upgrade to PostgreSQL 19 Beta 3 from an earlier version of PostgreSQL, you will need to use a strategy similar to upgrading between major versions of PostgreSQL (e.g. pg_upgrade or pg_dump / pg_restore). For more information, please visit the documentation section on upgrading.

Changes Since Beta 2

Fixes and changes in PostgreSQL 19 Beta 3 include:

• Revert GROUP BY ALL.
• Several fixes for the new FOR PORTION OF temporal table syntax.
• Several fixes for the new logical replication sequence synchronization feature, including a race involving REFRESH SEQUENCES.
• Fix an "unexpected logical decoding status change" error that could occur when logical decoding is activated concurrently.
• Fix issues around ownership changes for subscriptions.
• Fix wrong query results from postgres_fdw when pushing down an array comparison such as field = ANY($1) that involves an implicit type coercion.
• Fix a crash during foreign-key checks involving a nullable UNIQUE constraint.
• Fix pg_plan_advice parsing of underscores in numeric literals.
• Fix a missing FORMAT clause when deparsing JSON_ARRAY(query).

Please see the release notes for a complete list of new and changed features:

https://www.postgresql.org/docs/19/release-19.html

Testing for Bugs & Compatibility

The stability of each PostgreSQL release greatly depends on you, the community, to test the upcoming version with your workloads and testing tools to find bugs and regressions before the general availability of PostgreSQL 19. As this is a Beta, minor changes to database behaviors, feature details, and APIs are still possible. Your feedback and testing will help determine the final tweaks on the new features, so please test in the near future. The quality of user testing helps determine when we can make a final release.

A list of open issues is publicly available in the PostgreSQL wiki. You can report bugs using this form on the PostgreSQL website:

https://www.postgresql.org/account/submitbug/

Links

• Download
• Release Notes
• Security
• Versioning Policy
• Beta Testing Information
• PostgreSQL 19 Beta Release Notes
• PostgreSQL 19 Open Issues
• Submit a Bug
• Donate

If you have corrections or suggestions for this release announcement, please send them to the pgsql-www@lists.postgresql.org public mailing list.

What plx is

plx is a PostgreSQL extension that lets you write stored functions and triggers in the dialect you already know (the current set is listed below). When you run CREATE FUNCTION, plx transpiles the body to plpgsql and stores that plpgsql in pg_proc.prosrc. At run time the function is executed by PostgreSQL's own plpgsql interpreter. There is no separate language runtime loaded into the backend, and nothing new to run in production.

The front end is dialect-pluggable, and the set of dialects is growing. The dialects available today are:

• plxruby: a Ruby dialect.
• plxphp: a PHP dialect.
• plxjs: a JavaScript dialect.
• plxpython3: a Python dialect.
• plxcobol: a COBOL dialect (ISO/IEC 1989:2023).
• plxplsql: an Oracle PL/SQL dialect.
• plxts: a TypeScript dialect (plxjs plus type annotations).
• plxtsql: a Transact-SQL (SQL Server) dialect.
• plxgo: a Go dialect.

Every plpgsql statement type is reachable from every dialect. See doc/PARITY.md for the construct matrix. The language names carry a plx prefix, so the extension coexists with the native PL/Ruby and PL/PHP languages in the same database.

Why it exists

PostgreSQL rewards moving logic into the database: triggers, constraints, set-returning functions, and cursors all run closest to the data. The standard way to write that logic is plpgsql. plpgsql is fast and trusted, but its syntax is unfamiliar to developers who spend their day in Ruby, PHP, JavaScript, or Python, and that unfamiliarity is often enough to keep logic in the application tier where it does not belong.

The usual alternative is an untrusted procedural language such as plpython3u or plperlu. Those give you a familiar syntax, but at a cost: they load a full language interpreter into the backend, most are untrusted and therefore superuser-only, and every row they touch is marshalled across an SPI boundary into the interpreter's own data structures.

plx takes a different position. A new language surface does not require a new execution engine. plx changes only the syntax you write, not what runs:

• It is still plpgsql. The stored function body is plpgsql, executed by the plpgsql handler. You get plpgsql's performance and its safety as a trusted language, with no interpreter loaded into the backend.
• Nothing is hidden. The generated plpgsql is stored in pg_proc.prosrc, where you can read exactly what will run. plx embeds the original source as a comment so the function is idempotent to re-transpile, but the executable body is ordinary plpgsql you can inspect, pg_dump, and review.
• The cost is paid once. Translation happens at CREATE FUNCTION time, not per call. At run time there is no translation layer and no per-row marshalling beyond what plpgsql already does.

The goal is to meet developers where they are on syntax without changing what the database actually executes.

Who it is for

• Application developers who want to push logic into the database using syntax they already know, rather than learning plpgsql first.
• Teams standardizing on PostgreSQL who want triggers and functions written in a familiar dialect but running with plpgsql's performance and trust model.
• Anyone who wants the generated plpgsql to be visible and reviewable rather than executed by an opaque runtime.

Dear Community Members,

We are excited to announce the release of SynchDB 1.4, a PostgreSQL extension for real-time replication from heterogeneous source databases into PostgreSQL/IvorySQL.

This release extends Oracle Container Database support to every Oracle replication path, allows snapshot connections to be encrypted, and improves stability under sustained replication load.

What's New in SynchDB 1.4:

• Oracle Container Database (CDB/PDB) Support: SynchDB can now replicate from Oracle deployments that use the Container Database architecture, across all three of its Oracle paths: change data capture through the embedded Debezium engine, initial snapshots through oracle_fdw, and log-based replication through Openlog Replicator (OLR). Specify the source database in CDB/PDB format (e.g. FREE/FREEPDB1) when creating a connector, and SynchDB connects to the corresponding PDB service automatically. This path is tested against Oracle 23ai.

• TLS and Oracle Wallet Secure Connections: Initial snapshots taken through foreign data wrappers can now run over secured connections — TLS for MySQL and PostgreSQL sources, and Oracle Wallet for Oracle and OLR sources — configured through the new synchdb_add_fdw_conninfo() function. Previously these snapshot connections could not be secured.

• Runtime-Adjustable Debezium Log Level: The log level of a running connector's Debezium engine can now be changed with synchdb_set_dbz_loglevel(). Diagnosing a misbehaving connector no longer requires restarting it, which previously meant losing the very state you were trying to observe.

• Debezium Engine Upgrade: The embedded Debezium engine moves from 2.6.2.Final to 3.5.2.Final, along with Kafka Connect, Jackson, and Log4j2. This brings SynchDB's source-database connectors in line with current upstream Debezium, including its accumulated connector fixes and dependency security updates.

• Stability Improvements: Fixed crashes that could occur under sustained replication load, a crash in the data format converter, and a startup failure that happened when SynchDB's Oracle log parser was loaded alongside IvorySQL's built-in Oracle parser. Connectors are also now auto-started in every database, rather than only in the default postgres database.

For a detailed list of all changes, please visit our release notes at https://github.com/Hornetlabs/synchdb/releases/tag/v1.4

Acknowledgments and Contributions:

Thank you to all our users who contributed patches, reported bugs, and proposed new features.

SynchDB thrives on community contributions. We warmly welcome your ideas, feature requests, or patches. Please share your contributions on our GitHub page.

Source Code:

• https://github.com/Hornetlabs/synchdb

Useful Links:

• Documentation

• Support: Report issues on GitHub

We look forward to your feedback on SynchDB 1.4 and your continued support in making SynchDB even better.

Best regards,

SynchDB Dev Team

About SynchDB

SynchDB is a PostgreSQL extension that enables real-time data synchronization from heterogeneous databases including Oracle, MySQL, SQL Server, and PostgreSQL into PostgreSQL/IvorySQL. It provides both initial snapshot and CDC (Change Data Capture) capabilities, making it an efficient solution for database migration and real-time data integration.

Sehrope Sarkini along with Claude has written a new JDBC driver from scratch. It's currently in pre-release. Here's an excerpt from his blog

PostgreSQL-first.

The native API is designed around PostgreSQL's wire protocol and feature set. It is not designed around the lowest common denominator that JDBC has to support across every database on earth. If PostgreSQL can do it, the API should be able to say it directly.

JDBC as a layer, not a foundation.

Full JDBC compliance is a long-term goal. There's already a java.sql.* layer that registers a Driver and gives you Connection, PreparedStatement, ResultSet, DatabaseMetaData, DataSource, and XA. But it's built on top of the native API rather than dictating its shape. That ordering matters. Once JDBC's assumptions get into the execution core they never come back out.

Virtual threads for I/O.

For a decade, "fast driver" implied an async or reactive API, because the alternative was a thread per connection. On Java 21 that trade is gone. pg-java is ordinary blocking-style code that is careful never to pin a carrier thread (which mostly means ReentrantLock instead of synchronized around I/O). You can run thousands of connections on virtual threads without an event loop or a callback API in sight. It's also significantly easier to reason about both how it works and how you would use it.

Streaming by default.

The core query primitive is a pull cursor. It reads exactly enough off the wire to produce the next row and never buffers a whole result set. forEach, map, collect, and friends are adapters built on top of it, not a second read path.

Dasha is an open source performance dashboard for PostgreSQL fleets. It connects to your clusters with a read-only role, shows what the databases are doing right now, and explains what to do about it. Nothing is installed on the database hosts: no agent, no extension beyond the ones you already have.

One instance serves many clusters and all of their replicas. Because most PostgreSQL statistics are per-instance and are not replicated, Dasha reads every host of a cluster and reasons over the combined picture — an index that looks unused on the primary may be serving the entire read workload on a standby.

Features

• Health Score — a composite 0-100 score per instance across eight categories, with prioritized recommendations and per-database drill-down. Optionally computed from Prometheus/VictoriaMetrics time series instead of point-in-time SQL, with a trend and seasonal baseline.
• Query analysis — top queries by execution time and WAL, running and blocked queries, and pg_stat_statements snapshots that can be saved to a storage database, shared by URL, and diffed against another snapshot or against live data.
• Automatic snapshots — a separate daemon captures query and lock-contention snapshots on activity spikes or primary/replica role changes, so the evidence exists the next morning, when someone asks what happened at 03:00.
• Index analysis — bloat, duplicates, invalid indexes, B-tree on arrays, plus a may I drop this index? verdict that accounts for statistics resets, per-host counters and partitioned indexes, instead of trusting idx_scan = 0.
• Tables and maintenance — size with TOAST breakdown, per-table describe, autovacuum and wraparound thresholds computed with PostgreSQL's own formula, vacuum progress, and hot tables/indexes derived from scheduled delta snapshots.
• Locks, waits, connections — lock trees, wait events grouped by type, connection states and sources, active session details.
• Access control — three auth modes (open, static API keys, or OIDC with encrypted session cookies), Casbin RBAC, personal access tokens and per-identity rate limiting.
• MCP connector — a read-only MCP server that exposes the fleet diagnostics to AI assistants: 26 tools, 5 prompts, per-user token passthrough, and an embedded knowledge base of the scoring rules. The interface is available in English, Russian and German.

Requirements

• PostgreSQL 14 or newer (tested on 14-18) for the monitored clusters, reachable with a role holding pg_monitor and CONNECT.
• pg_stat_statements for query statistics; pgstattuple is optional.
• A separate PostgreSQL database if you want snapshots, hot-object history and personal access tokens — everything else works without it.

Documentation

• README — configuration, deployment, Helm values.
• Health Score scoring model
• Changelog

License

Dasha is licensed under the GNU General Public License v3.0; see LICENSE.

Project page: github.com/dbulashev/dasha

Hi all,

The talk schedule for Postgres Summit US 2026 is now published. Browse it here: Talk Schedule

The summit runs September 30 through October 2, 2026 at Convene, 555 Broadway, New York, NY, organized by the United States PostgreSQL Association (PgUS).

You can also view individual sessions and register on the event site.

Hope to see you in New York!

Autobase 2.10 expands day-to-day PostgreSQL operations with new cluster management capabilities.

Administrators can now perform common cluster actions directly from the Console UI, configure advanced system settings, deploy clusters using the local disk, and automate maintenance with an extended set of Ansible playbooks.

See the full details in the release notes.

Highlights

Cluster management actions

Autobase Enterprise includes an Actions menu that allows administrators to perform common PostgreSQL cluster operations directly from the UI, including switchover, failover, replica reinstallation, restart, stop/start, and cluster deletion.

System parameters tab

Added a new System tab to the Parameters page, providing access to advanced system configuration, including Regional Settings, Host Mappings, DNS Servers, NTP Servers, Kernel Parameters, and SSH Public Keys.

Local disk storage option

Added support for deploying PostgreSQL data on the local disk, eliminating the need for an additional network volume. To enable this mode, set the volume size to 0 or explicitly select System Disk in Expert Mode.

New Ansible playbooks

Automate common PostgreSQL cluster operations with a new set of Ansible playbooks:

• Patroni cluster operations: switchover_pgcluster, failover_pgcluster, reinit_pgcluster
• Cluster lifecycle: stop_pgcluster, start_pgcluster
• Node lifecycle: stop_pgnode, start_pgnode, restart_pgnode

Explore the complete list of available playbooks in the Ansible Collection README.

About Autobase

Autobase is an Internal Database Platform for PostgreSQL, bringing the managed database experience of DBaaS into your own infrastructure.

Deploy, operate, and scale production-ready, highly available PostgreSQL clusters across bare metal, virtual machines, on-premises infrastructure, and supported cloud providers.

Website: https://autobase.tech

July 30, 2026: The pgBackRest community is pleased to announce the release of pgBackRest 2.59.0, the latest version of the reliable, easy-to-use backup and restore solution that can seamlessly scale up to the largest databases and workloads.

pgBackRest supports a robust set of features for managing your backup and recovery infrastructure, including: parallel backup/restore, full/differential/incremental backups, block incremental backup, multiple repositories, delta restore, parallel asynchronous archiving, malware/ransomware protection, per-file checksums, page checksums (when enabled) validated during backup, multiple compression types, encryption, partial/failed backup resume, backup from standby, tablespace and link support, S3/Azure/GCS/SFTP support, backup expiration, local/remote operation via SSH or TLS, flexible configuration, and more.

pgBackRest can be installed from the PostgreSQL Yum Repository or the PostgreSQL APT Repository and packages are also available for many other distributions. Source code can be downloaded from releases.

Significant New Features and Improvements

• PostgreSQL 19 support (David Steele)
• Add archive-expire-before option to clean up WAL archive (Stefan Fercot)
• Add support for S3 Outposts (Shiva Kumar Ambigi)
• Add S3 process authentication (David Steele)
• Add user/group caching for faster manifest build (Gunnar Lindholm)
• Reconnect SFTP storage after the server drops an idle connection (David Steele)
• Add per-repo backup progress to info command output (Will Morland)
• Add batch delete for Azure storage (David Steele)
• Add backup.info checks to verify command (Denis Garsh)
• Allow the S3 STS endpoint to be configured (Simon Gratton)
• Add systemd notify integration (Andrew Jackson)
• Error when running as root unless allow-root is enabled (David Steele)
• Exit async archive-push on first error (David Steele)

See the 2.59.0 Release Notes for additional features and improvements.

Important Notes

• Only the restore command may be run as root by default. Use allow-root to run other commands as root (though this is not recommended).
• A new distribution tarball with pregenerated documentation, man page, and code is attached to each release to simplify packaging. See New Distribution Tarball for more information.
• There is a new optional dependency on libsystemd.

Links

• Website
• User Guides
• Release Notes

Sponsorship

This release was made possible by the generous sponsorship of AWS, Supabase, pgEdge, Tiger Data, Percona, Eon, Xata, Dalibo, and Data Egret.

We are very glad to announce the E-Maj 5.0.0 version.

Among improvements, this major version:

• Allows non-superuser roles to install and use E-Maj in a database, the usable features depending on the priviledges they own.
• Eases writing idempotent administration scripts and managing E-Maj parameters.
• Brings the PostgreSQL 19 version compatibility.

The Emaj_web client has been enhanced too, in particular to take benefit of these new features.

E-Maj is a PostgreSQL extension which enables fine-grained write logging and time travel on subsets of the database.

E-Maj 5.0.0 is compatible with Postgres 14 to 19 versions. Emaj_web 5.0.0 is compatible with emaj extension 3.0 to 5.0 versions.

The full documentation is available on line. The core extension is available at pgxn.org for installation or github.org for development.

The Emaj_web client is also available at github.org.

Have fun with E-Maj !

The pgAdmin Development Team is pleased to announce the release of pgAdmin 4 version 9.17. This release of pgAdmin 4 includes 28 bug fixes and new features, including fixes for seven security vulnerabilities (CVE-2026-17346 through CVE-2026-17351, and CVE-2026-17566). For more details, please see the release notes.

pgAdmin is the leading open-source graphical management tool for PostgreSQL. For more information, please see the website.

Notable changes in this release include:

Features:

• Include the authenticated user's identity in the HTTP access log.
• Add an opt-in Gateway API HTTPRoute template to the Helm chart as an alternative to the existing Ingress.
• Add a preference to cap the row count fetched by the plain "View Data" action, so it is usable on large tables without always doing a full SELECT *.
• Add support for a custom XYZ tile provider (URL, name, CRS, attribution, max zoom) in the Geometry Viewer, alongside the existing built-in base layers.

Security Fixes:

• Fix a tool-permission bypass where a user denied the Query Tool, Grant Wizard, or Schema Diff permission could still drive that tool's backend routes and Socket.IO handlers directly, since the permission check was applied only to a single "front door" route per tool. Also fixes a non-owner triggering an adhoc connection against another user's shared server persisting a new server record still owned by that other user (CVE-2026-17350).
• Fix OS command injection in the MASTER_PASSWORD_HOOK feature, where an externally-sourced username (e.g. via OAuth2/OIDC, Kerberos, or webserver authentication) containing shell metacharacters could execute arbitrary commands as the pgAdmin service account when the configured hook string uses %u (CVE-2026-17347).
• Fix a lexer-differential bypass of the AI Assistant's read-only transaction guard, where sqlparse's string-literal lexing disagreed with PostgreSQL's own parser under standard_conforming_strings = on, letting a crafted multi-statement payload smuggle a COMMIT past the intended read-only wrapper; an incomplete fix for CVE-2026-12045 (CVE-2026-17351).
• Fix SQL injection in the Index Statistics all-indexes listing and the Publications/Subscriptions Dependencies views, where an apostrophe in a table, index, publication, or subscription name broke out of an unescaped template interpolation; an incomplete fix for CVE-2026-12044 (CVE-2026-17346).
• Fix several Constraints, Preferences, Debugger, and Schema Diff routes missing the @pga_login_required decorator, making them reachable without authentication in server mode; an incomplete fix for CVE-2026-12046 (CVE-2026-17348).
• Fix an adhoc server connection cloning another user's stored database credentials (password, save password flag, tunnel password) alongside ownership, letting a non-owner who cloned another user's shared server connect using that user's saved database password (CVE-2026-17349).
• Fix OS command injection in the Import/Export Data tool, where a query-based export could pass a crafted query string past the \copy (...) parenthesis-balance guard by exploiting a backslash-escape mismatch with psql's default standard_conforming_strings = on behaviour, exposing a live TO PROGRAM clause for arbitrary command execution (CVE-2026-17566).

Bugs/Housekeeping:

• Fix Schema Diff's "Generate Script" and the browser tree's CREATE Script view emitting wrong SQL for SERIAL/identity columns, by detecting column-owned sequences via pg_depend instead of guessing the sequence name.
• Fix ALT+F5 ("Execute query at cursor") doing nothing when the cursor is on or near a statement that is not highlighted, in a Query Tool tab with multiple statements separated by blank lines.
• Fix the object browser's extension UI breaking under PostgreSQL 19's extension catalog changes.
• Detect a selected-but-unusable OS keyring and fall back gracefully instead of failing.
• Warn when OAuth2 provider settings are misplaced at the top level of the config instead of under OAUTH2_CONFIG.
• Honor the selected EOL sequence when copying query text to the clipboard.
• Fix a Schema Diff result-status filter chip showing "No difference found" after being toggled off and back on, even when real differences exist.
• Fix the Object Explorer briefly showing literal HTML markup instead of a greyed-out "[Disconnecting...]" label when disconnecting a server or database.
• Centralize shared-server-group visibility and access-control logic, and adjust the ServerGroup-to-Server/SharedServer model relationships.
• Fail the macOS appbundle build if any bundled library links outside the bundle, and scan all Mach-O binaries for bundle linkage.
• Pin the sonarqube-scan-action GitHub workflow to a full commit SHA, and pin the Yarn version used by the build scripts to the packageManager field.
• Bump JavaScript and Python third-party dependencies, including axios, webpack, react, electron, and certifi.
• Update the Simplified Chinese (zh_Hans_CN) translation.

Builds for Windows and macOS are available now, along with a Python Wheel, Docker Container, RPM, DEB Package, and source code tarball from the download area.

PL/Ruby is a procedural-language handler that lets you write database functions in Ruby, stored and executed inside PostgreSQL. You get the expressiveness of Ruby and its standard library with the full power of a native PostgreSQL function: plain functions, set-returning functions, triggers, event triggers, and procedures with transaction control.

```sql CREATE EXTENSION plruby;

CREATE FUNCTION hello(text) RETURNS text LANGUAGE plruby AS $$ "Hello, #{args[0]}!" $$;

SELECT hello('world'); -- Hello, world! ```

[!NOTE] PL/Ruby embeds an MRI Ruby interpreter in the backend. It targets PostgreSQL 11-18 and Ruby 3.x, installs as a first-class CREATE EXTENSION, and mirrors the feature set of PL/php with a large set of PL/Perl- and PL/Tcl-inspired capabilities.

Features

| Scalars, arrays, composites | Arguments arrive as native Ruby values: Integer, Float, true/false, String, nested Array, and composite/record types as Hash. |

| Set-returning functions | RETURNS SETOF / RETURNS TABLE with return_next. |

| Triggers | Row & statement triggers via $_TD

|Event triggers | Back CREATE EVENT TRIGGER with RETURNS event_trigger. |

|Database access (SPI) | spi_exec, spi_fetch_row, spi_processed, spi_status, spi_rewind, and result column metadata (spi_colnames / spi_coltypes / spi_coltypmods). |

|Cursor streaming | spi_query (block or handle), spi_fetchrow, spi_cursor_close, Cursor#each. Consume large results without materializing them. |

|Prepared statements | spi_prepare / spi_exec_prepared / spi_query_prepared / spi_freeplan. |

|Transaction control | spi_commit / spi_rollback in procedures, plus subtransaction blocks. |

| Utilities | quote_literal / quote_nullable / quote_ident, elog, session-shared $_SHARED, and per-function $_SD. |

| Session setup | Anonymous DO blocks, plruby_modules autoloading, and a plruby.start_proc hook. |

| Transforms | jsonb_plruby, hstore_plruby, and ltree_plruby: functions declared TRANSFORM FOR TYPE exchange native Ruby Hashes/Arrays with jsonb, hstore, and ltree. |

See the language reference for the full API, the cookbook for tested recipes, and the PL/Perl and PL/Tcl comparisons for feature-by-feature detail.

Examples

A set-returning function

```sql CREATE FUNCTION squares(lim integer) RETURNS TABLE(n integer, square integer) LANGUAGE plruby AS $$ (1..lim).each do |i| n = i square = i * i return_next end $$;

SELECT * FROM squares(3); -- (1,1), (2,4), (3,9) ```

Querying the database with a prepared plan

sql CREATE FUNCTION lookup(int) RETURNS text LANGUAGE plruby AS $$ plan = spi_prepare('select name from things where id = $1', 'int4') row = spi_fetch_row(spi_exec_prepared(plan, args[0])) spi_freeplan(plan) row['name'] $$;

A row trigger that transforms data

sql CREATE FUNCTION uppercase_name() RETURNS trigger LANGUAGE plruby AS $$ $_TD['new']['name'] = $_TD['new']['name'].upcase 'MODIFY' $$;

Requirements

• PostgreSQL 11 or newer (tested on 11-18; 18 recommended), with the server development files that provide pg_config.
• Ruby 3.x built as a shared library (ENABLE_SHARED=yes) with development headers. On Debian/Ubuntu, install ruby-dev.

Installation

sh make sudo make install

Then, in a database:

sql CREATE EXTENSION plruby;

See INSTALL for details, and run the regression suite with make installcheck.

Security

[!WARNING] PL/Ruby is an untrusted language. Ruby 3.0 and later have no sandbox ($SAFE and object tainting were removed in Ruby 3.0), so a PL/Ruby function can do anything the PostgreSQL server's operating-system user can: read and write files, open network connections, run shell commands, and so on.

The language is created without the TRUSTED attribute, so only superusers can install the extension or create PL/Ruby functions. Grant that ability only to roles you would trust with the server's OS account.

Documentation

• Language reference
• Cookbook: tested recipes
• Performance benchmarks
• Feature comparison: PL/Ruby vs PL/php vs PL/Perl vs PL/Tcl
• PL/Ruby vs PL/Perl
• PL/Ruby vs PL/Tcl
• Why PL/Ruby embeds CRuby (MRI), not mruby

License

PL/Ruby is licensed under the MIT License; see LICENSE.

The CloudNativePG Community is excited to announce the immediate availability of CloudNativePG 1.30.0!

This minor release introduces the new DatabaseRole CRD for declarative, GitOps-friendly PostgreSQL role management and a Lease-based primary election primitive for safer failover, alongside notable security and operational improvements, further cementing CloudNativePG as the leading operator for running PostgreSQL workloads on Kubernetes.

We are also pleased to announce the release of maintenance versions 1.29.2 and 1.28.4, the latter of which is the final planned release in the 1.28.x series. We encourage users on 1.28 to plan their upgrade to 1.29 or 1.30.

With the release of CloudNativePG 1.30.0, the CloudNativePG 1.28.x series reaches its End-of-Life (EOL) date of June 30, 2026, and the EOL date for the CloudNativePG 1.29.x series is confirmed as September 29, 2026.

Highlights in 1.30.0

DatabaseRole CRD for declarative role management

The headline addition in 1.30 is the new DatabaseRole custom resource, which manages a PostgreSQL role as a standalone Kubernetes object rather than inline in the Cluster’s .spec.managed.roles stanza. Each role now has its own lifecycle, status and RBAC, which suits GitOps workflows and lets role definitions live next to the applications that own them. Migrating an existing role is a matter of moving its stanza into a dedicated manifest.

A DatabaseRole can also include a clientCertificate block, having the operator automatically generate and renew a TLS client certificate signed by the cluster’s client CA and stored in a <databaserole-name>-client-cert Secret. This enables password-free PostgreSQL cert authentication, with the Secret cleaned up automatically when the feature is disabled or the resource is deleted.

Primary Lease for safe primary election

CloudNativePG 1.30 introduces a Kubernetes Lease object, named after the cluster, that acts as a mutex serializing primary promotion. The instance manager must hold the lease before acting as primary and releases it on clean shutdown, so replicas can promote without waiting for the full TTL. Timings are configurable through the new .spec.primaryLease stanza.

To be precise about the architecture: the lease is a promotion gate, not a fence. Primary isolation remains responsible for fencing — the Lease closes the window for an uncoordinated promotion during transitions.

Enhanced Security and Resilience

This release includes significant improvements focused on stability, security, and supply-chain integrity:

• search_path pinning (CVE-2026-55769): Fixed a privilege-escalation vulnerability (CWE-426) where a database owner could plant overloaded operators in the public schema. The operator now pins search_path = pg_catalog, public, pg_temp on its pooled connections.
• SCRAM-SHA-256 password encoding (CVE-2026-55765): The operator now SCRAM-SHA-256 encodes cleartext passwords before issuing CREATE/ALTER ROLE commands, so the SCRAM verifier — rather than the cleartext secret — is what could ever appear in logs or extension captures.
• Authenticated instance communication (GHSA-7qwx-x8ff-3px9): Operator-to-instance-manager communication is now authenticated via ECDSA certificates. This hardening is new in 1.30.0 and is not backported; on earlier releases continue to restrict the instance status port with a NetworkPolicy.

Other Notable Enhancements

• In-place major upgrades with Image Volume extensions — pg_upgrade in-place upgrades are now supported for clusters using Image Volume extensions, mounting the source- and target-version extension images side by side so a failed upgrade reverts cleanly.
• PgBouncer image management via Image Catalogs — the Pooler can now reference an ImageCatalog or ClusterImageCatalog entry through spec.pgbouncer.imageCatalogRef, with referencing Poolers automatically reconciled and rolled out when a catalog entry changes.
• TLS for the Pooler metrics endpoint via .spec.monitoring.tls.enabled, with hot certificate reloading on every handshake.
• Cluster as a VPA/HPA target through a new status.selector on the scale subresource, mapping a Cluster to its instance pods.
• Primary status visibility — the operator now emits a PrimaryStatusCheckFailed warning event when a primary pod looks Ready to the kubelet but fails the operator’s /pg/status check, surfacing failover deferrals via kubectl describe cluster.

This release also adds support for Kubernetes 1.36 and updates the default PostgreSQL version to 18.4.

Heads-up on an API change: the cluster reference is now immutable on the Database, Pooler, Publication, Subscription and ScheduledBackup resources. Re-pointing one of these at a different cluster is now rejected by a CEL validation rule at the API server, as it had no well-defined semantics.

Dive into the full list of changes and fixes in the release notes for CloudNativePG 1.30.

Maintenance Releases: 1.29.2 & 1.28.4

In parallel with the 1.30 release, we have also shipped maintenance updates for the previous stable series. Both backport the security fixes above — including search_path pinning and SCRAM-SHA-256 password encoding — along with VPA/HPA support, primary status visibility, automatic CNPG-I plugin reloading, Kubernetes 1.36 support, the updated PostgreSQL 18.4 default, and dozens of bug fixes:

• CloudNativePG 1.29.2: see the release notes for 1.29.
• CloudNativePG 1.28.4: the final planned maintenance release for the 1.28.x series — see the release notes for 1.28. We strongly recommend planning an upgrade to a currently supported version.

We encourage all users to upgrade to the latest stable versions to benefit from the latest features, security enhancements, and bug fixes.

Follow the upgrade instructions for a smooth transition.

Get Involved with the Community

Join us to help shape the future of cloud-native Postgres!

If you’re using CloudNativePG in production, consider adding your organization as an adopter to support the project’s growth and evolution.

Thank you for your continued support! Upgrade today and discover how CloudNativePG can elevate your PostgreSQL experience to new heights.

POSETTE: An Event for Postgres 2026, took place from 16–18 June 2026 as a free and virtual event, organized by Microsoft in partnership with AMD. Although the event has concluded, all the content remains available online.

All 44 talks are now on YouTube

Whether you missed the conference or want to revisit your favorite sessions, all 44 talks are now available on YouTube, with captions that have been translated into 16 different languages (because accessibility matters). Explore the recordings and resources below:

• Find all 44 talks: in one playlist on YouTube
• Watch the first keynote: Driving Postgres forward at Microsoft, delivered by Affan Dar and Charles Feddersen
• Watch the second keynote: Postgres 19 Hackers Panel: What’s In, What’s Out, & What’s Next, with Heikki Linnakangas, Melanie Plageman, Thomas Munro, and Álvaro Herrera
• Replay the full livestreams: watch the livestream playlist if you want to enjoy the talks back-to-back, peppered with host banter
• Learn more about the speakers: The Speaker page shines a light on this year’s 50 speakers, featuring biographies and written interviews

If you need help deciding which talks to watch first, this ultimate guide blog post may help. All the talks are categorized into buckets such as Postgres core, Postgres ecosystem, Azure Database for PostgreSQL and Azure HorizonDB—and then we tagged each talk by topic.

Big Gratitude: Thank you!

Big thank you to everyone who participated in the 5th annual POSETTE, whether as a speaker or livestream host or livestream attendee on the virtual hallway track on Discord.

Keep up with the latest news

Good news: Discussions are already underway for POSETTE: An Event for Postgres 2027. We hope to see you there!

Subscribe to the POSETTE newsletter, our team at Microsoft will send you a newsletter when the next POSETTE is announced, when the CFP opens and closes, when we post the schedule, and when there is other important news about the event to share.

You can follow POSETTE on LinkedIn, Bluesky, Mastodon, and X/Twitter. #PosetteConf

We are pleased to announce the release of Barman 3.19.0 and 3.19.1, which shipped in quick succession on May 20 and May 26, 2026. This announcement covers both releases.

Barman (Backup and Recovery Manager) is an open-source administration tool for remote backups and disaster recovery of PostgreSQL servers in business-critical environments. It relies on PostgreSQL's point-in-time recovery technology, allowing DBAs to manage a complete catalog of backups and the recovery phase of multiple remote servers from one location.

Release Highlights (3.19.0)

Cloud Storage Restore Support
Barman can now restore backups taken with backup_method = local-to-cloud or backup_method = postgres directly from cloud object storage, using the standard barman restore command. A new barman cloud-wal-restore command fetches WAL files directly from cloud storage during recovery and supports parallel fetching. This completes the cloud backup lifecycle, enabling backup and recovery workflows entirely in the cloud.

New Backup Export and Import Commands
New barman export-backup and barman import-backup commands let you export a backup to a tarball for sharing or archiving, and re-register a previously exported backup into a Barman catalog.

Improvements
Parallel WAL archiving for barman cloud-wal-archive (--parallel flag), reducing WAL archival backlog during high-WAL periods.
Parallel WAL restore support added to barman-cloud-wal-restore.
Support for alternative GCP universes via the GOOGLE_CLOUD_UNIVERSE_DOMAIN environment variable.
New aws_check_object_lock option checks S3 Object Lock before deleting base backup files.
In-progress cloud backups are now visible in barman-cloud-backup-list rather than only appearing once complete.
New --partial-wal flag for barman restore --no-get-wal, for opt-in inclusion of .partial WAL files.
Setuptools is no longer a runtime dependency.

Bug Fixes (3.19.0)
Fixed backup metadata (backup.info) not being updated in cloud storage for local-to-cloud/postgres backup methods.
Fixed barman restore --no-get-wal copying unusable .partial WAL files that PostgreSQL could never apply.
Fixed --no-get-wal restores not copying WAL files from newer timelines on PostgreSQL 12+, which could cause PITR restores to fail.
Fixed spurious warnings about intermediary files not being removed during batch WAL archiving (introduced in 3.18).

Bug Fixes (3.19.1)
Fix cloud-wal-restore failing to find compressed WAL files
Fixed a bug where barman-cloud-wal-restore and barman cloud-wal-restore would fail to locate a compressed WAL file when a backup file with the same prefix existed in the cloud storage bucket. WAL files are now correctly identified even when backup files share the same prefix.

Links
Website: https://pgbarman.org/
Download: https://www.enterprisedb.com/software-downloads-postgres#barman
Documentation: https://docs.pgbarman.org/
Release Notes: https://docs.pgbarman.org/release/3.19.0/releases/index.html and https://docs.pgbarman.org/release/3.19.1/releases/index.html
Support: https://pgbarman.org/support/

About Barman
Barman is distributed under the GNU GPL 3 license and maintained by EnterpriseDB (EDB).

🚀 Announcing pglayers

Pre‑built PostgreSQL extensions as composable Docker image layers

Project: https://github.com/pglayers/pglayers

📌 What It Does

pglayers publishes 53 PostgreSQL extensions as minimal Docker images (FROM scratch).
Each image contains only:

• Shared libraries
• Control files
• SQL scripts
• Correct filesystem paths

You compose them onto the official postgres Docker image using COPY --from:

dockerfile FROM postgres:17 COPY --from=ghcr.io/pglayers/pgx-pgvector:17 / / COPY --from=ghcr.io/pglayers/pgx-postgis:17 / / COPY --from=ghcr.io/pglayers/pgx-pg_cron:17 / /

No compilation.
No apt-get.
No build tools in the final image.
Just CREATE EXTENSION as usual.

🟢 Ready-to-Use Images

For a fully preconfigured setup:

bash docker run -d -e POSTGRES_PASSWORD=s ghcr.io/pglayers/pglayers-full:17

Includes:

• All 53 extensions
• shared_preload_libraries already set

Also available:

• Azure profile (28 extensions) matching Azure Database for PostgreSQL Flexible Server
  Useful for local dev/test against managed services.

📦 Extensions Included

53 extensions across major categories:

• AI/ML: pgvector
• Geospatial: PostGIS, pgRouting, h3-pg
• Time-series: TimescaleDB
• Analytics: pg_duckdb
• Observability: pgaudit, pg_stat_monitor, pg_qualstats, pg_wait_sampling
• Scheduling: pg_cron
• Partitioning: pg_partman
• Replication: pglogical, pg_failover_slots, wal2json
• Full text search: pg_textsearch, pg_bigm, rum
• And 36 more

Full list: https://github.com/pglayers/pglayers#available-extensions

🐘 Supported PostgreSQL Versions

• PostgreSQL 17 (stable)
• PostgreSQL 18 (stable)
• PostgreSQL 19 (experimental, beta)

All images support linux/amd64 and linux/arm64.

🧱 PG 18+ Isolated Layout

PostgreSQL 18 introduces extension_control_path and dynamic_library_path.
pglayers uses these to place each extension in its own namespace:

/extensions/<name>/

Benefits:

• No file collisions
• Multiple versions of the same library can coexist
• Extensions can be mounted at deploy time (no rebuild)

Example:

dockerfile COPY --from=ghcr.io/pglayers/pgx-pgvector:18 / /extensions/pgvector/ COPY --from=ghcr.io/pglayers/pgx-pg_cron:18 / /extensions/pg_cron/

PostgreSQL locates them via:

extension_control_path = '/extensions/pgvector/share:/extensions/pg_cron/share:$system' dynamic_library_path = '/extensions/pgvector/lib:/extensions/pg_cron/lib:$libdir'

Fully compatible with CloudNativePG ≥ 1.27, which auto‑manages these GUCs.

🧪 Testing

The test suite validates:

• No file collisions between layers
• No overwrites of base image files
• All shared library dependencies resolve (ldd)
• CREATE EXTENSION succeeds for every extension
• Functional smoke tests + integration tests

📄 Licensing

Only permissive open-source licenses:

• PostgreSQL
• MIT
• BSD
• Apache 2.0
• ISC
• MPL‑2.0

PostGIS and pgRouting (GPL‑2.0) included under the standard mere aggregation interpretation used in the PostgreSQL ecosystem.

No BSL, SSPL, or proprietary-dependency extensions.

🤝 Contributing

Contributions welcome!

Adding a new extension requires:

• Dockerfile
• extension.conf
• test.sql

See CONTRIBUTING.md for details.

Feedback, bug reports, and extension requests via GitHub Issues.

🙏 Acknowledgements

This project stands on the shoulders of the PostgreSQL community:

• PostgreSQL Global Development Group
• PGDG APT Repository maintainers
• Official PostgreSQL Docker image maintainers
• Debian PostgreSQL team
• Every extension author who publishes under permissive licenses

pglayers is a thin layer of automation on top of their work. Without the quality and consistency of the upstream ecosystem, this project would not exist.

Thanks!
Ismael Mejia

PDU helps recover offline PostgreSQL databases by reconstructing metadata, exporting tables, and reading WAL for targeted row recovery.

When a PostgreSQL instance cannot be started, normal SQL tools are no longer available. PDU, PostgreSQL Data Unloader, is an open source recovery tool for that situation. It reads PostgreSQL data files and WAL archives directly, without modifying the original data directory.

PDU can reconstruct database, schema, and table metadata while the database is offline. After the structure is discovered, it can export a single table, a schema, or a full database with one command. The output is CSV, which makes it practical to inspect recovered data or load it into another PostgreSQL instance.

For accidental DELETE and UPDATE operations, PDU can also recover selected row data from WAL. This recovery path does not rely on tuple remnants left before VACUUM. Instead, it reads WAL records available on a replica or in WAL archives, then reconstructs deleted rows or pre-update row versions from those records. The recovery window therefore depends on WAL availability.

Current capabilities include:

• offline discovery of PostgreSQL database, schema, and table metadata
• export of a single table, a schema, or a full database to CSV
• direct reading of PostgreSQL heap and TOAST files
• WAL-based recovery of deleted rows and pre-update row versions
• recovery support for catalog corruption, accidental DELETE/UPDATE, and damaged data files
• support for PostgreSQL 14 to 18

PDU is intended as an emergency recovery aid. It is not a replacement for backups, PITR, or existing PostgreSQL recovery practices.

Project repository: https://github.com/wublabdubdub/PDU-PostgreSQLDataUnloader

Feedback is welcome, especially around heap/TOAST parsing, offline metadata reconstruction, WAL decoding, supported data types, and recovery edge cases.

Autobase 2.9 focuses on the next step in the platform's evolution: simplifying PostgreSQL infrastructure management after deployment.

See the full details in the release notes.

Highlights

Platform users & email/password authentication

Added support for platform users and email/password authentication. Each user can now sign in with their own credentials instead of using a shared access token.

The Operations log now also records which user performed each change, providing a complete audit trail.

Manage cluster and Postgres parameters

Manage PostgreSQL parameters, pg_hba.conf, connection pools, and other cluster settings directly from the UI, making day-to-day cluster administration simpler and more efficient.

YAML editor with diff mode

Added a built-in YAML editor for advanced cluster configuration. Edit any supported configuration directly in the UI and review changes with a built-in diff before applying them. Available in Expert Mode.

About Autobase

Autobase is an Internal Database Platform for PostgreSQL that brings the managed database experience of DBaaS to your own infrastructure.

It enables organizations to deploy and operate production-ready, highly available PostgreSQL clusters while retaining full control over their infrastructure and data.

Website: https://autobase.tech

What's Changed

• use openssl 3.5.5 by @davecramer in https://github.com/postgresql-interfaces/psqlodbc/pull/169
• Fix SQLPrimaryKeys to exclude INCLUDE columns from results by @davecramer in https://github.com/postgresql-interfaces/psqlodbc/pull/171
• Fix stack buffer overflow in getPrecisionPart() (GitHub #173) by @davecramer in https://github.com/postgresql-interfaces/psqlodbc/pull/174
• Avoid reading past conn_settings end by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/176
• Validate percent escapes before decoding connection-string values by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/175
• Handle ARD bookmark allocation failure by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/179
• fix version reporting by @davecramer in https://github.com/postgresql-interfaces/psqlodbc/pull/181
• Reject overlong cursor names by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/178
• Reject invalid SQLPutData lengths by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/182
• Detach freed app descriptors from statements by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/183
• Avoid reading before leading string literals by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/185
• Pass SQLSetDescRec field values correctly by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/186
• Validate UTF-16 surrogate pairs before combining by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/187
• Clear PGresults from per-query rollback by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/188
• Fix double-free / heap corruption during SQLDisconnect cleanup (#189) by @davecramer in https://github.com/postgresql-interfaces/psqlodbc/pull/190
• Redact sensitive connection parameters in logs by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/184
• Use signed type for error status by @jarvis24young in https://github.com/postgresql-interfaces/psqlodbc/pull/193

New Contributors

• @jarvis24young made their first contribution in https://github.com/postgresql-interfaces/psqlodbc/pull/176

Full Changelog: https://github.com/postgresql-interfaces/psqlodbc/compare/REL-18_00_0001...REL-18_00_0002

Tainan, Taiwan - Sun 12 Jul 2026

powa-archivist 5.2.0

The PoWA team is pleased to announce the release of the version 5.2.0 of powa-archivist, the core extension of the PoWA project.

PoWA (PostgreSQL Workload Analyzer) is a performance tool, compatible with all supported PostgreSQL versions. It allows to collect and aggregate metrics gathered from multiple PostgreSQL instances using various extensions covering all parts of PostgreSQL and provides real-time charts and graphs to help monitor and tune your servers. It also suggest optimizations, like global or per-query index suggestions, to easily improve performances.

• New feature
  • Add support for pg19, including new stat viewpg_stat_recovery and pg_stat_lock (Julien Rouhaud, Georgy Shelkovy)

Links & Credits

Thank to the users who reported bugs or submitted patches, they are all cited in the CHANGELOG file and the CONTRIBUTORS file.

powa-archivist is an open project. Any contribution to build a better tool is welcome. You just have to send your ideas, features requests or patches using the github repository at github.com/powa-team/powa-archivist.

Links

• Documentation: powa.readthedocs.io/
• Download: github.com/powa-team/powa-archivist/releases
• Bug tracker: github.com/powa-team/powa-archivist/issues

We are excited to announce a new release of the Odyssey — advanced multi-threaded connection pooler for PostgreSQL and Apache Cloudberry.

A lot of new small features have been implemented, alongside extended protocol support refactoring - many violations fixed, and overall performance of pipelining improved.

New features:

• simple shared pools support
• pool_pin_on_listen option for transaction pooling
• improvements of balancing
• cpu_affinity support
• build with aws-lc support
• SSLKEYLOGFILE support
• support for queue time metrics: avg_wait_time / total_wait_time
• poll server on attach for transparent failed backends closing
• NOTICE with queue time via pool_notice_after_waiting_ms option
• server_drop_on_cached_plan_error option
• improvements of prometheus metrics exporter

Bug fixes

• recheck pool size after server creation
• better cancel support: wait for PG to close the cancel-connection and fix race
• auth_query fixes
• correct Close support in Extended protocol
• DEALLOCATE ALL support
• correct COPY support in extended protocol

More on pages:

• release page on github
• documentation at pg-odyssey.tech
• community links

We are already preparing the 1.5.2 with even more features and fixes, stay tuned! :)

The PostgreSQL Global Development Group announces that the second beta release of PostgreSQL 19 is now available for download. This release contains PostgreSQL 19 feature previews ahead of general availability, though some details of the release can change during the beta period.

You can find information about all of the PostgreSQL 19 features and changes in the release notes:

https://www.postgresql.org/docs/19/release-19.html

In the spirit of the open source PostgreSQL community, we strongly encourage you to test the new features of PostgreSQL 19 on your systems to help us eliminate bugs and other issues. While we do not advise you to run beta versions in production environments, we encourage you to find ways to run your typical application workloads against this beta release.

Your testing and feedback help the community ensure that PostgreSQL 19 upholds our standards of delivering a stable, reliable release of the world's most advanced open source relational database. Please read more about our beta testing process and how you can contribute:

https://www.postgresql.org/developer/beta/

Upgrading to PostgreSQL 19 Beta 2

To upgrade to PostgreSQL 19 Beta 2 from an earlier version of PostgreSQL, you will need to use a strategy similar to upgrading between major versions of PostgreSQL (e.g. pg_upgrade or pg_dump / pg_restore). For more information, please visit the documentation section on upgrading.

Changes Since Beta 1

Fixes and changes in PostgreSQL 19 Beta 2 include:

• Fix a regression in vacuumdb --analyze-in-stages for partitioned tables.
• Fix servicefile to show correct file after fallback to system file.
• Fix tuple deformation optimization for virtual generated columns.
• Allow pg_createsubscriber to accept duplicate publication names.
• Fix REPACK worker not being cleaned up on a FATAL exit.
• Several fixes for the new FOR PORTION OF temporal table syntax.
• Fix race condition when logical decoding activation is concurrently interrupted.
• Disallow negative values for max_retention_duration.
• Fix md5_password_warnings for role and database settings.
• Several fixes for the new SQL/PGQ property graph feature.
• Fix autovacuum's multixact-age score calculation, which could become infinite.
• Revert non-text output formats for pg_dumpall.
• Fix locking for ALTER DOMAIN ... VALIDATE CONSTRAINT.
• Fix how postgres_fdw handles imported foreign-table statistics.

Please see the release notes for a complete list of new and changed features:

https://www.postgresql.org/docs/19/release-19.html

Testing for Bugs & Compatibility

The stability of each PostgreSQL release greatly depends on you, the community, to test the upcoming version with your workloads and testing tools to find bugs and regressions before the general availability of PostgreSQL 19. As this is a Beta, minor changes to database behaviors, feature details, and APIs are still possible. Your feedback and testing will help determine the final tweaks on the new features, so please test in the near future. The quality of user testing helps determine when we can make a final release.

A list of open issues is publicly available in the PostgreSQL wiki. You can report bugs using this form on the PostgreSQL website:

https://www.postgresql.org/account/submitbug/

Beta Schedule

This is the second beta release of version 19. The PostgreSQL Project will release additional betas as required for testing, followed by one or more release candidates, until the final release around September/October 2026. For further information please see the Beta Testing page.

Links

• Download
• Beta Testing Information
• PostgreSQL 19 Beta Release Notes
• PostgreSQL 19 Open Issues
• Submit a Bug
• Donate