SafeGrd is a new backup service for PostgreSQL 13 and later that restores every backup on a schedule and checks the row counts.

It takes a backup, restores it later into memory or a throwaway database, and counts what came back, so you find out a backup is broken before you need it.

Taking the backup

The safegrd daemon runs on a host next to your database and connects as a read-only role. On PostgreSQL 14 and later that role only needs pg_read_all_data. On 13 you grant each schema instead. The schema comes from pg_dump and the rows come over binary COPY, in one transaction. After the first run, each backup uploads only what changed.

The backup is encrypted with age on your host before it leaves, then written to an S3 bucket with Object Lock on. That can be your own bucket or SafeGrd-hosted storage. The backup data never goes through SafeGrd's servers.

You choose how the age key is managed. With a customer-managed key, only you can decrypt these backups. With a SafeGrd-managed key, SafeGrd keeps your key sealed and releases it only to your enrolled hosts, so you can restore even after losing a host.

Supabase, Neon and Amazon RDS work from a connection string. Supabase backups are restored on Supabase's own Postgres image, so the extensions in the dump load.

Testing the backup

We call the restore test a Fire Drill. It takes the newest backup, decrypts it and checks it in one of two ways:

• In memory. The dump is replayed without a running server, and the table, row and column counts and the extensions are compared with what the backup recorded.
• In a sandbox. The backup is restored into a throwaway PostgreSQL database and the counts are checked there. You can add your own SQL checks too, for example SELECT count(*) FROM users WHERE email IS NULL has to return 0.

Each drill writes a signed, dated record with the counts and the check results. Every record points at the one before it. The attestation verifier checks the whole chain against SafeGrd's published signing key in your browser, with nothing to install.

Trying it

curl -fsSL https://safegrd.dev/install.sh | sh
safegrd login
safegrd enroll

The CLI source is on GitHub under the Business Source License 1.1.

The free plan covers one database. It is backed up daily to SafeGrd-hosted storage, or hourly to your own bucket, and drilled in memory once a week. Paid plans start at $15 a month and add hourly backups, sandbox drills and more databases.

Docs: safegrd.dev/docs

pgrecon, an Apache-2.0 licensed Oracle to PostgreSQL migration assessment and schema conversion tool, is now public. The current release is 0.7.3.

pgrecon works entirely offline. A reviewable, read-only SQL*Plus script produces a dump, and the tool builds a local inventory from it; it never connects to either database. A deterministic rule engine runs 80 rules over the inventory, covering data types and length semantics, storage and partitioning, PL/SQL constructs (parsed with a full grammar, not pattern matching), supplied-package usage, schema objects, and performance posture, each with line-level evidence and remedy guidance. An effort estimator produces person-day ranges from named components with stated assumptions.

The converter emits plain PostgreSQL DDL for what it can prove: tables with native partition children, constraints, indexes, sequences, views (CONNECT BY hierarchies become WITH RECURSIVE), materialized views, comments, grants, simple DML triggers, and standalone routines, now including ROWNUM top-N bounds as LIMIT and MERGE statements. Everything it cannot carry faithfully is a named line in a residue report, never emitted DDL.

Verification: the full extraction path is verified nightly in CI against Oracle XE 11g, XE 21c, and Oracle Free 23ai; converted output is applied to PostgreSQL 16, 17, and 18 on every commit; a schema fuzzer generates adversarial Oracle estates nightly and checks that nothing crashes, nothing is lost silently, and the DDL applies; and the public benchmark row is measured by a workflow in the repository, which installs Oracle's HR, OE and CO samples plus utPLSQL, PLJSON, Logger and Alexandria into a live Oracle XE 21c, extracts, converts, and applies to PostgreSQL 16: 423 statements, zero rejected, at 0.7.3. Both extraction script tiers capture character versus byte length semantics, so VARCHAR2(30 CHAR) maps to varchar(30).

Oracle 9.2 through 23ai are supported through two extraction script tiers; Python 3.11 or newer on the analysis side.

Install: pip install pgrecon

• Project page: muzzammil242.github.io/pgrecon
• Source: github.com/Muzzammil242/pgrecon
• Release notes: pgrecon 0.7.3

BackupDrill backs up Supabase Postgres databases to a bucket you own, then restores each backup into a throwaway PostgreSQL instance to check it restores.

Most teams find out whether their pg_dump backups work on the day they need them. BackupDrill makes that check a routine step.

What it does:

• Runs pg_dump (custom format) against a Supabase project and streams the archive to any S3-compatible bucket (AWS S3, Cloudflare R2, Backblaze B2, Wasabi), with a checksummed manifest. Storage files can be copied into the same snapshot.
• backupdrill drill restores the latest snapshot into a throwaway PostgreSQL container with pg_restore. It checks the archive checksum, that pg_restore completed, that post-data objects such as indexes, constraints and triggers were created, that every table is present and that tables which held data are not empty, and it records how long the restore took.
• Backups are plain pg_dump archives, so stock pg_restore can restore them without BackupDrill.
• It refuses to run a pg_dump whose major version is older than the server's. Supabase currently runs PostgreSQL 15 to 17.

Scope: Supabase-hosted PostgreSQL only for now; the public schema is dumped by default and other schemas can be added.

The CLI is MIT-licensed: https://github.com/backupdrill/cli (npm package: backupdrill). The hosted service at https://backupdrill.com runs the same engine on a schedule, with restore drills and email alerts when a backup or drill fails. It has a free plan.

Antananarivo, Madagascar - October 20, 2026

pgCluu

PostgreSQL Cluster Utilization

pgCluu is a Perl program used to perform a full audit of a PostgreSQL Cluster performances. It is divided in two parts, a collector used to grab statistics on the PostgreSQL server using psql and sar, a reports builder that will generate all HTML and charts output.

Version 6.0 of pgCluu have been released, this is a major release that adds several new features and reports. It also fixes issues reported since the last release.

New features:

• Add report about replication slots retrieved from pg_replication_slots.
• Add collect of pg_hba_file_rules
• Limit wait event reporting to those that represent more than 0.1 percent of the total of the wait event observed.
• Add collect of I/O statistics from pg_stat_io (PG16+)
• Add reports about:
  • I/O throughput per backend type
  • shared buffers writers and evictions
  • buffer hit ratio and ring buffers
  • I/O latency and size
  • WAL I/O
  • temporary relations I/O
  • asynchronous I/O (PG18+)
• Add collect more kernel tuning parameters, remove shmmax and shmall
  • vm.dirty_expire_centisecs and vm.dirty_writeback_centisecs, they were not matched by the sysctl filter, and all other vm.dirty_* parameters,
  • vm.min_free_kbytes, vm.watermark_scale_factor and kernel.numa_balancing,
  • net.core.somaxconn, net.ipv4.ip_local_port_range, net.core.rmem_max, net.core.wmem_max, fs.file-max and fs.nr_open,
  • /sys/kernel/mm/transparent_hugepage/shmem_enabled: PostgreSQL shared memory is anonymous shared memory, this is the setting that applies to the shared buffers, not 'enabled',
  • the frequency governor of all CPUs instead of cpu0 only, the cpuidle driver, the intel_pstate status and energy performance preference, and the number of NUMA nodes,
  • read_ahead_kb, nr_requests, max_sectors_kb and wbt_lat_usec of each block device.
• Collect and report the limits of the postmaster process. pgcluu_collectd now saves in a new POSTMASTER section of sysinfo.txt:
  • the pid of the postmaster, found as the parent of the checkpointer (its /proc entry is readable by any user) or read from postmaster.pid before PostgreSQL 10,
  • oom_score_adj, -1000 is recommended for the postmaster,
  • the soft and hard limits of open files, processes and locked memory,
  • the cgroup limits: memory.max, memory.high, memory.swap.max, cpu.max, cpu.weight, io.max, pids.max and the oom/oom_kill counters of memory.events with cgroup v2 (also in hybrid mode), memory and cpu quota limits with cgroup v1. pgcluu and pgcluu.cgi show them in the Kernel panel of the system information with sizes and CPU quotas formatted, and a tooltip for oom_score_adj and the process limits.
• Add kernel pressure stall information and memory events reports. pgcluu_collectd now appends at each run to kernel_stats.csv the cumulative counters of:
  • the pressure stall information (PSI) of the host (/proc/pressure, kernel 4.20+) and of the cgroup v2 of the postmaster (cpu, memory and io pressure),
  • the memory events of the cgroup of the postmaster (high, max, oom and oom_kill from memory.events),
  • /proc/vmstat counters not reported by sar: direct reclaims (allocstall), memory compaction, transparent huge pages allocations and fallbacks, OOM kills, NUMA allocations and page cache refaults.
  • pgcluu and pgcluu.cgi have two new pages in the System menu:
  • Pressure stall information: percentage of time with some or all tasks stalled on CPU, memory or I/O for the host and the PostgreSQL cgroup,
  • Kernel memory events: allocation stalls and compaction, transparent huge pages, OOM kills, cgroup memory events, page cache refaults and NUMA allocations.

See ChangeLog for a complete list of changes, bug fixes and acknowledgements.

About pgCluu:

The goal of this project is to provide a complete PostgreSQL auditing tool that don't need any dependency to be run easily to audit a local or remote server.

If you just have a sar output file, pgCluu can be use to draw graphs about the system utilization only.

Credits

pgCluu is an original collection of tools built during my work at Dalibo and HexaCluster. The tools are published under the PostgreSQL License.

pgCluu is created and maintained by Gilles Darold. Any contribution to build a better tool is welcome. You can send your ideas, features requests or patches using the GitHub tools.

Links

View a sample report at http://pgcluu.darold.net/example/index.html

• Web site: http://pgcluu.darold.net/
• Download: https://github.com/darold/pgcluu/releases
• Development: https://github.com/darold/pgcluu
• Documentation: https://github.com/darold/pgcluu/blob/master/README

The SLES 15.6 repositories are being retired from the main PostgreSQL RPM repository, and are moved to the PostgreSQL ZYPP archive .General support for SUSE Linux Enterprise Server (SLES) 15 SP6 (15.6) ended on December 31, 2025 (by upstream).

All PostgreSQL major versions that were built for these minor releases are available there, including PostgreSQL 18.

If you are still on SLES 15.6 either update to a newer SP (SP7 at the time of this writing), or use the archive. The archived repositories section of the repository packages page generates the repository file and the install commands for each distribution version, architecture and PostgreSQL version:

https://zypp.postgresql.org/repopackages/#archivedrepos

Please note that these repos will not receive further updates.

