PGConf.EU 2025 Establishing the PostgreSQL standard What is Postgres compatible

Establishing the PostgreSQL standard: What's Postgres compatible?

Website on PGConf.EU conference system

About

What does it mean to be "PostgreSQL compatible"? As PostgreSQL becomes "the new Linux" for the enterprise, this question becomes increasingly important. This half-day session invites Postgres developers, contributors, and community members to define a practical framework of criteria and tests for PostgreSQL compatibility.

Discussion Topics

TOPICS

What specific SQL features define the core Postgres user experience?

JIMMY SUBTOPIC: Behavior

What specific behavioral tests, run over a client connection, should be included? Must a compatible product support the same transaction isolation levels (e.g. Read Committed, Repeatable Read, Serializable) with the same behaviors? Must it return identical SQLSTATE error codes for common errors to ensure application-level error handling remains consistent? What level of compatibility with the pg_catalog system catalogs is required? (e.g. for psql commands, monitoring tools, and ORMs to function). Must it fully support the v3 client wire protocol, including all standard authentication methods (e.G., SCRAM, MD5, GSSAPI)? Compatibility with SSL/TLS and its various modes (prefer, require, verify-ca, etc.)? What level of compatibility, if any, is required for configuration files and GUCs (e.g. postgresql.conf, pg_hba.conf)?

HETTIE SUBTOPIC: Functionality + Extensions

Is support for PL/pgSQL a mandatory part of compatibility? What about other standard procedural languages (e.g. PL/Python, PL/Perl)? Must indexing methods be supported and behave identically? (e.g. GIN, GiST, BRIN)? Support for specific functions, such as SELECT now()? Support for specific data types, like ARRAY, BYTEA and JSONB?

(merged with "Extensions" topic)

What is the standard for compatibility with Postgres extensions? Compatibility with standard Foreign Data Wrappers (FDWs) ABI (Application Binary Interface) stability checker test?

Discussion:

1. Everything covered by Postgres documentation in "SQL commands" is required to be "Postgres compatible." Even if rules are almost never used, since they are part of Postgres, any system that is "Postgres compatible" should have rules. 2. For each of the characteristics, there should be a way to quantify how much it satisfies the standard requirements (not only yes/no, but also "with exception" or with restriction, or "partially") 3. There are more important and less important features, and if we design compatibility tests, we should identify features that are more important and less important, and have a "weighted" comparison to the standard

Open questions:

- Is it enough if SQL does not error, even if it does nothing? (for example, CREATE INDEX completes normally, but does not create any index?) - Extensions support - Specifically, FRW support

TERESA SUBTOPIC: Backups & Replication

Is Point-In-Time Recovery (PITR) required to be included? Must a compatible product provide access to the raw data files, including the WAL (Write-Ahead Log)? What is the standard for backup compatibility? Must a compatible product allow backups to be performed and restored using standard tools? What is the standard for replication compatibility? Must a compatible product be able to open incoming and outgoing streaming replication connections to vanilla Postgres? Must a compatible product be able to open incoming and outgoing logical replication connections to vanilla Postgres? Must a compatible product be compatible with standard replication and HA tools like Patroni, RepMgr, EFM, etc.?

ALL GROUPS SUBTOPIC: Brand/Identity

If a product satisfies all compatibility criteria but is not the vanilla C implementation, is it still "Postgres"? Should such a product be defined only as "Postgres-compatible"?

ALL GROUPS OUTLIER TOPIC: What specific build tests should be included?

Tests within each grouping. Compatibility is defined ONLY as passing 100% of tests within group.