PostgreSQL compatible database guide

Classify Supabase, Neon, YugabyteDB, CockroachDB, Cloudberry, IvorySQL, Materialize, Gel, and FerretDB by PostgreSQL lineage and compatibility

“Built on PostgreSQL,” “uses the PostgreSQL protocol,” and “can replace PostgreSQL” are three different claims. Compatibility has at least five layers:

A driver connects
  → pgwire messages work
    → SQL, types, and functions match
      → catalogs, extensions, and transactions match
        → backup, replication, upgrade, and failure semantics match

Each deeper layer needs migration and failure testing. A PostgreSQL-compatible label usually describes only part of this stack.

Developer platforms centered on PostgreSQL

Platform	Where PostgreSQL sits	Platform additions	Do not assume
Supabase	Each project runs PostgreSQL	PostgREST, Auth, Realtime, Storage, Functions, Dashboard, and pooling	Cloud and self-hosted operations are identical, or browser APIs are secure automatically
Neon	Compute nodes run the PostgreSQL query layer	Separated compute/storage, page servers, branches, and scale-to-zero	Data directory, WAL, unlogged tables, and recovery behave like ordinary PostgreSQL
Nhost	PostgreSQL is the database	Hasura GraphQL, Auth, Storage, and Functions	GraphQL permissions are the complete database security boundary
Prisma Postgres	Managed PostgreSQL	PgBouncer, HTTP/edge driver, query cache, temporary databases, and Prisma tooling	Operation billing, pooling, and extensions match every self-hosted installation

These platforms preserve ordinary SQL, migration, and pg_dump thinking, but their connection proxies, sleep behavior, backups, extension allowlists, API permissions, and billing belong in the architecture.

Forks, reused query layers, and new storage

Project	Implementation path	Primary target	Migration risk center
YugabyteDB	YSQL reuses the PostgreSQL query layer over distributed DocDB	Distributed transactions, horizontal scale, and multi-region	Extensions, locks/isolation, catalogs, DDL, and distributed cost model
PolarDB for PostgreSQL	Compute/storage-separated PostgreSQL-lineage fork	Shared storage, one writer/many readers, cloud architecture	Open-source version cadence, specialized storage/HA, and differences from the hosted product
Apache Cloudberry	Greenplum/PostgreSQL-lineage MPP database	Warehousing and massively parallel analytics	OLTP transactions, distribution keys, SQL/extensions, and operational tooling
IvorySQL	Oracle-compatible fork tracking PostgreSQL	PL/iSQL, Oracle syntax, packages, and migration	Compatibility mode, Oracle semantics, extension packaging, and upstream synchronization
openGauss	Independent database kernel with PostgreSQL lineage	Enterprise deployment, parallelism, and its own ecosystem	Long independent evolution means current PostgreSQL compatibility is not a default
OrioleDB	New PostgreSQL storage engine, generally on a supported build	Undo-based MVCC, copy-on-write/checkpointing, and reduced bloat for selected workloads	Binary/build, WAL/backup, extensions, major upgrade, and failure recovery

Lineage is not a drop-in guarantee. Distributed storage in particular changes transaction retries, hot keys, sequences, foreign keys, locks, and consistency/latency tradeoffs.

PostgreSQL clients work, but the server is not PostgreSQL

Project	Role of pgwire/PostgreSQL	Actual product
CockroachDB	Implements pgwire and much PostgreSQL syntax	Independent distributed SQL database with different extensions, catalogs, and transaction behavior
Materialize	PostgreSQL-compatible drivers query views	Streaming incremental-compute and live-data layer, not general-purpose OLTP PostgreSQL
Gel	Uses PostgreSQL technology underneath and offers SQL/ecosystem integration	Graph-relational database whose primary model and language are Gel/EdgeQL

server_version can be a compatibility interface

Compatible databases may report a PostgreSQL-like server_version or expose similar catalogs. A version string helps a driver choose a protocol path; it does not prove the same PostgreSQL kernel is running.

FerretDB is compatibility in the opposite direction

FerretDB 2.x accepts MongoDB 5.0+ wire-protocol requests, translates them to SQL, and uses PostgreSQL with the DocumentDB extension as its database engine:

MongoDB driver → FerretDB proxy → PostgreSQL + DocumentDB extension

It is not a PostgreSQL client connecting to a MongoDB-compatible server. It is a MongoDB client using a PostgreSQL-backed document database. Test the MongoDB command/BSON matrix, DocumentDB extension, indexes, transactions, backup, and exact version combination.

Migration compatibility matrix

Layer	Required tests	Insufficient evidence
Connection	TLS, SCRAM, startup parameters, prepared statements, pooling	`psql` runs `SELECT 1`
Schema	Types, identity/sequences, generated columns, constraints, partitions	ORM migration succeeds only on an empty database
SQL	Functions/operators, JSONB, CTE/windows, collations, full text	Basic CRUD works
Transactions	Isolation, retries, row locks, deadlocks, advisory locks	A product page says “ACID”
Extensions	Exact version, operators/index methods, update scripts	The extension name appears on an allowlist
Operations	Backup/PITR, CDC, replication, catalogs, monitoring	A backup button exists
Failure	Node/zone failure, connection convergence, RPO/RTO, rollback	Vendor benchmarks or an SLA number

Run application tests and migrations first, restore a masked production copy next, and rehearse cutover and rollback last. For distributed databases such as CockroachDB and YugabyteDB, deliberately induce transaction conflicts, hot partitions, and node failures.

Choosing a direction

For standard PostgreSQL ecology and minimum migration cost, prefer community PostgreSQL or a managed service that explicitly runs it.
For BaaS choose Supabase; for GraphQL-first choose Nhost; for branches and scale-to-zero evaluate Neon.
For multi-region distributed OLTP, evaluate YugabyteDB and CockroachDB as new databases, not as settings.
For an MPP warehouse, evaluate Cloudberry without extrapolating from OLTP benchmarks.
For Oracle migration, evaluate IvorySQL and preserve separate PostgreSQL-mode and Oracle-mode tests.
For continuously updated views, Materialize is a data-layer candidate, not a transparent primary-OLTP replacement.

See free PostgreSQL cloud databases for free tiers and PostgreSQL extension selection for actual extensions.