If you have any questions, please either email to pgsql-pkg-yum@lists.postgresql.org, or create a ticket at our issue tracker .

We are happy to announce that FOSSASIA PGDay returns to Thailand on 9 March, 2027, bringing the PostgreSQL community together at True Digital Park, Bangkok. Visit the PGDay website for more details.

About Event

FOSSASIA PGDay is an annual gathering for PostgreSQL users, developers, and enthusiasts, bringing together the community from across Asia and beyond. Co-located with the FOSSASIA Summit, the event provides a focused forum for sharing knowledge, practical experiences, and insights into PostgreSQL and its growing ecosystem. Previous editions have taken place in Singapore, Vietnam, Thailand, and Indonesia, connecting local communities with contributors, users, and organizations from around the world.

FOSSASIA PGDay highlights PostgreSQL in real-world applications and its role as a scalable, secure, and cost-effective open-source data platform. It also creates opportunities to build connections within the PostgreSQL community and the wider open-source ecosystem.

Call for Proposals

The CFP is open until November 30, 2026. Slots are limited, so early submissions are encouraged. 👉 Submit your proposal here

Key Topics

FOSSASIA PGDay features a single-track program, giving all participants the opportunity to follow the same talks and discussions throughout the day. Following the technical program, a social event will provide an opportunity for community networking, informal discussions, and collaboration in Bangkok.

We welcome proposals on topics including:

• PostgreSQL development and administration
• Performance, scaling, and high availability
• Security and reliability
• Cloud, containers, and infrastructure
• Data engineering and analytics
• Extensions and ecosystem tools
• Migration and modernization
• Real-world deployments and case studies
• PostgreSQL community and adoption

Call for Sponsors

PGDay is made possible through the support of sponsors. We invite you to share the prospectus with your company or contacts. For questions or to discuss sponsorship opportunities, please feel free to get in touch. 👉 View the Sponsorship Prospectus

The RHEL 10.0 and RHEL 9.6 repositories are being retired from the main PostgreSQL RPM repository, and are moved to the PostgreSQL YUM archive .

All PostgreSQL major versions that were built for these minor releases are available there, including PostgreSQL 18.

The rolling EL-10 and EL-9 repository RPMs are not affected.

If you are still on RHEL 10.0 or 9.6 (or on Rocky Linux / AlmaLinux 10.0 or 9.6), please either update to a newer minor release, or use the archive. The archived repositories section of the repository packages page generates the repository file and the install commands for each distribution version, architecture and PostgreSQL version:

https://yum.postgresql.org/repopackages/#archivedrepos

Please note that these repos will not receive further updates.

If you have any questions, please either email to pgsql-pkg-yum@lists.postgresql.org, or create a ticket at our issue tracker .

October 18, 2026: The pgBackRest community is pleased to announce the release of pgBackRest 2.60.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

• Add checksum-page-error option to error on invalid page checksums (Andrew Pogrebnoi)
• Support for GCS Workload Identity Federation (Adol Rodriguez)
• Prefetch multi-file/range reads from object stores (David Steele)
• Reduce keep-alive requests to remote processes (David Steele)
• Retry Azure batch sub-requests missing from the response (David Steele)
• Reduce the manifest checks made when reconstructing backup.info (David Steele)
• Support building on illumos (Kalevi Kolttonen)
• Support OpenSSL 4 (David Steele)
• Modernize the website (David Steele, Jan Wieremjewicz)

See the 2.60.0 Release Notes for additional features and improvements.

Important Notes

• The restore command will now error and stop if any restored file contains an invalid page checksum, which leaves the cluster incomplete and unable to start, so the restore must be rerun. The expire command will now refuse to expire if the oldest retained backup would contain checksum errors, which also prevents archive from being expired in that repository. Set checksum-page-error=n to warn instead of erroring.
• Building from a git checkout requires PyYAML instead of libyaml. The distribution tarball includes the generated code and requires neither.
• PostgreSQL 19rc1 is supported by v2.59.2 and later, including this release.

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.

Join us for FOSDEM PGDay 2027 on January 28 and 29 at the Brussels Marriott Hotel Grand Place.

This year, we're expanding to two days, bringing you more PostgreSQL talks and more time to connect with fellow enthusiasts from around the world. Start your FOSDEM trip with dedicated PostgreSQL content, then enjoy the main FOSDEM event over the weekend!

- New for 2027: sponsor the event -

For the first time, we're offering sponsorship opportunities for FOSDEM PGDay!

Our Platinum, Gold and Silver packages offer different ways to get involved. Platinum and Gold packages include an exhibition desk and a sponsor-track talk.

Explore the sponsorship opportunities and find the right package for you.

- Call for Papers -

Our Call for Papers is now open!

Talks will be 45 minutes, followed by time for questions, and must be presented in English. Selected speakers receive free admission to the conference.

Read the Call for Papers and submit your proposal by 2026-12-01 23:59:59 CET.

We look forward to seeing you in Brussels for two days of PostgreSQL!

The pg_hint_plan development team is pleased to announce pg_hint_plan 1.9.0. This release of pg_hint_plan adds compatibility with PostgreSQL 19, and includes various improvements and bug fixes. For more details, see the release notes. This new major version includes support for path generation strategies (PGS).

pg_hint_plan is a PostgreSQL extension that offers the possibility to tweak PostgreSQL execution plans using so-called "hints" in SQL comments. For more information, see the project page.

The documentation of the project is published at this page, and is synced up automatically from the source repository.

A new set of minor releases is available down to PostgreSQL 14, each marked with the following versions:

• pg_hint_plan 1.8.1, compatible with PostgreSQL 18.
• pg_hint_plan 1.7.2, compatible with PostgreSQL 17.
• pg_hint_plan 1.6.3, compatible with PostgreSQL 16.
• pg_hint_plan 1.5.4, compatible with PostgreSQL 15.
• pg_hint_plan 1.4.5, compatible with PostgreSQL 14.

This is the last release planned for PostgreSQL 14.

Notable changes in this set of releases include the following bug fixes, where applicable:

• Fix infinite loop with hint parser and multi-query strings
• Add CHECK_FOR_INTERRUPTS() in get_hints_from_comment()
• Ignore indexes without a name, like hypothetical indexes
• Fix server crash when HintStateDump[2] throws an ERROR
• Restore query ID after SPI execution in get_hints_from_table()
• Correct schema-qualification of operators for hint table query
• Add PG_MODULE_MAGIC_EXT
• Update Japanese documentation

Antananrivo, Madagascar - October 14, 2026

PostgreSQL credcheck extension

The credcheck PostgreSQL extension provides few general credential checks, which will be evaluated during the user creation, during the password change and user renaming. By using this extension, we can define a set of rules:

• allow a specific set of credentials
• reject a certain type of credentials
• deny password that can be easily cracked
• enforce use of an expiration date with a minimum of day for a password
• define a password reuse policy
• define the number of authentication failure allowed before a user is banned
• define a delay on authentication failures
• force users to change their password after first login
• throw a warning N days before when the password user is about to expire
• prohibit password changes
• last login and boot/shutdown information
• use of authentication failure with PgBouncer

Release 6.0 has been published,

This major release adds some new features and fix issues reported by users since last release.

• Allow integration of the max_auth_failure feature with pgbouncer. See documentation.
• Allow use of password_change_first_login with pgBouncer.
• Add credcheck.password_valid_min setting to force a short VALID UNTIL window on newly created roles. Useful to force new users to change their password quickly when the client (DBeaver, pgAdmin, ...) does not support the error reported when credcheck.password_change_first_login is enabled.
• Add an optional last-login history modelled on the Unix last(1)/wtmp. Records user sessions (name, login time, duration, backend pid, source IP and port, and optionally the last SQL query) plus PostgreSQL boot/shutdown/crash markers.
• Change the behavior of the credcheck.no_password_logging to not hide the error statement anymore but instead to replace every PASSWORD '<literal>' clause with dots inplace of the literal to not expose the password in the log.
• Add function pg_check_password( IN username name, IN password text ) to check a candidate password (and the associated username) against the credcheck username/password policy without creating or altering a role.
• Fix privilege escalation via self ALTER ROLE when password_valid_until is set.
• Fix memory leaks and a heap overflow.

Upgrade require a PostgreSQL restart to reload the credcheck library.

Complete list of changes and acknowledgements are available here

Links & Credits

credcheck is an open project under the PostgreSQL license maintained by HexaCluster. Any contribution to build a better tool is welcome. You can send your ideas, features requests or patches using the GitHub tools.

Links :

• Download: https://github.com/HexaCluster/credcheck/releases/
• Support: use GitHub report tool at https://github.com/HexaCluster/credcheck/issues

About credcheck

The credcheck extension is developed and maintained by Gilles Darold at https://hexacluster.ai. If you need more information please https://hexacluster.ai/contact-us/.

Documentation at https://github.com/HexaCluster/credcheck#readme

Antananarivo, Madagascar - October 06, 2026

PostgreSQL UTL_SMTP compatibility extension

pg_utl_smtp is a PostgreSQL extension to create, manage and use Oracle-style UTL_SMTP package. The use and behavior is just like with the UTL_SMTP Oracle package. This work is released from the HexaRocket project.

This extension allows email notifications to be sent from triggers or stored procedures. By integrating the extension directly into the database, you can trigger data-driven actions without waiting for application intervention. Examples include security alerts or notifications when certain minimum thresholds are reached.

pg_utl_smtp v2.0.0 has been released, this new major version adds an asynchronous mode with setting pg_utl_smtp.asynchronous enabled. The Oracle version doesn't support asynchronous mode but this feature can be useful if you want to port the MSSQL sp_send_dbmail() procedure using pg_utl_smtp.

Other changes in this release:

• Raise an error when the SMTP server returns an error to HELO/EHLO, MAIL, RCPT, DATA, end of DATA or QUIT.
• Fix duplicate EHLO sent at connection
• Implement SSL/TLS connections (secure_connection_before_smtp).
• QUIT releases the connection, a second QUIT raises an error.
• When the connection can not be established the WARNING gives the reason.
• Add regression tests by GitHub Actions.

To upgrade an installed version 2.0.0 execute:

  ALTER EXTENSION pg_utl_smtp UPDATE;

This extension uses plperl stored procedures based on the Net::SMTP Perl module to provide the procedures of the UTL_SMTP package.

Links & Credits

pg_utl_smtp is an open project under the PostgreSQL license created by Gilles Darold at HexaCluster Corp. as part of the HexaRocket migration solution. Any contribution to build a better tool is welcome. You can send your ideas, features requests or patches using the GitHub tools.

