Need a fully distributed PostgreSQL database like CockroachDB, EDB, pgEdge or Yugabyte?

Consider these factors in your decision


Standard PostgreSQL vs Postgres Compatible

A Postgres Compatible solution requires the user to consider the time and cost required to convert code, research extension support, understand Postgres tooling, and the timing of updates to support new Postgres versions.

What are the advantages of fully standard Postgres versus “Postgres compatible”?

If your application makes relatively extensive use of Postgres as its underlying database you will want to look into the following questions:

  • How much code will you need to convert, based on your usage of standard Postgres syntax and features that are unsupported by the Postgres compatible database?   What level of effort will this require?

  • Do my applications make use of popular Postgres extensions, and are these extensions fully supported by the Postgres compatible database?

  • Will the Postgres tooling (e.g. pgAdmin) used by my team for database administration be supported by the Postgres compatible database (unlikely)?  If not, what tooling is available and what is the level of effort required for training and retooling?

  • Does the database vendor update the database to support new Postgres versions as they become available each year?

With fully standard Postgres -- as provided by pgEdge -- all PostgreSQL syntax and PostgreSQL extensions are fully supported so you can leverage your investment in application code, tooling and staff.

Cap Theorem

Postgres users must choose their priorities because they can't have all three: Consistency, Availability and Partition Tolerance. Although pgEdge is an AP system, it can function as a CP system for transactions that require it.

Do we need to prioritize latency and high availability over consistency?

In a CP distributed database (Consistent and Partition Tolerant), all database writes are synchronous across all or at least a majority of nodes.  An advantage of CP systems is absolute consistency across all nodes.   However synchronous updates across geographically separated nodes will be slower, negatively impacting latency and availability. In some instances if one or more nodes are down the system will simply stop. Some CP database users mitigate this issue by paying for additional nodes. Work-arounds to address the CP latency and availability issues are sometimes more costly and kludgy than choosing an AP system from the start. 

pgEdge is an AP (Availability and Partition Tolerant) system with loosely coupled nodes capable of read and write operations at any node in a geographically distributed cluster. The nodes are kept updated via asynchronous logical replication providing  low latency and ultra-high availability for the majority of workloads.  If absolute consistency is needed across the cluster for a particular transaction, pgEdge can function in a synchronous CP mode for that transaction.   

Each node runs standard Postgres (v14, v15, v16), and a cluster can span multiple cloud regions or data centers.  A configurable conflict resolution algorithm resolves data conflicts when transactions at different nodes update the same data at the same time. pgEdge also employs conflict free delta apply columns to maintain consistency for data fields that keep running sums like financial balances or inventory counts.

In general for an application that is geographically distributed or where breaking up the workload on a geographic basis is desired, an AP system such as pgEdge will be a better fit.   For horizontal scaling within a single data center or cloud region and where absolute consistency is required a CP system may be preferable.  

pgEdge Ultra-High Availability

pgEdge is an AP (Availability and Partition Tolerant) system with loosely coupled nodes capable of read and write operations at any node in a geographically distributed cluster.

What approach is best to achieve ultra-high availability with PostgreSQL?

The core principle behind high availability (HA) is redundancy. A robust system that supports HA is architected in such a way that if a node goes down, its duties are instantaneously handed over to another node, preventing any operational disruption.

An AP database system like pgEdge can achieve higher levels of availability (3, 4 or perhaps even 5 nines) with a smaller number of nodes.   This results in significant savings in software licensing and cloud or hardware infrastructure.


While a number of excellent and popular Postgres-compatible distributed databases are available, only pgEdge offers a low latency, ultra-high availability AP system that is both fully open and fully based on standard and current Postgres. pgEdge offers:  

  • Postgres syntax and popular PostgreSQL extensions are fully supported so you can leverage existing investments and skill sets and eliminate vendor lock-in

  • Lower latency facilitated by placing copies of your database closer to users

  • Ultra-high availability with multi-master replication means high reliability with fewer nodes, lower costs and zero downtime for maintenance

  • Geographic scaling across regions and cloud providers

Dive deeper into pgEdge


Enhancing pgLogical with Multi-Master (Active-Active) Features


Distributed PostgreSQL Buyer's Guide: How to evaluate vendor claims of Postgres compatibility


Unlocking PostgreSQL 16 New Features

Get started today.

Experience the magic of pgEdge Distributed PostgreSQL now.