EDB Alternatives: Where to Get PostgreSQL Support If Not From EnterpriseDB

The short answer

The right EDB alternative depends on which PostgreSQL you run. EDB supports community PostgreSQL as well as its own distributions, Enterprise Postgres (Oracle Compatible), formerly EDB Postgres Advanced Server, and EDB Postgres Extended Server. If your clusters run community PostgreSQL, you can change support vendor without touching the data: other support companies, Percona's open source distribution, a managed cloud service or patched builds from OSSeva all work. If your applications depend on EDB's Oracle compatibility, such as SPL packages and Oracle-style data types and catalog views, EDB is usually the better fit until that dependency is removed.

First, check which PostgreSQL you run

Run this on each cluster:

SELECT version();
SHOW server_version;
SELECT extname, extversion FROM pg_extension ORDER BY extname;

The version string, the packages installed on the host and the repository they come from together show whether a cluster runs community PostgreSQL or one of EDB's own servers. Community PostgreSQL installed from EDB's repository is still community PostgreSQL, and any vendor can support it.

If you run EDB's Oracle-compatible server, list what the applications use: SPL procedures and packages, Oracle data types, Oracle-style catalog views and built-in packages. That list decides whether leaving is a support change or a migration.

EDB alternatives compared

Each row reflects what the provider publishes on its own site as of 7 October 2026.

The options in more detail

Community PostgreSQL with another support vendor

The shortest path. Your binaries, data, extensions and HA tooling stay as they are, and a new vendor takes over incidents and fixes. Percona, OpenLogic and Instaclustr all list PostgreSQL support for self-managed servers. Check each against your exact versions: EDB's published support for PostgreSQL 14.x ends on 1 December 2026, and most vendors follow the community dates, which end 14 on 12 November 2026. PostgreSQL end-of-life support providers compares who covers which version.

Percona Distribution for PostgreSQL

Percona states that all of its PostgreSQL software is fully open source, with no gated features, proprietary extensions or commercial-only editions. Its stack adds pg_tde for encryption at rest, a Kubernetes Operator and Percona Monitoring and Management. Moving to it means changing packages, which is a planned change rather than a data migration. OSSeva vs Percona covers how the two differ on end-of-life versions.

Managed cloud PostgreSQL

RDS and Aurora PostgreSQL, Azure Database for PostgreSQL and Cloud SQL or AlloyDB on Google Cloud take operations off your team. They also bring a migration, the provider's version calendar and paid extended support when a major version ages out. RDS Extended Support for PostgreSQL covers what that costs on AWS.

OSSeva

OSSeva supports the community PostgreSQL you run today with no migration: keep your binaries, change your support. It ships signed patched builds for 11, 12 and 13 now and for 14 after 12 November 2026, as DEB and RPM packages, tarballs and container images that install like a minor release under Patroni or repmgr. Extensions are tested for compatibility with each build; their own code stays with their maintainers. OSSeva Assure adds major-version migration planning and Oracle-to-PostgreSQL migration design, and OSSeva Operate adds 24/7 operations with a 15-minute P1 response. PostgreSQL sits under the same contract as MySQL, Redis, RabbitMQ and Kafka, priced per cluster.

When to stay with EDB

EDB's Oracle-compatible server adds Oracle-compatible data types, keywords, functions and Oracle-style catalog views, and its SPL language supports procedures, functions, triggers and packages. Applications written against those features do not run on community PostgreSQL without conversion. The open source orafce extension emulates a subset of Oracle functions and packages and is available on Aurora PostgreSQL and Azure, but it is not a full replacement. If your estate depends on these features, the honest answer is to stay with EDB for those clusters and treat leaving as an Oracle-compatibility migration, planned on its own timeline. The same applies if you use EDB's own tooling or its managed cloud service and want to keep them.

A split is common: EDB for the Oracle-compatible clusters, another vendor for the community PostgreSQL clusters, on separate renewal dates until the first group shrinks.

How to leave without a gap

1. Inventory every cluster: distribution, version, extensions, HA tooling and where it runs.
2. Separate community PostgreSQL clusters from EDB-server clusters.
3. Check the EDB contract for the renewal date, the notice period and whether it renews automatically.
4. Give the new vendor the inventory and ask in writing which versions it fixes, until when, and who applies the fixes.
5. Agree a start date before the EDB term ends, and export ticket history and runbooks.

Switching PostgreSQL support vendors without migrating covers the handover step by step, and OSSeva vs EDB compares the two directly.

Frequently asked questions

What are the best EDB alternatives?

For community PostgreSQL: another support vendor such as Percona, OpenLogic, Instaclustr or OSSeva, Percona Distribution for PostgreSQL, or a managed cloud service. For EDB's Oracle-compatible server there is no drop-in alternative, because applications depend on its Oracle features.

Is there an open source alternative to EDB Postgres Advanced Server?

Community PostgreSQL is the open source base, and the orafce extension covers some Oracle functions and packages. Neither covers all of EDB's Oracle compatibility, so moving off it means converting the code that relies on it.

Can we leave EDB without migrating data?

Yes, if the clusters run community PostgreSQL. A new vendor supports the binaries and data you have. If they run EDB's own server, leaving involves converting Oracle-compatible code and moving data.

Which PostgreSQL versions does EDB support?

EDB's platform compatibility page lists community PostgreSQL, EDB Postgres Advanced Server and Extended Server versions with their own end dates, for example 14.x to 1 December 2026 and 18.x to 25 November 2030. Check the page for the versions you run.

Who supports PostgreSQL besides EDB?

Percona, OpenLogic, Instaclustr and OSSeva support self-managed PostgreSQL. AWS, Microsoft and Google run it as managed services. The PostgreSQL Global Development Group maintains the code and fixes each major version for five years.