Links :

• Download: https://github.com/HexaCluster/pg_utl_smtp/releases/
• Support: use GitHub report tool at https://github.com/HexaCluster/pg_utl_smtp/issues

About pg_utl_smtp

The pg_utl_smtp extension is an original work of HexaCluster Corp., HexaCluster is specialized in migration to PostgreSQL and PostgreSQL support. If you need more information please contact us

Documentation at https://github.com/HexaCluster/pg_utl_smtp#readme

The PostgreSQL Global Development Group announces that the first release candidate of PostgreSQL 19 is now available for download. As a release candidate, PostgreSQL 19 RC 1 will be mostly identical to the initial release of PostgreSQL 19, though some more fixes may be applied prior to the general availability of PostgreSQL 19.

The next scheduled update release for supported versions of PostgreSQL, on November 12, 2026, will include a large number of fixes. Because of this, the release team decided to include these fixes in PostgreSQL 19 before its general availability. This means a second release candidate, PostgreSQL 19 RC 2, will be available on the same day as the update release.

The planned date for the general availability of PostgreSQL 19 is November 19, 2026. Please see the "Release Schedule" section for more details.

Upgrading to PostgreSQL 19 RC 1

To upgrade to PostgreSQL 19 RC 1 from earlier versions of PostgreSQL, you will need to use a major version upgrade strategy, e.g. pg_upgrade or pg_dump / pg_restore. For more information, please visit the documentation section on upgrading:

https://www.postgresql.org/docs/19/upgrading.html

Changes Since 19 Beta 4

Several bug fixes were applied to PostgreSQL 19 during the Beta 4 period. These include:

• Several fixes for REPACK (CONCURRENTLY).
• Several fixes for pg_plan_advice.
• Several fixes for new query planner optimizations that rely on whether an expression can be NULL.
• Several fixes for the automatic enablement of logical replication when wal_level is set to replica.
• Fix postgres_fdw statistics import to run as the owner of the foreign table instead of the user running ANALYZE.
• Several fixes for parallel autovacuum.
• Fix COPY (query) TO ... (FORMAT json) to use the query's column names, including aliases, as the JSON keys instead of the table's column names.

For a detailed list of fixes, please visit the open items page.

Release Schedule

This is the first release candidate for PostgreSQL 19. The release team plans to issue a second release candidate, PostgreSQL 19 RC 2, on November 12, 2026. Unless an issue is discovered that requires a delay or an additional release candidate, PostgreSQL 19 should be made generally available on November 19, 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

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

I am very pleased to announce that, after a long hiatus, Perseid 0.1.0, a set of utilities for versioning PostgreSQL database schemas, has been released.

Perseid 0.1.0 is available from:

• Codeberg
• Git repository: https://codeberg.org/perseas/perseid

Documentation is available at: https://perseas.codeberg.page/perseid/

Perseid is the successor to Pyrseas. It provides dbtoyaml and yamltodb to extract a PostgreSQL database schema as YAML and to generate or apply SQL to bring a target database into agreement with a YAML specification.

This initial release supports SQL SCHEMAs, TABLEs, COLUMNs and CONSTRAINTs. PostgreSQL 17 or higher is required.

Many thanks to those who contributed code, ideas, and discussions to make this first release possible.

Best wishes,

Joe Abbate

The psqlODBC team has released version 18.00.0005 of psqlODBC, the official ODBC driver for PostgreSQL. This release fixes one security vulnerability and two bugs. All users should upgrade.

Security issue

CVE-2026-109448: heap memory corruption when binding more than 32767 parameters

CVSS 3.1 base score: 5.9 (Medium)

Versions affected: 08.01.0102 through 18.00.0004.

psqlODBC stored the number of bound parameters on a statement in a signed 16-bit field. When an application bound more than 32768 parameters on one statement, the driver wrote zeros outside the memory that holds the parameter bindings. The application could crash, or keep running with corrupted memory. An application is exposed if it lets untrusted input decide how many parameters it binds, for example by building an IN (?, ?, ...) list from user-supplied values.

SQLBindParameter now rejects parameter numbers above 32767 with SQLSTATE 07009. ODBC cannot report more than 32767 parameters, because SQLNumParams and SQL_DESC_COUNT are 16-bit values. No earlier release could run a statement with more than 32767 parameters, so this change does not break any application that worked before.

If you cannot upgrade right away, limit the number of parameters your application builds from external input, or pass long value lists as a single array parameter, for example = ANY(?).

The psqlODBC team thanks Richard Kuesters for reporting this problem.

For more details, see the advisory GHSA-cmfx-rm3r-p2jr.

Bug fixes

• Statements prepared on the server with 1000 or more parameters could fail with errors such as type "timestam" does not exist. From parameter 1000 on, the driver cut the type name that follows each parameter to fit a fixed-size buffer.
• Since 18.00.0003, bytea parameters failed with "Type is invalid" when used through Microsoft's OLE DB Provider for ODBC (MSDASQL), for example from ADO.

The Windows packages are now built with OpenSSL 3.5.9.

Download

Windows installers and merge modules for x86, x64 and ARM64 are available from the PostgreSQL download site and from the GitHub release page. The source code is on GitHub.

The full list of changes is in the release notes.

Please report bugs on the psqlODBC issue tracker or the pgsql-odbc mailing list.

I’m pleased to announce the first public release of pglifecycle, an open source schema management tool for PostgreSQL.

pglifecycle keeps your database schema in version control as structured YAML, with one file for each table, view, function, role, and other object. This makes the current schema easy to browse, review, and change without reconstructing it from years of migration files.

With pglifecycle, you can:

• Pull an existing database into a schema project
• Build that project into an archive for pg_restore
• Compare it with a live database and generate the DDL needed to reconcile them

Deployment is plan first. Destructive changes are withheld unless explicitly allowed, making the generated SQL suitable for review in CI.

The companion pglifecycle GitHub Action can detect schema drift and post deployment plans directly to pull requests without applying them.

Version 2 is a Rust rewrite of the original tool, which has managed AWeber’s production schema for more than seven years. The beta release expands PostgreSQL object coverage and improves deployment convergence and safety.

• Getting Started
• Documentation
• GitHub Action

Feedback and real world test cases are welcome as pglifecycle moves toward a stable 2.0 release.

PgBouncer 1.26.1 has been released. This release fixes three CVEs:

1. CVE-2026-107350: Authentication bypass, allowing a client that knows the password of one SCRAM user to log in as any other SCRAM user, including admins and backend superusers. Caused by a second StartupMessage being processed during SCRAM authentication when connecting to a non-existent database.
2. CVE-2026-107349: DoS due to infinite loop, triggerable by unauthenticated clients. Caused by an empty option name in the startup options parameter, when ignore_startup_parameters is non-empty but does not contain options.
3. CVE-2026-107348: DoS due to infinite loop, triggerable by unauthenticated clients. Caused by an integer overflow in the packet buffer growth logic, only when max_packet_size is set above its default.

It also makes ignore_startup_parameters take precedence over tracked parameters, so that ignore_startup_parameters = search_path restores the 1.25 behaviour of ignoring search_path.

See https://www.pgbouncer.org/2026/10/pgbouncer-1-26-1 for more information, the detailed changelog, and download links.

The PostgreSQL JDBC team has released a security release for 2 CVE's

CVE-2026-107314 and the GitHub Security Advisory GHSA-rhp9-mr79-r74h and CVE-2026-107315 and the GitHub Security Advisory GHSA-f64h-wr5q-3qf3

See the release notes for details

PGX Inc. has released version 1.0 of pgx-bm25, an extension that adds Okapi BM25 ranked full-text search to PostgreSQL as a native index access method. It supports PostgreSQL 17 and 18, and installs as bm25_native.

CREATE EXTENSION bm25_native;
CREATE INDEX docs_bm25 ON docs USING bm25_native (body);

SELECT id, bm25_score(ctid) AS score
FROM   docs
WHERE  body @@@ 'quick fox'
ORDER  BY body &@@ 'quick fox'
LIMIT  10;

@@@ selects the matching rows and &@@ orders them by relevance. The query runs as an ordered index scan; there is no Sort node.

It is a PostgreSQL index

The whole index lives in the index relation's own pages, so it gets WAL logging, crash recovery, and physical replication from core. VACUUM maintains it. There is no external search engine and no separate runtime to operate. The extension is written in C against the stock server headers and builds with PGXS; a C compiler and pg_config are the whole toolchain.

Text is analyzed with PostgreSQL's own Snowball dictionaries, with the language set per index, so a search for negligent finds negligence. Ranked top-N queries use block-max WAND, so a typical LIMIT 10 search does not have to score every matching document.

Query features

• Multi-column indexes with BM25F scoring: per-field boosts and per-field length normalization. k1, b, and the boosts can be changed with ALTER INDEX ... SET and take effect on the next scan, without a REINDEX.
• Exact phrases, and proximity search by token distance, ordered or unordered.
• Boolean queries (must, should, must_not), nested as needed.
• Prefix wildcards (judg*).
• Query-time boosts on any clause.
• Highlighted snippets with bm25_snippet(), HTML-escaped by default.

Simple searches can be written as a text string. Everything else is composed from builder functions that produce a jsonb query tree, so user input always arrives as a value and never as query syntax:

CREATE INDEX docs_bm25 ON docs
  USING bm25_native (title, summary, body) INCLUDE (id) WITH (key_field = 'id');

SELECT id, bm25_score_key(id) AS score
FROM   docs
WHERE  title @@@ bm25_boolean(
                   must     => ARRAY[ bm25_term('body', 'tort') ],
                   must_not => ARRAY[ bm25_term('body', 'battery') ])
ORDER  BY title &@@ bm25_boolean(
                   must     => ARRAY[ bm25_term('body', 'tort') ],
                   must_not => ARRAY[ bm25_term('body', 'battery') ])
LIMIT  10;

License

pgx-bm25 is released under the PostgreSQL License, the same terms as PostgreSQL itself. It is a standalone project: it does not depend on, or connect to, any other product or service, and there is no separate commercial edition. The source, the regression and TAP test suites, the benchmark scripts, and the design record (an architecture guide and a log of design decisions) are all in the repository.

Upgrades and testing

The on-disk format carries a compatibility contract: additive format changes do not require a REINDEX, and where a breaking change allows it, bm25_upgrade() migrates an index in place. CI builds and tests against PostgreSQL 17 and 18, including assert-enabled, UBSan, and AddressSanitizer runs, plus TAP tests for crash recovery and replica equality. PostgreSQL 19 is tested against the current beta but is not yet a supported major version.

