PostgreSQL Compatibility: Cutting Through the Hype with PG Scorecard

The PostgreSQL ecosystem has exploded in popularity, with many vendors claiming compatibility to tap into its thriving community. But how do you measure true compatibility with community PostgreSQL? Enter PG Scorecard, the PostgreSQL Compatibility Index (formerly Postgres.Is): the new (and welcome) tool designed to evaluate how closely a database system aligns with standard PostgreSQL behavior. PG Scorecard is an open-source project (MIT licensed) that allows you to see at a glance how much each vendor has modified native PostgreSQL to work with that vendor's product. We’re personally excited to see that pgEdge came in ranking as 100% compatible with PostgreSQL, based on a comprehensive scoring methodology and philosophy.

Let’s delve a little more into how PG Scorecard works, how pgEdge meets these compatibility standards, and how this applies across different PostgreSQL versions.

The PostgreSQL Compatibility Race

Many vendors have claimed that they were in close alignment with standard Postgres, yet key features - such as foreign key constraints, extensions, JSONB, and more - were lacking from their products. And so, PG Scorecard was born out of the need to have a clearly established definition for PostgreSQL compatibility.

PG Scorecard runs a number of tests comparing vendor software to community PostgreSQL (version 17), across such categories as:

• Data Types (e.g., JSONB, geospatial, custom types)  

• DDL Features (e.g., views, triggers, sequences)

• Constraints (e.g., foreign keys, exclusion constraints)  

• Procedural Features (e.g., stored procedures, PL/pgSQL)  

Each feature is scored based on how much support a vendor provides for the feature, and the results are aggregated into a single PCI percentage. While the list of current vendors isn’t complete there are currently nine vendors evaluated at the time of this writing.

pgEdge: 100% Compatible with Standard PostgreSQL

According to PG Scorecard's tests, pgEdge is 100% compatible with standard PostgreSQL.

What does this mean?

pgEdge provides the same native functionality as community Postgres for:

• data types

• DDL features

• SQL features

• procedural features

• performance

• constraints

• extensions

• security

• replication

• transaction features

• and other core features.

This means you get all of pgEdge’s benefits: high availability, near-zero maintenance downtime, low latency, and multi-region distribution along with support for native PostgreSQL behavior. Compatibility and security for your existing PostgreSQL applications is not a concern when you're using pgEdge. No fuss, no vendor lock-in, and no new protocols or interfaces to learn.

Built on Community PostgreSQL

Unlike vendors that fork PostgreSQL or reimplement its wire protocol, pgEdge is built directly on standard PostgreSQL, augmented by extensions like Spock (available under the pgEdge community license) for multi-master replication. There’s no proprietary code or features as a result, giving you clear insights into the source code.

Key advantages include:  

1. No Fork, (Almost) No Patches

pgEdge builds PostgreSQL with minimal patches (50–100 lines) to implement advanced features. This ensures maximum alignment with community PostgreSQL and ensures access to the latest updates and innovations.  

2. Full Ecosystem Support

Because pgEdge is standard PostgreSQL under the hood, it has native support for everything you would expect from a typical Postgres installation such as:

• PostgreSQL extensions (e.g., PostGIS, pgVector, TimescaleDB).  

• Client tooling (e.g., pgAdmin, psql, ORMs).  

• Stored procedures and triggers without rewrite requirements.  

3. Timely Version Updates  

pgEdge supports new PostgreSQL major versions within weeks of release, in order to avoid outdated, unsupported forks and provide the latest and greatest features and bugfixes to users.

Caveats

While pgEdge guarantees ACID compliance at the node level, its distributed architecture follows the AP (Availability and Partition Tolerance) model of the CAP theorem. This means you can expect:

• Single-Node ACID: When connected to a specific node, users experience full PostgreSQL ACID guarantees.  

• Eventual Global Consistency: Conflicts in a multi-master cluster are resolved via conflict-free delta apply columns which use a delta application technique when addressing potentially conflicting transactions in order to ensure accurate results.  

This design prioritizes low latency and high availability—critical for global applications—but requires partition optimization for optimal data consistency:  

Still have questions? Our support team can help design distributed architectures that balance consistency, availability, and performance. Reach out to us, anytime.

What’s next

PG Scorecard is entirely open-sourced and MIT licensed. Because of its open-source nature, the success and usefulness of PG Scorecard are entirely influenced by our collaborative efforts as a community. If you see inaccurate information or would like to otherwise improve or enhance this project, please take a moment to check out the GitHub repository and consider contributing.

As for pgEdge, you may be interested in joining the ranks of companies using our software for SaaS, financial services, or US national security projects. What’s your use case? We’d love to hear from you - feel free to get in touch and let’s chat!