EDB has released PGD 6.4 for distributed Postgres deployments, adding quorum commit, native connection pooling, and support for PostgreSQL large objects.
The update centres on quorum commit, which EDB described as a way to enforce a single transaction outcome across cluster nodes before a transaction is committed locally. The feature is aimed at systems where conflicting writes across locations can create financial or operational risk.
EDB is targeting organisations running critical workloads in sectors such as banking, payments, telecoms, and infrastructure, where distributed consistency is often a core requirement. In those environments, operators have often relied on proprietary database products for the strongest transaction guarantees.
Jozef de Vries, Senior Vice President, Database Engineering, at EDB, said the launch addresses that gap for Postgres users. "Postgres has become the de facto standard for modern applications. Yet until now, organizations running high-value workloads in banking, payments, or telecom were forced to fall back on legacy enterprise RDBMS for their strongest consistency requirements. PGD 6.4 changes that, delivering the same distributed consistency those systems were built on, now fully Postgres native."
According to EDB, quorum commit works as a pre-commit coordination step across the cluster. Rather than simply confirming that a replica has received a record, it is designed to coordinate concurrent writes across sites before a transaction completes.
EDB illustrated the issue with a payments example involving a shared credit card used in different geographies at the same time. Under conventional replication, two transactions can pass local checks and commit separately, leaving the institution to reconcile an overspend afterwards. With quorum commit, one transaction is intended to win cluster consensus first, while the other sees the updated balance and is rejected before completion.
Pooling built in
Alongside that change, PGD 6.4 expands the Connection Manager introduced in an earlier release with native connection pooling. EDB said this removes the need for external poolers such as pgBouncer in many production setups.
Because the Connection Manager is tied to PGD's Raft consensus layer, it can route traffic with awareness of both cluster and regional state, shift routes automatically during failover, and expose monitoring through PostgreSQL logging and monitoring views. The aim is to reduce the number of moving parts in large deployments.
This matters most for organisations running large numbers of clusters, where each extra component adds deployment, maintenance, and monitoring work. EDB said payment processors and other operators managing infrastructure across thousands of CPU cores can simplify operations by relying on the built-in layer rather than a separate proxy tier.
Broader workloads
The release also adds replication support for PostgreSQL large objects, which are used to store binary data. EDB said this extends distributed Postgres support to workloads involving scanned documents, image archives, binary payloads, and applications that combine transactional data with unstructured content in the same database.
That could broaden the relevance of distributed Postgres in sectors that keep mixed data sets alongside core records, including government, healthcare, and financial services. In those settings, binary objects can sit next to transaction tables and customer or case records, making support for both forms of data important when systems are distributed across multiple locations.
The update comes as data sovereignty remains a central issue for many organisations. EDB cited a Gartner forecast that by 2030, more than 75% of enterprises in Europe and the Middle East will have repatriated workloads to their home jurisdictions, up from less than 5% in 2025. That trend has increased scrutiny not just over where data is stored, but also over how consistently it is managed across borders and sites.
For database suppliers, the opportunity lies in offering open-source-based systems that can meet those governance and resilience demands without requiring a return to proprietary platforms. EDB is seeking to position Postgres more firmly in that part of the market by focusing on transaction integrity in distributed environments and reducing dependence on surrounding infrastructure components.