Getting it

make    
sudo make install

Source, documentation, and issue tracker: https://github.com/pgexperts/pgx-bm25

pg_plan_filter version 1.0.0 has been released.

This loadable module test sstatements against specific configured criteria before execution, raising an error if the criteria are violated. This allows administrators to prevent execution of certain queries on production databases.

The criteria are based on the planner's estimated cost. pg_plan_filter can refuse an individual statement whose plan is too expensive (statement_cost_limit), cap the combined cost of all the statements run in one transaction (transaction_cost_limit), and optionally apply the filter to SELECT statements only (filter_select_only). The module could be extended to support further kinds of filters.

It supports PostgreSQL versions 14 through 18.

The release adds a PostgreSQL Debugger, visual editors for event triggers, functions and procedures, as well as file attachments and model choice in dbForge AI Assistant.

Devart, a leading developer of database management software, has released dbForge 2026.2, the latest update to its unified ecosystem of professional database tools. The new version adds a brand-new embedded PostgreSQL Debugger and visual object editors to dbForge Studio for PostgreSQL. dbForge AI Assistant gains broader context awareness through file attachments, supports models from Anthropic and OpenAI, and is now available in a free Express edition. The release also brings SQL refactoring enhancements, quicker access to test data generation, a new “Last modified” column in schema comparison documents and reports, and much more.

Embedded PostgreSQL Debugger helps teams track errors in server-side code

dbForge Studio for PostgreSQL now includes a PostgreSQL Debugger that lets developers set breakpoints, step through code line by line, and monitor variables, expressions and query results as code runs. When an exception occurs, the Debugger highlights the exact line that caused it.

The Debugger is integrated into dbForge Studio for PostgreSQL and requires no separate extensions or manual setup.

Visual editors replace raw code for PostgreSQL object management

The release also introduces visual editors for PostgreSQL event triggers, functions and procedures, so teams can create and modify these objects without writing SQL manually.

"Finding a problem in PostgreSQL code shouldn't mean reading through it line by line and guessing," said Oleksii Honcharov, Head of Engineering at Devart. "Developers should be able to pause execution, watch the data change and see the exact line where something breaks, without installing extensions or configuring anything first. Functions, procedures and event triggers deserve the same treatment: teams should be able to build them visually, not only in raw code. dbForge 2026.2 puts all of that inside dbForge Studio for PostgreSQL."

dbForge AI Assistant gains broader context awareness

dbForge 2026.2 expands the context available to dbForge AI Assistant. Users can attach the active SQL document, scripts, application code, database projects, diagrams, or custom instructions instead of pasting code into prompts. Teams can supply sample code, so the Assistant generates SQL that follows their coding standards, attach several databases to one chat, or ask the Assistant to compare two scripted databases.

Users can also choose the model behind dbForge AI Assistant: Claude Haiku 4.5, Claude Sonnet 4.6 or Claude Sonnet 5 from Anthropic, or GPT-5.4 and GPT-5.6 from OpenAI.

“AI is most useful when it understands the context in which developers work,” said Honcharov. “The latest improvements to dbForge AI Assistant give users more control over that context, from active documents and file attachments to saved instructions and model selection. Our goal is to make AI assistance more relevant and flexible across the database development workflow.”

dbForge AI Assistant introduces a free Express edition

Developers can now bring AI assistance into their SQL development without a paid plan. The new free Express edition of dbForge AI Assistant includes a limited token allowance and retains the chat history for 14 days. Paid plans offer a larger token allowance and an unlimited chat history.

SQL development and schema comparison improvements

New refactoring commands in dbForge SQL Complete and dbForge Studio for SQL Server, MySQL, and Oracle apply object and column name qualification and expand wildcards in the existing SQL code. Users can also launch test data generation directly from Database Explorer.

Schema comparison documents and reports in dbForge tools for SQL Server and Oracle now include a new “Last modified” column. All dbForge tools for MySQL now support MySQL 26.7 and MariaDB 13.x.

Availability

dbForge 2026.2 has already been rolled out. Current users can install the update directly from their dbForge products via Help > Check for Updates. New users can download any dbForge product for free, and it will be already up to date.

For more information about dbForge 2026.2, visit: https://www.devart.com/blog/whats-new-in-dbforge-2026-2-2.html.

dbForge 2026.2 FAQ

What is dbForge 2026.2?

dbForge 2026.2 is the latest update to dbForge, Devart's AI-powered ecosystem of database tools for SQL Server, MySQL, MariaDB, Oracle and PostgreSQL. It adds a built-in PostgreSQL Debugger, as well as file attachments, model choice, and a separate free Express edition in dbForge AI Assistant.

Who is dbForge 2026.2 for?

The release is designed for database developers, architects, and analysts. Its PostgreSQL-focused features are aimed at teams that write and maintain server-side code.

Is dbForge AI Assistant free?

dbForge AI Assistant is available in a free Express edition with a limited token allowance and a 14-day chat history. Paid plans offer a larger token allowance and an unlimited chat history.

Which AI models does dbForge AI Assistant support?

dbForge AI Assistant provides access to the following models: Claude Haiku 4.5, Claude Sonnet 4.6 or Claude Sonnet 5 from Anthropic, or GPT-5.4 from OpenAI.

About Devart

Devart is a global leader in data management, connectivity, and integration solutions. Our mission is simple: to enable customers to manage data easily and effectively at an affordable cost. Over the past 29 years, we’ve built a rich ecosystem of database solutions. Today, more than 500,000 users, including 65% of Fortune 100 companies, rely on our products.

For more information, visit www.devart.com.

Media Contact

Jordan Sanders
Devart
Email: jordan.sanders@devart.com
Website: www.devart.com

Version 1.7.2 of pg_vault_tde is now available. This is a binary patch release where extension version stays at 1.7, but users can distinguish the build at runtime using pg_vault_tde_build_version().

This update focuses on critical stability, security, and correctness fixes:

• New On-Disk Tuple Layout (v5): Introduces a walkable structure to fix a critical segmentation fault on UPDATE operations for tables with indexed variable-length columns (PSQLE-165).
• TOAST Crash Resolved: Fixes a segfault triggered when values crossed the TOAST_TUPLE_THRESHOLD only after being encrypted. Furthermore, a bug where an all-NULL row made its table unreadable has been fixed.
• tde_btree Hardening: The tde_btree index now strictly answers equality queries only, preventing incorrect row returns on range operators, ORDER BY, or merge joins (PSQLE-173).
• Key Management & Reliability: Addresses data loss and corruption vulnerabilities in rotate_online() concurrent access (PSQLE-184), local wallet KEK rotation (PSQLE-185), and vault-to-wallet migrations (PSQLE-188).
• WAL & Logical Decoding: Fixes memory accounting drift in logical decoding (PSQLE-186) and moves the Custom WAL resource manager ID from 128 to the registered ID 161 (PSQLE-172).
• New script/checking improvement : The development process now includes ASan testing, Semgrep security checks, extended soak testing, and release signing with a generated SBOM (PSQLE-180, PSQLE-181, PSQLE-182).

Critical Upgrade Instructions:

• Due to the WAL resource manager ID change, the upgrade requires a clean shutdown. If toast_custom_rmgr is turned on, the primary and standbys must be upgraded together, as a rolling upgrade is not possible.
• Users must run VACUUM FULL on every encrypted table after the upgrade. Existing rows in the v4 format remain readable but will crash on UPDATE until they are rewritten to the v5 layout.

For a complete list of fixes and detailed upgrade procedures, please refer to the ROADMAP.md file.

pgvector 0.8.7 is now available. This release fixes a buffer overflow with IVFFlat index builds (CVE-2026-103484), which can lead to arbitrary code execution. Users are encouraged to upgrade when possible.

More details: https://github.com/pgvector/pgvector/issues/1036

pgvector is an open-source PostgreSQL extension that provides vector similarity search capabilities

IVM Development Group is pleased to announce the release of pg_ivm 1.16.

Changes since the v1.15 release include:

What's Changed

New features

• Add support for PostgreSQL 19 ( Devrim Gündüz )

Bug fixes

• Fix a segfault when an IMMV is maintained and dropped in the same transaction (Yugo Nagata)

• Fix IVM maintenance for tables without default equality operators (Yugo Nagata)

  When a base table contained a type without a default equality operator, maintenance of the views failed when the table was updated, even if the column was not referenced by the view definition.

• Fix OID handling when OID exceeds INT_MAX (Artur Aleksander Kanošin)

  View maintenance failed when the global OID counter exceeds INT_MAX.

• Prevent spurious transaction failures during incremental maintenance (Dzmitry Levankou)

  During incremental maintenance, locks are acquired on the materialized view to prevent anomalies caused by concurrent maintenance. Previously, due to the timing of lock release during commit, a transaction could fail unnecessarily with a lock error even though no concurrent incremental maintenance was actually in progress. This issue could also make isolation tests fail intermittently under load.

About pg_ivm

pg_ivm is an extension module that provides Incremental View Maintenance (IVM) feature.

Incremental View Maintenance (IVM) is a way to make materialized views up-to-date in which only incremental changes are computed and applied on views rather than recomputing. pg_ivm provides a kind of immediate maintenance, in which materialized views are updated immediately after a base table is modified.

Source repository: https://github.com/sraoss/pg_ivm

What is Pgpool-II?

Pgpool-II is a tool to add useful features to PostgreSQL, including:

• connection pooling
• load balancing
• automatic failover and more.

Minor releases

Pgpool Global Development Group is pleased to announce the availability of following versions of Pgpool-II:

• 4.7.3
• 4.6.8
• 4.5.13
• 4.4.18
• 4.3.21

These releases include security fixes.

• A vulnerability in watchdog message processing during failover in Pgpool-II allows an attacker to write an arbitrary 32-bit value to an arbitrary memory address by sending a malformed message. (CVE-2026-92867)

• When a client connects to Pgpool-II using certificate authentication, Pgpool-II does not properly handle NUL bytes (\0) in the domain name in the Common Name (CN) field of the client's X.509 certificate. This vulnerability allows a malicious client to connect to the Pgpool-II server as another user without a password. (CVE-2026-92868)

• A vulnerability in watchdog message processing in Pgpool-II allows an attacker to overwrite memory beyond the boundaries of fixed-size arrays by sending a malformed message. (CVE-2026-92869)

• A vulnerability in the handling of failover messages by watchdog in Pgpool-II allows writes of arbitrary-length data to corrupt the stack and crash a Pgpool-II process. (CVE-2026-92870)

• A NULL pointer dereference vulnerability exists in watchdog inter-node authentication in Pgpool-II. When an authentication key is configured, crafted watchdog messages that omit authentication information are not handled correctly. (CVE-2026-92871)

• An information disclosure vulnerability exists in the heartbeat receiver process of Pgpool-II. (CVE-2026-92872)

• A vulnerability in watchdog promotion processing in Pgpool-II allows an attacker to bypass authentication key checks and promote a watchdog node of their choice to leader. (CVE-2026-92873)

For more details please see the release notes.

You can download the source code and RPMs.

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, and no extension beyond the ones you already have.

One instance serves many clusters and all of their replicas. Most PostgreSQL statistics are per-instance and are not replicated, so 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.

New since the last announcement

• Index recommendations. Dasha reads pg_stat_statements on every host of a cluster and proposes the B-tree indexes that are missing. Each candidate comes with its column order, a ready CREATE INDEX CONCURRENTLY, the statements it covers and their share of execution time. Write counters and partitioned tables (ATTACH PARTITION) are taken into account. A candidate can be backed by auto_explain plans from the log: sequential scans of its table, what they cost and how many rows their filters discarded. A misestimated row count raises a warning to run ANALYZE first.
• I/O page built on pg_stat_io (PostgreSQL 16+). Server I/O is broken down by backend type, object and context (normal, vacuum, bulkread, bulkwrite), with WAL on PostgreSQL 18. There is a live mode and snapshot history, and cards for shared_buffers efficiency, vacuum cost and bulk operations.
• Schema checks. 17 checks for structural defects that stay invisible until something breaks, including sequences close to exhaustion, tables without a primary or unique key, forgotten UNLOGGED relations, a public schema anyone can create objects in (CVE-2018-1058), UUIDs stored as varchar, nullable foreign keys, NOT VALID constraints that were never validated and reserved keywords used as names. Each finding has a severity and remediation SQL.
• Log insights. Log search now works with OpenSearch, Elasticsearch and VictoriaLogs, as well as Yandex Managed PostgreSQL. A time window is grouped into event categories (deadlocks, lock waits, cancellations, checkpoints, autovacuum, temp files, errors) with frequent message templates. auto_explain plans are grouped by statement and plan shape. The plan tree flags sequential scans of large tables, row estimates that are off by orders of magnitude and sorts that spilled to disk. Comparing two windows lists the statements whose plans got worse.
• Per-database query analysis. The query report and the Top 10 panels switch between the current database and the whole instance.
• Postgres Pro support. When pg_stat_statements is not available, Dasha reads pgpro_stats, with no configuration needed.
• Automatic database discovery. Dasha asks the cluster for its database list and keeps it current.

Features

• Health Score: a composite 0-100 score per instance across eight categories, with prioritized recommendations tied to a specific database. Optionally computed from Prometheus/VictoriaMetrics time series, with a trend and a seasonal baseline.
• Query analysis: top queries by execution time and WAL, running and blocked queries with wait events, and pg_stat_statements snapshots. Snapshots 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 instance-wide lock-contention snapshots on activity spikes or primary/replica role changes. The evidence is there the next morning when someone asks what happened at 03:00.
• Index analysis: bloat, duplicates, invalid indexes and B-tree on arrays. It also answers "may I drop this index?", accounting for statistics resets, per-host counters and partitioned indexes rather than trusting idx_scan = 0.
• Tables and maintenance: size with a TOAST breakdown, per-table describe, and autovacuum and wraparound thresholds computed with PostgreSQL's own formula. Also vacuum progress, and hot tables and indexes derived from scheduled delta snapshots.
• Locks, waits, connections: lock trees, wait events grouped by type, connection states and sources, and 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 gives AI assistants the fleet diagnostics. It has 31 tools, including index recommendations, schema checks, I/O, log search and plan regressions. It also has 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 on every monitored database.
• pg_stat_statements (or pgpro_stats on Postgres Pro) for query statistics; pgstattuple is optional.
• The I/O page requires PostgreSQL 16 or newer.
• Optional: a log source (OpenSearch, Elasticsearch, VictoriaLogs or Yandex Managed PostgreSQL) for log search and plan insights, with auto_explain enabled for plan analysis.
• Optional: a separate PostgreSQL database for snapshots, hot-object history and personal access tokens. Everything else works without it.

Documentation

• README: configuration, monitoring role privileges, deployment, Helm values
• Health Score scoring model
• Changelog

ALEXANDRIA, Va. — Sept. 28, 2026 — pgEdge, the leading open source Postgres company for agentic AI and enterprise applications, today announced pgEdge Starfleet, a new Postgres cloud database platform built to bridge the widening chasm between enterprise AI prototypes and actual AI production applications. pgEdge Starfleet is the first 100% Postgres cloud database platform to combine a smooth developer experience and comprehensive agentic AI tooling with flexible deployment options (including on-premises), data sovereignty, and the ability to scale to highly available, zero-downtime multi-region clusters.

According to research by IDC and Lenovo, only 46% of general AI and agentic AI prototypes reach production, and 82% of organizations need to leverage hybrid or on-premises environments for AI workload deployment. Often, the underlying data infrastructure platforms used for prototyping were never designed to meet stringent enterprise requirements such as security, compliance, high availability, reliability and data sovereignty, including the ability to deploy on-premises, air-gapped or in a private cloud, with full control over where data lives. Nevertheless, developers have been attracted to these platforms because of the ease of getting started, the developer experience, and their support for agentic AI applications. pgEdge Starfleet closes the AI prototype-to-production gap by combining the experience and features developers love with the capabilities and deployment flexibility enterprises demand.

“Business teams can now use AI coding agents to build apps without waiting on IT,” said Mike Leone, VP and principal analyst at Moor Insights & Strategy. “Once one of those apps moves to production, its database needs the same security and uptime standards as any other core system.” “pgEdge Starfleet allows developers to build at AI speed and then deploy anywhere, without finding themselves at an architectural dead end,” said Phillip Merrick, CEO of pgEdge. “Only with pgEdge Starfleet is it possible to start for free with a single small Postgres instance, then scale all the way up to multi-region clusters running on our cloud, your cloud or on your own on-premises infrastructure.”

What Sets pgEdge Starfleet Apart

• Comprehensive Agentic AI tooling. pgEdge Starfleet incorporates the pgEdge Agentic AI Toolkit for Postgres, which includes a full-featured MCP server, making it easy to connect agentic code generators such as Claude Code, Replit and Cursor. A dedicated RAG API server supports retrieval-augmented generation (RAG) of text based on content within a PostgreSQL database, using pgvector. A PostgREST API server supports database access directly from browser clients using PostgREST, a pattern popular with certain agentic code generators like Lovable.

• True copy-on-write fast database branching. pgEdge Starfleet provides true copy-on-write database branching to support parallel agentic experiments in addition to easing support for separate development, testing and staging databases, or aligning with branches in GitHub source code repositories. Unlike other solutions, pgEdge has implemented this capability without replacing the Postgres storage layer with its own proprietary or semi-proprietary storage layer.

• Smooth developer experience. Initial sign-up for a free trial — without a credit card — and creation of your first database takes under two minutes. Connect to your database instance right away. Easily add MCP and RAG servers, and optionally enable PostgREST API access to your database. Add a credit card and select your instance size. Pricing is simple, flat and predictable, and starts at $25/month.

• Flexible deployment options. Developers start fast on pgEdge-hosted infrastructure, then choose to deploy in production either on the pgEdge Cloud, the enterprise’s own tightly controlled cloud, or on on-premises infrastructure, even if air-gapped. When deploying on-premises or self-hosted via pgEdge Enterprise Postgres, customers can utilize pgEdge’s curated array of platform binaries — compiled, tested and validated for their specific hardware and OS environment. No other vendor offers this choice, allowing customers to meet their data sovereignty requirements while running applications on the same identical Postgres platform across cloud and on-premises.

• Secure by default. pgEdge has drawn on years of working with some of the largest and most demanding enterprise Postgres users to design pgEdge Starfleet as “secure by default.” This includes ensuring users’ database infrastructure is not wide open to the internet by default, relying on IP allowlisting to restrict access to authorized applications. The MCP server integrated into pgEdge Starfleet incorporates numerous security and governance guardrails, including the ability to ensure read-only connections are truly read-only via pgEdge SafeSession. Global scalability. Developers can start with a single instance of Postgres, scale through an array of ever larger compute sizes, then ultimately grow to a multi-region cluster for high availability and zero downtime.

• 100% pure open source Postgres. pgEdge Starfleet utilizes pgEdge Enterprise Postgres, which itself is 100% based on standard community Postgres. All included pgEdge and third-party-developed extensions are open source under the PostgreSQL license or OSI-approved equivalent. The source code for pgEdge developed extensions is available at the pgEdge GitHub page, https://github.com/pgedge. Supported by people who help build Postgres itself. Members of the pgEdge team are active members of the Postgres community and include a core team member, major and significant contributors, authors of popular Postgres books, and board members of the regional Postgres community associations in North America and Europe.

“AI is core to our business, so we need infrastructure that lets developers move fast without adding complexity,” said Arnaud Jaspart, CTO, Enquire AI. “pgEdge gives us a familiar, standard Postgres experience with built-in AI capabilities like RAG and MCP, which makes working with agents simpler and safer. We run pgEdge in a hybrid cloud environment, which gives us control over where our data resides and how it is managed. We also have the flexibility to use managed cloud, customer cloud or on-premises deployments as our needs change.”

Availability

pgEdge Starfleet is available now, and users can sign up for a free 14-day trial at www.pgedge.com/products/starfleet.

Documentation is available at docs.pgedge.com. To learn more, watch the brief pgEdge Starfleet Quickstart video at www.youtube.com/watch?v=XSDZHfW-5XM.

About pgEdge

pgEdge, the leading open source enterprise Postgres company for AI, delivers 100% Postgres infrastructure for agentic AI and other enterprise applications that demand high availability, reliability and data sovereignty. Our mission is to make it easy to build, deploy and manage enterprise-grade AI and other applications at scale on Postgres. pgEdge is trusted by organizations including Bertelsmann, Qube RT, Thales, and U.S. government agencies. Our team are active members of the Postgres community and include a core team member, significant contributors, members of the PgUS, PGCA and PGEU boards, along with conference and user group organizers. For more information, visit www.pgedge.com and follow the company on LinkedIn.

Note: PostgreSQL is a trademark of the PostgreSQL Community Association of Canada. All other trademarks are the property of their respective owners.

Tags: pgEdge, pgEdge Starfleet, Postgres, PostgreSQL, pgEdge Enterprise Postgres, pgEdge Cloud, pgEdge Agentic AI Toolkit for Postgres, AI, artificial intelligence, agentic AI, developers, open source, data sovereignty, Phillip Merrick

Media Contact

Dottie O’Rourke, for pgEdge TECHMarket Communications 650-344-1260 pgEdge@techmarket.com

We are pleased to announce the release of version 6.0 of the PL/Haskell extension. This extension allows users to write PostgreSQL functions in the Haskell functional programming language. Instructions can be found here.

Version 6.0 adds the ability to work with range types.

Users of Ubuntu and Fedora can install the extension directly from the rpm and apt repositories.

Please note that these is a bug in the GHC libraries in Fedora 44. If you are using Fedora 44, see the workaround.

If you have problems with the extension or a feature request, please submit a Github issue.

The PostgreSQL Global Development Group announces that the fourth 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

The next planned release of PostgreSQL 19 is the release candidate, which should occur in early October. Based on testing and evaluation, this means that the PostgreSQL 19 GA may also occur in October. More details will be provided as we move closer to these releases.

This beta release reverted several features that were originally planned for PostgreSQL 19. The PostgreSQL community strongly believes that, first and foremost, PostgreSQL must be reliable. Additionally, the community strives for a predictable release schedule. Because of this, the community chose to remove some features from the PostgreSQL 19 release so they can be potentially be included in a later major release after more time working through the community development and review process.

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 4

To upgrade to PostgreSQL 19 Beta 4 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 3

Fixes and changes in PostgreSQL 19 Beta 4 include:

• Revert SQL/PGQ (property graph query) support.
• Revert online enabling and disabling of data checksums.
• Revert support for temporal updates/deletes provided by the FOR PORTION OF clause.
• Revert ALTER TABLE ... MERGE PARTITIONS and ALTER TABLE ... SPLIT PARTITIONS.
• Remove the pg_get_role_ddl(), pg_get_tablespace_ddl(), and pg_get_database_ddl() functions.
• Revert a change that forced LC_COLLATE to C in the postmaster process.
• Several fixes to the performance improvement feature for the foreign key constraint checks.
• Several fixes for the new REPACK command, including crashes, incorrect behavior with invalid indexes and materialized views, and several permission and error-reporting corrections.
• Several fixes for the new WAIT FOR command, including a deadlock and clearer reporting of isolation-level errors.
• Fix validation of an empty FOREIGN_JOIN list in pg_plan_advice.
• Several fixes for CREATE PUBLICATION ... EXCEPT.
• Fix logical replication initial table synchronization when replicating from an older PostgreSQL version to v19.
• Several fixes for logical replication conflict detection.
• Several fixes for the new autovacuum scoring system, including for TOAST tables.
• Fix for the COPY FROM SIMD optimization.
• Fix a crash when accessing a partition whose concurrent detach did not complete.
• Clarify that failed transactions are reported separately when using pgbench --continue-on-error.

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 fourth beta release of version 19. The PostgreSQL Project is planning to move to the release candidate portion of the release cycle, and will continue to issue release candidates until PostgreSQL 19 is made generally available. 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

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

PgBouncer 1.26.0 has been released. This release fixes three CVEs:

1. CVE-2026-19888: DoS due to crash, triggerable by unauthenticated clients. Caused by a SCRAM client-final-message without a nonce.
2. CVE-2026-6668: DoS due to infinite loop, triggerable by unauthenticated clients. Caused by an integer overflow in the packet buffer growth logic.
3. CVE-2026-6669: DoS due to unbounded work during login, triggerable by a malicious PostgreSQL server. Caused by an unbounded SCRAM iteration count.

It also tracks search_path and default_transaction_read_only by default, adds the pool_idle_timeout setting, allows query_wait_timeout to be set per user and database, adds meson build support, and removes the deprecated online restart (-R) functionality.

See https://www.pgbouncer.org/2026/09/pgbouncer-1-26-0 for more information, the detailed changelog, and download links.

PgBouncer is a lightweight connection pooler for PostgreSQL.

This is a major release, and the headline feature is our new AI Assistant. We're starting to roll out AI capabilities across our database tools, and SQL Manager for PostgreSQL is the first to get them. It's also available in SQL Management Studio for PostgreSQL, which ships with SQL Manager.

You'll find all the AI Assistant features you'd expect: write a query from a plain-language description, explain existing SQL, fix errors, optimize, make sense of an EXPLAIN plan.

But you can also take on bigger jobs:

• Give it two database schemas and get a list of the differences along with a ready-to-run migration script.
• Hand it your current schema along with new business requirements and get a script that makes the changes.
• Attach someone else's SQL as a file, have it explained, then ask for changes.

Here's the key part: you decide how much of the schema the model sees, down to a single table. You stay in full control of exactly what context goes to the model.

Connect as many providers as you like — all it takes is an API key (stored encrypted), and you can switch models right in the chat. Need to stay completely self-contained? It works with Ollama, so your data never leaves your machine.

How the AI Assistant works in SQL Manager for PostgreSQL

Download SQL Manager for PostgreSQL

Application code has fast testing loops: runners, fixtures, and red-green feedback in JavaScript, TypeScript, and Python. Postgres can be tested too, but database logic often sits outside those loops. Developers have to provision state, manage transactions, or fall back to a pasted query, a browser refresh, or a manual check. That gap shapes architecture. When rules are easier to test in application code than in Postgres, they tend to end up there, even when Postgres is the better place to enforce them.

Mocks do not close the gap. They test how application code handles a result, not whether Postgres will produce it. A mock does not exercise a foreign key, fire a trigger, evaluate a row-level security policy, or verify the database role under which a query actually runs.

pgsql-test is an MIT-licensed harness that puts a real PostgreSQL database inside those loops. It spins up an ephemeral PostgreSQL database, seeds it once, and rolls every test back to that seeded state. Assertions run in the project’s existing test runner, and Postgres executes the constraints, functions, and policies under test. It is not the first way to test Postgres—pgTAP has long done it in pure SQL. pgsql-test targets the application layer instead, where most developers already work.

Testing row-level security

Row-level security (RLS) makes access rules enforceable by Postgres. Policies are pure database logic, invisible to mocks, and a wrong one can leak rows. Testing them means checking both what a user can access and what they cannot.

The pgsql-test harness provides an administrative client, pg, for setup and an application client, db, for testing grants and policies. Superusers bypass RLS, so tests need to exercise the database roles and permissions the application actually uses.

Suppose a project defines app.documents with an ownership policy, and its fixtures insert document 101 owned by Alice and document 202 owned by Bob. Each test runs inside a transaction that is rolled back afterwards, so every test starts from the seeded state:

import { getConnections } from 'pgsql-test';

let db, teardown;

beforeAll(async () => {
  // create a fresh database and deploy the project's schema
  ({ db, teardown } = await getConnections());
});
afterAll(() => teardown());
beforeEach(() => db.beforeEach());
afterEach(() => db.afterEach());

test('Alice sees her document and not Bobs', async () => {
  db.setContext({
    role: 'authenticated',
    'jwt.claims.user_id': 'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'
  });

  const result = await db.query(
    'SELECT id FROM app.documents ORDER BY id'
  );

  expect(result.rows).toEqual([{ id: 101 }]);
});

The query has no ownership filter. The policy must make Alice’s document visible and keep Bob’s out of the result.

setContext() applies the role and identity settings through SET LOCAL and set_config(..., true), scoping them to the transaction. They supply the identity the policies read. Nothing validates a token. Test identities must match what the application’s policies expect. The RLS tutorial covers the setup.

The harness seeds through pgsql-seed, which loads SQL files, programmatic fixtures, CSV, JSON, or migrations.

One harness, many platforms

The same harness runs under other stacks:

• supabase-test supplies Supabase roles, schemas, and authentication defaults.

• drizzle-orm-test runs Drizzle queries within the managed transaction.

• pglite-test uses in-process PGlite, with no external database service when the schema and required extensions are supported.

• graphile-test runs GraphQL against a PostGraphile schema backed by the test database. graphile-realtime-test adds subscription testing.

In one supabase-test run, noted by Supabase CEO Paul Copplestone, 246 tests across 44 databases completed in four seconds.

Scaffolding the loop with pgpm

pgpm, Constructive’s package manager for modular PostgreSQL, scaffolds workspaces with pgsql-test, Jest, and GitHub Actions; getConnections() deploys the module’s plan by default. Start with pgpm init workspace, then add a schema change and a test.

Each change ships deploy, verify, and revert scripts. verify checks that the schema landed. The tests check that it behaves.

The scaffolded workspace extends the same feedback loop into CI with safegres. Tests verify that database behavior is correct, and safegres checks the deployed schema for security and performance regressions. Its CI job enforces a security threshold and compares performance findings against a committed baseline, so a change cannot lower the schema’s security grade or add performance findings.

Postgres enforces the rules. pgsql-test brings verification of those rules into the application development loop.

Availability

pgsql-test and its integrations are MIT licensed and available on npm and PyPI.

Get started: Tutorials · End-to-end testing course · npm · Source code

PostgresCompare is pleased to announce the release of version 2.2.0, the first public release since 1.2.2 and the largest change in the product's history. The application has been rebuilt on a new foundation, and the 2.x series adds database pipelines, ad-hoc comparison, data-change scripting, an MCP server for AI agents, and a fully translated interface.

PostgresCompare connects to two live PostgreSQL databases, detects schema differences across tables, views, functions, indexes, types, and 30+ other object types, and generates a ready-to-run SQL deployment script to synchronise them. It runs on Windows, macOS, and Linux.

Rebuilt from the ground up

• A new application foundation — PostgresCompare has moved from Electron to Tauri. The download is smaller, memory use is lower, and the application now updates itself: new versions are detected and installed without a manual download.
• A redesigned interface — The application has been restyled throughout, with a modern theme, list views for comparisons, a spotlight search that reaches projects, connections and comparison objects from anywhere, keyboard navigation through the difference list, and connection health indicators. Environments were renamed Connections to match how people describe them.
• Six languages — The interface, including the native application menu, is translated into English, Chinese, Hindi, Spanish, French and German, switchable from the sidebar.

New ways to compare

• Pipelines — Model a whole environment chain — development, test, staging, production — and run every comparison in it from one place. Comparisons are explicit edges between environments, so hub-and-spoke and matrix topologies are supported as well as straight chains. A graph canvas draws the pipeline, shows each comparison's result on its edge, and allows any comparison to be re-run from the diagram.
• Quick compare — Compare two databases without creating a project first. Choose two connections, set the comparison options, and run. Intended for one-off checks that do not warrant a saved project.
• A demo database — A first-run option creates a sample project with two deliberately diverging schemas, so the comparison and deployment workflow can be explored before connecting to a real database.

Data comparison and scripting

Data comparison gained a scripting engine. Differences between table contents can be turned into a SQL script, with row-level selection so only the chosen rows are included, and the script panel highlights the row under the cursor as you work through it. Comparison results can also carry notes, so the reason for a decision stays with the comparison.

Automation and AI agents

• MCP server — pgc mcp serve runs PostgresCompare as a Model Context Protocol server, so an AI agent can compare schemas, detect drift, generate and apply migrations, read a schema, take snapshots, explain an individual difference and run health checks through a defined tool interface. A read-only mode disables every tool that writes.
• Export a schema to files — pgc scripts-folder exports a database to a folder of .sql files, one per object, suitable for checking a schema into version control.

Under the hood

• Parallel connections — Projects can read each database over several connections at once, shortening both schema snapshots and data comparisons on large databases.
• Faster large comparisons — Comparisons containing thousands of objects open substantially faster, and deployment script generation now builds SQL directly rather than through an intermediate syntax tree.
• Index sort direction — Deployment scripts preserve DESC and NULLS FIRST/LAST ordering on index columns.
• Function argument types — CREATE FUNCTION arguments retain their schema qualification and array notation.
• Diagnostic logging — Optional verbose logging to a file, with a menu item that opens the log folder, making support issues easier to report.

Availability

PostgresCompare 2.2.0 is available for Windows, macOS (Apple Silicon and Intel) and Linux (AppImage and .deb). The pgc command-line tool ships for all three platforms. Users on 1.2.2 upgrade by downloading 2.2.0 directly; from 2.x onward the application updates itself. A 14-day free trial is available with no credit card required, and when a trial ends, quick compare and connection management remain available without a licence. PostgreSQL versions 9.2 through 18 are supported.

• Download PostgresCompare 2.2.0
• Full release notes

The pgAdmin Development Team is pleased to announce the release of pgAdmin 4 version 9.18. This release of pgAdmin 4 includes 29 bug fixes and new features, including fixes for four security vulnerabilities (CVE-2026-86861 through CVE-2026-86864). 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

• Collapse and restore the Object Explorer by re-clicking the current workspace icon, in the manner of the VS Code side bar, remembering the choice across refreshes. A keyboard shortcut, Ctrl+Alt+B by default, does the same thing and can be changed through the new toggle_object_explorer preference.
• Harden the default Content-Security-Policy so inline scripts run under a per-request nonce rather than a blanket 'unsafe-inline', and drop 'unsafe-eval'. style-src keeps 'unsafe-inline', because MUI and React inject runtime styles and inline style attributes that cannot carry a nonce, and development bundles have 'unsafe-eval' re-added automatically when DEBUG is set.

Security Fixes

• Fix an authentication bypass in Webserver authentication mode, where get_user() fell back to reading the configured WEBSERVER_REMOTE_USER name from the inbound request headers when it was absent from the WSGI environment. Because a header is written by whoever sends the request, any client that could reach pgAdmin could assert any identity, including an administrator's, without presenting a credential. A header-asserted identity is now opt-in, restricted to a configured list of trusted proxies with an optional shared secret, and refused for accounts whose authentication source is not webserver (CVE-2026-86863).
• Fix argument and connection-string injection in the Backup tool, where the client-supplied database name was appended to the pg_dump argument vector as a bare positional value. Because getopt_long permutes arguments, a value beginning with a dash supplied further options such as --file, overriding the storage-confined output path; and because libpq expands a database name containing an equals sign into a full connection string, the same field could redirect the connection, and the password exported in PGPASSWORD, to a host of the caller's choosing. The database name is now passed through the PGDATABASE environment variable, which libpq never expands (CVE-2026-86864).
• Fix connection-string injection in the Restore and Maintenance tools, where the client-supplied database name was passed straight to --dbname and could likewise redirect the connection, and the exported password, to a server of the caller's choosing (CVE-2026-86862).
• Fix a time-of-check to time-of-use flaw in the File Manager's save_file endpoint, which backs saving from the Query Tool and ERD: the requested path was validated with check_access_permission() and then opened with a plain open(), so a symbolic link planted in between was followed, writing outside the user's storage directory. This is the write sink that CVE-2026-7819's hardening of the separate upload path did not cover (CVE-2026-86861).
• Refuse HTTP redirects on LLM API requests, rather than following a Location header on to a destination the ALLOWED_LLM_API_URLS check was never applied to. This is hardening rather than a fix for an exploitable flaw, since returning the redirect at all requires control of a host already on the allowlist.
• Reject an empty or null Username when importing a non-shared server, which previously imported cleanly and left a server that libpq would silently authenticate as the OS account running pgAdmin rather than reject outright.

Bugs/Housekeeping

• Fix login being impossible against Flask-Security-Too 5.8.2, which corrected a long-standing inversion in UserMixin.is_locked() that pgAdmin's own is_locked() had been written against.
• Fix inherited columns in the Table dialog being editable and deletable, and the Data type dropdown on the expanded Definition tab offering every type rather than honouring the allowed-type restriction applied inline.
• Reinstate dependency ordering of the script Schema Diff generates, which had been lost since the React port left dependLevel unset.
• Fix Schema Diff reporting false differences for SERIAL and BIGSERIAL columns, duplicating any column that also differs when recreating a foreign table, losing a foreign table column's collation, injecting whitespace into an applied function or procedure body, generating SQL that PostgreSQL rejects when a sequence's MINVALUE is raised above its current value, and reporting a comparison that fails part way through as a success.
• Share concurrent identical GET requests behind getNodeAjaxOptions() so a wide table's Columns tab no longer fires one duplicate get_types request per column row.
• Fix the argument grid on the Definition tab of a user-defined function or procedure refusing to delete, or add, a row in edit mode.
• Omit the redundant TABLESPACE pg_default clause from generated index SQL, which was invalid on a partitioned table.
• Fix a crash when a per-server Password Exec Command is used with a service-only (pg_service.conf) connection, which leaves host, port and username unset.
• Accept SharedUsername when importing a shared server from a servers.json definition, instead of insisting on Username for every server.
• Render the Validate binary path dialog as HTML, instead of showing the raw markup.
• Remove a trailing quote from the Windows installer's ProductVersion, and fix the existingSecret path in the Helm deployment template.
• Skip importing and initialising the Kerberos, LDAP, MFA, OAuth2 and Webserver authentication providers unless SERVER_MODE is set, leaving desktop mode with internal authentication alone.
• Bump JavaScript and Python third-party dependencies, and update the message catalogs, including a fix for the Korean catalog that had not been recompiled since November 2025.

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.

With this release, pgAssistant is evolving beyond PostgreSQL analysis and tuning to become a continuous PostgreSQL improvement platform.

The new positioning is built around a continuous improvement loop:

Observe → Diagnose → Prioritize → Plan → Implement → Collect again → Measure

pgAssistant already helped identify what should be improved and turn recommendations into a prioritized Executive Plan with clear DEV and OPS ownership.

Combined with pgAssistant Collector, version 3.8.0 goes further by adding historical workload and environment measurements. The objective is to answer four essential questions:

• What should we improve?
• What did we decide to do?
• What did we actually change?
• What was the result?

Workload Insights compares consecutive collections and highlights:

• new and no-longer-detected recommendations;
• changes to the PostgreSQL version and configuration;
• workload evolution by statement type;
• changes in execution time and call volume;
• the queries with the greatest impact on the overall workload.

The ambition is to correlate the application of pgAssistant recommendations and the Executive Plan with observed performance changes.

Correlation is not causation, and a recommendation that is no longer detected does not necessarily prove that it was implemented. pgAssistant keeps these distinctions explicit while bringing the relevant evidence together in one place.

pgAssistant is not intended to replace real-time monitoring. Monitoring shows what is happening now; pgAssistant helps teams decide what to improve next, organize the remediation work, and measure what changed afterwards.

From recommendations to action—and from action to measurable evidence.

pgAssistant 3.8.0: https://github.com/beh74/pgassistant-community

pgAssistant Collector: https://github.com/beh74/pgassistant-collector

pgAssistant Grafana : https://github.com/beh74/pgassistant-grafana

CERN PGDay 2027

Date: Friday, February 12, 2027
Location: CERN Campus, Geneva, Switzerland / Suisse Romande
Language: English
Organizers: Swiss PostgreSQL Users Group (SwissPUG) & CERN
Format: Single-track (6–7 sessions) followed by networking social event
Homepage: swisspug.org/cern-pgday-2027

About the Event

Continuing in the line of work of the past editions, CERN PGDay 2027 returns as the annual gathering for PostgreSQL users, developers, and enthusiasts across Suisse Romande (western Switzerland) and the neighboring French border regions.

Co-organized by CERN and SwissPUG, this single-day community conference offers a premier opportunity to network, share practical experiences, and explore the future of the world's most advanced open-source database. The event takes place in the unique, international environment of Geneva—a hub for major scientific institutions, non-governmental organizations, and financial and tech enterprises.

Format & Venue

• Single-Track Schedule: The program consists of a single track featuring 6 to 7 technical sessions presented entirely in English.

• Social Event & Networking: Following the technical presentations, a social event will take place to facilitate community networking, discussions, and collaboration in the inspiring atmosphere of CERN.

• CERN Visits: Attendees are encouraged to arrange their schedules before or after the event to take advantage of the conference location and visit CERN, the European Organization for Nuclear Research.

Call for Papers (CfP)

Speaker proposals for CERN PGDay 2027 can be entered online via Indico.

• Call for Papers Closes: November 8, 2026 (23:59 CET)

Call for Sponsors (CfS)

Sponsors proposals for CERN PGDay 2027 are welcome. Please find the contract with all details online.

Key Themes

We welcome talk proposals covering broader PostgreSQL and community trends and localized enterprise & scientific topics:

• High-Performance Science & Big Data: Managing massive datasets, extreme write throughput, partitioning, and high-availability database architectures in large-scale setups.

• AI & Vector Search Integration: Best practices for pgvector, machine learning pipelines, RAG, and AI-driven data workloads built directly on PostgreSQL.

• Enterprise Security, Sovereignty & Compliance: Data protection, cloud sovereignty, encryption, and auditability.

• Extensibility & Core PostgreSQL: Performance tuning, query optimization, new features, and extension development.

Policies & Code of Conduct

CERN PGDay 2027 is a community event recognized under the PostgreSQL Community Event Guidelines. All participants, speakers, sponsors, and organizers are required to adhere to the PostgreSQL Community Code of Conduct to ensure a safe, inclusive, and welcoming environment for everyone.

pg_vault_tde provides Transparent Data Encryption for PostgreSQL 17 and 18. A table access method, encrypted_heap, encrypts every tuple with AES-256-GCM before it reaches the storage manager and decrypts it after it leaves, so applications require no changes.

Keys are held outside the database: HashiCorp Vault or OpenBao through the Transit engine, a PKCS#11 token or HSM, or a local PKCS#12 wallet. Data encryption keys are per table and can be rotated online. Requirements are PostgreSQL 17 or 18, OpenSSL 3.x, and the library listed in shared_preload_libraries.

The current release is 1.7.1. It corrects the AAD derivation for out-of-line TOAST values, with the consequence that TOAST data written by 1.7.0 or earlier does not authenticate under 1.7.1: affected tables must be exported before the new binary is installed. The procedure is documented in the README.

pg_vault_tde is released under the PostgreSQL licence. Sources, documentation and binary .deb and .rpm packages are on GitHub; the distribution is on PGXN.

Paris, 7th september 2026.

The Dalibo team is pleased to announce the release of PostgreSQL Migrator 1.0 stable, a free and open-source tool designed to help migrate databases from Oracle and MySQL/MariaDB to PostgreSQL.

Key features

• Easy installation: pure Go binary with zero proprietary dependencies.
• Fast, offline inspection: Extract the full source catalog once, then iterate on conversion offline.
• Complexity scoring: Quickly assess and compare the difficulty of migration projects.
• Interactive web UI: Browse both the original and converted catalogs, search objects, and identify migration blockers.
• Schema and data conversion: Converts datatype and SQL expression, convert column to boolean.
• Code analysis and transpilation: Transpiles and analyzes SQL, PL/SQL and routines with the companion transqlate tool.
• High-performance data copy: Streamed bulk COPY to PostgreSQL (or to files / pipes), with low memory usage and significantly higher throughput than traditional tools in our tests.
• Hackable & configurable: Reliable JSON catalog data, TOML configuration, and templating for fine-tuning.

Supported features

PostgreSQL Migrator supports migrating from Oracle Database 11g to 26ai, MySQL 8.4+ and MariaDB 10+ to PostgreSQL 16 up to 19.

Version 1.0 has full inspection including jobs, system triggers, etc. However, conversion and migration is limited to role, schema, sequences, table, virtual columns, constraints and indexes. The documentation describes implemented and planned features including views, procedural objects, SQL Server and more.

Stability

We have built a demanding CI pipeline including end-to-end tests based on Oracle Free container and cypress. This effectively prevents regression and ensure quality. After one year of beta and rc, PostgreSQL Migrator is stable. We'll ensure configuration, CLI and project compatibility for all 1.x releases.

License and availability

PostgreSQL Migrator is released under the PostgreSQL License.

• Documentation: https://postgresql-migrator.readthedocs.io/
• Source code: https://gitlab.com/dalibo/pg_migrate

We welcome feedback, bug reports, and contributions via the GitLab issue tracker.

Happy migrating!

Autobase 2.11 is an important milestone in the evolution of the platform. Two years ago, we started working on a broader goal: evolve the Autobase Console from a PostgreSQL deployment UI into a platform for managing the complete cluster lifecycle.

With this release, the remaining major pieces of that roadmap are now in place - scaling, upgrades, backups, and point-in-time recovery can all be managed directly from the Platform UI.

See the full details in the release notes.

Highlights

Scaling (read replicas)

Scale PostgreSQL read capacity directly from the UI. Simply specify the desired number of cluster nodes, and Autobase will provision the additional replicas automatically using the existing cloud configuration.

For cloud deployments, the required servers and related infrastructure resources are created automatically. You can also scale clusters running on your own bare-metal or virtual machines.

Start with a single-node PostgreSQL cluster and add replicas later as your workload grows.

Upgrades

Autobase Platform now supports minor upgrades within the current PostgreSQL major version as well as major-version upgrade workflows.

For minor upgrades, replicas are updated one at a time, followed by a switchover and upgrade of the former primary. Read traffic remains available throughout the process, while expected write downtime is only ~5-10 seconds.

For in-place major upgrades, the expected downtime is typically ~30-60 seconds. A blue-green major upgrade workflow with near-zero downtime is planned for a future release.

Backup & Restore (PITR)

Backup and recovery management is now available directly in the Platform UI. Configure the backup method, storage, retention, and schedule, or create backups on demand.

Restore options include:

• Latest: recover to the latest available state
• Point in time: restore to a specific date and time
• Specific backup: restore from a selected backup

New Ansible playbooks

Autobase 2.11 adds new Ansible playbooks for backup and recovery operations:

• enable_backups: enable pgBackRest or WAL-G for an existing cluster
• backup_pgcluster: create a backup on demand
• backup_list: list available backups
• restore_pgcluster: restore a PostgreSQL cluster from backup

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

Eymoutiers, France, Septembre 4th, 2026

Dalibo is pleased to announce PostgreSQL Anonymizer 3.2 introducing a new panel of fast pseudonymization filters.

Enhanced Privacy Protection for Your Data

PostgreSQL Anonymizer is an extension that hides or replaces personally identifiable information (PII) or commercially sensitive data from a PostgreSQL database.

The extension offers 6 different masking strategies:

• Dynamic Masking - Real-time data protection
• Static Masking - Permanent data transformation
• Replica Masking - Anonymized logical replication
• Backup Masking - Privacy-protected database exports
• Masking Views - Controlled data visibility
• Masking Data Wrappers - Extended protection across systems

Each strategy is complemented by an enhanced suite of Masking Functions, including advanced techniques such as: Substitution, Randomization, Faking, Pseudonymization, Partial Scrambling, Shuffling, Noise Addition and Generalization.

The extension can be installed with Debian and RPM packages, an Ansible role, a Docker image, etc. You can use it on most major DBaaS providers including : Alibaba Cloud, Crunchy Bridge, Google Cloud SQL, IBM Cloud, Microsoft Azure Database, Neon, Yandex It is also available on some Postgres forks such as EDB Advanced Postgres, Greenplum and Yugabyte.

See the INSTALL section of the documentation for more details!

Fast and Localized pseudonymization

Although Pseudonymization is not Anonymization, it may be useful in some contexts.

Until version 3.1, this was achieved with a panel of pseudo_* functions, such as anon.pseudo_last_name(...), anon.pseudo_email(...), etc.

These functions are now replaced by a new panel of anon.seeded_* functions, such as anon.seeded_last_name(...), anon.seeded_email(...), etc.

The anon.seeded_* functions have 2 main advantages over the previous ones:

• They can be localized, e.g anon.seeded_street_name(id,'fr_FR')
• They are 40x faster :)

The anon.pseudo_* functions are kept for backward compatibility but are now deprecated and will be removed in a future version. We encourage all users to switch to the new anon.seeded_* functions as soon as possible.

Important Security Update

Version 3.2 includes fixes for 3 critical vulnerabilities allowing a user to gain superuser privileges under certain circumstances. The risk is very high on PostgreSQL 14 and on instances upgraded from PostgreSQL 14 and earlier.

These vulnerabilities are declared below:

• CVE-2026-19633: Privilege elevation via custom types, operators and rangevars
• CVE-2026-19634: SQL injection in the masking rules import functions
• CVE-2026-83534: Privilege elevation via parallel static masking

All users should upgrade the extension to version 3.2 as soon as possible.

See issue 665 and issue 666 for more details.

Version 3.2 introduces a new security barrier that forbids superusers from using any kind of masking (static, dynamic, etc.). Enforcing the principle of "Least Privilege", the extension now refuses to run any masking function on behalf of a superuser.

Especially if you are currently using static masking, replica masking or backup masking with a superuser, we advise you to create a dedicated role for that.

The previous behaviour can be restored by setting anon.nosuperuser to FALSE, in which case the security barrier will be removed and superusers will be able to execute masking rules at their own risk.

Upgrade

The JSON schema used for imports / exports has changed between version 3.1 and 3.2. It is recommended to re-export the rules after the upgrade to 3.2

See the UPGRADE section for more details.

Acknowledgments

This release includes code, bugfixes, documentation, code reviews and ideas from Alain Lesage, Benoit Lobréau and other contributors. Kudos to Alain for his first contributions !

CVE-2026-19633 and CVE-2026-19634 were reported by Sarath Kumar, IITM Pravartak Security Team CVE-2026-83534 was reported by Alexander Kukushkin. Many thanks to them and to the PostgreSQL Security Team.

We would also like to thanks the people at Efluid who helped us with their ideas, comments and testing.

And also special thanks to the PGRX team for their amazing work!

Join our community to improve data privacy!

PostgreSQL Anonymizer is part of the [Dalibo Labs] initiative. It is mainly developed by [Damien Clochard] and [Benoit Lobréau].

This is an open project, contributions are welcome. We need your feedback and ideas! Let us know what you think of this tool, how it fits your needs and what features are missing.

If you want to help, you can find a list of Junior Jobs.

Hey there,

Mark your calendars: PGConf India 2027 is set for March 2–5, 2027 at the Sheraton Grand Hotel at Brigade Gateway, Bengaluru.

The Call for Papers is open right now.

Important dates

• CFP closes — October 15, 2026
• We tell you yes/no — November 15, 2026
• The actual conference — March 2–5, 2027

What we're into

Basically anything Postgres, including but not limited to:

• Core internals & features
• Performance & query tuning
• HA, replication & disaster recovery
• Cloud & infra
• Security & compliance
• Monitoring & ops
• Real production case studies
• ML, analytics & data platforms (pgvector fans, this means you)
• Extensions & ecosystem tools
• Community & open source

To submit

Give us a title, session length (25 or 40 min), your bio, and an abstract (≤500 words) on what you'll say and what people should walk away with.

Submit your talk

Ticket sales aren't open yet — watch pgconf.in for that and everything else. See you in Bengaluru.

The PGConf India Team

https://pgconf.in

Powered By ConfBase.io

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