// OSSeva Blog
MigrationOracle Database Alternatives: PostgreSQL, EDB, MariaDB, Cloud and Distributed Options Compared
The short answer
For most custom applications, the best open source alternative to Oracle Database is community PostgreSQL: it has the closest procedural language, the widest tooling for Oracle migrations, and runs anywhere. If the application holds a lot of PL/SQL and rewriting it is the obstacle, EDB Postgres Advanced Server, now also called Enterprise Postgres (Oracle Compatible), adds an Oracle compatibility mode on top of PostgreSQL. MariaDB has an Oracle mode of its own and suits teams already running the MySQL family. Aurora PostgreSQL and AlloyDB replace Oracle with a managed service if you are moving to AWS or Google Cloud anyway. YugabyteDB and CockroachDB are for the smaller set of workloads that need writes spread across nodes or regions.
The decision is rarely about features. It is about how much PL/SQL you have, where the database has to run, and who supports it after cutover. The Oracle to PostgreSQL migration guide covers the move itself.
Oracle database replacements compared
Each row reflects what the project or vendor publishes on its own site as of 7 October 2026.
| Option | What it is | Help for Oracle code | Where it runs | Best fit |
|---|---|---|---|---|
| PostgreSQL (community) | Open source relational database | PL/pgSQL is close to PL/SQL; the orafce extension adds Oracle-compatible functions and packages; ora2pg converts schema and part of the code | Anywhere: bare metal, VMs, Kubernetes, any cloud | Custom applications where rewriting stored code is acceptable |
| EDB Postgres Advanced Server (Enterprise Postgres, Oracle Compatible) | EDB's PostgreSQL distribution with added features | An Oracle compatibility mode that EDB says lets many Oracle applications run with minimal to no changes; Migration Portal and Migration Toolkit | On premises, in the cloud or on Kubernetes, per EDB | PL/SQL-heavy applications where rewriting is the blocker |
| MariaDB | Open source relational database from the MySQL family | SQL_MODE=ORACLE accepts PL/SQL syntax for procedures and functions, packages and sequences; EMPTY_STRING_IS_NULL mimics Oracle's empty strings | Anywhere | Teams with MySQL-family skills and moderate PL/SQL |
| MySQL | Open source relational database | Stored procedures, functions, triggers and events, but no packages, so PL/SQL is rewritten | Anywhere | Applications with little logic in the database |
| Amazon Aurora PostgreSQL | AWS managed database that AWS describes as fully compatible with PostgreSQL | AWS SCT and DMS for conversion and replication; orafce is available | AWS only | Oracle exits that are also AWS moves |
| AlloyDB for PostgreSQL | Google Cloud managed, PostgreSQL-compatible database; AlloyDB Omni is a downloadable edition | Google's Database Migration Service supports Oracle to AlloyDB | Google Cloud; Omni runs elsewhere | Oracle exits that are also Google Cloud moves |
| YugabyteDB | Open source distributed SQL database with a PostgreSQL-compatible API | YugabyteDB Voyager migrates from Oracle, PostgreSQL and MySQL | Self-managed, Kubernetes, or Yugabyte's managed service | Workloads that need horizontal write scale or multi-region |
| CockroachDB | Distributed SQL database | Speaks the PostgreSQL wire protocol and most PostgreSQL syntax, with documented differences | Self-managed or CockroachDB's cloud service | Workloads that need horizontal write scale or multi-region |
How the options differ
Community PostgreSQL
PostgreSQL is the target most Oracle migration tooling is built for, and for practical reasons. PL/pgSQL follows the same block structure as PL/SQL, the PostgreSQL manual has a section on porting from it, and the open source tooling is mature: ora2pg for assessment and conversion, orafce for the Oracle functions and packages applications call most. It runs on any infrastructure, every major cloud offers it as a service, and no single vendor controls it. The trade-off is that code gets converted rather than run as is, and the team picks a source of support, because the community fixes bugs in released versions for five years and then stops. Our migration challenges post lists the conversion traps.
EDB Postgres Advanced Server
EDB's documentation describes Enterprise Postgres (Oracle Compatible), also known as EDB Postgres Advanced Server, as PostgreSQL with extended functionality, available in a Postgres mode and an Oracle compatibility mode. In Oracle mode it aims to make PostgreSQL "look, feel, and operate more like Oracle", and EDB ships tools around it: Migration Portal, which converts Oracle schemas to Advanced Server online, the Migration Toolkit, EDB*Loader, an OCI-compatible connector and dblink_ora for querying Oracle. If you have a large PL/SQL estate and limited appetite for rewriting it, this is the strongest fit in the list. The trade-off is that code written against the compatibility features depends on Advanced Server, so a later move to community PostgreSQL means converting it after all. We compare the two support models at OSSeva vs EDB.
MariaDB and MySQL
MariaDB's SQL_MODE=ORACLE, available since 10.3, accepts Oracle PL/SQL syntax for stored procedures and functions, supports CREATE PACKAGE and CREATE PACKAGE BODY, and has an EMPTY_STRING_IS_NULL mode for Oracle's empty-string rule. Its documentation lists the supported syntax and the remaining differences, which is the page to read before choosing it. MySQL's stored objects are procedures, functions, triggers, events and views, with no packages, so PL/SQL is rewritten. Both suit applications built around simple queries more than ones with business logic in the database.
Aurora PostgreSQL and AlloyDB
The managed services remove the database operations work and come with their own migration services: AWS SCT and DMS for Aurora, and Google's Database Migration Service for AlloyDB and Cloud SQL. Both are PostgreSQL-compatible engines run by the provider, on the provider's version schedule. Google says AlloyDB tracks PostgreSQL releases and offers extended support if you need more time to upgrade, and AWS charges for RDS and Aurora Extended Support once a version's standard support ends, as our post on RDS Extended Support costs sets out. Choose them when the Oracle exit is part of a cloud move. If the goal is to stop depending on one vendor, a single-cloud engine moves that dependency rather than ending it.
YugabyteDB and CockroachDB
YugabyteDB describes itself as a distributed PostgreSQL database and is open source; its Voyager tool lists Oracle among its migration sources. CockroachDB supports the PostgreSQL wire protocol and the majority of PostgreSQL syntax, and documents the PostgreSQL features it does not support or handles differently. Both are built for databases that must scale writes across nodes or survive the loss of a region. An OLTP system that runs well on one primary with replicas gains complexity, not capacity, from a distributed database.
How to choose
| Situation | Usual answer |
|---|---|
| Custom application, PL/SQL you are willing to convert, any infrastructure | Community PostgreSQL |
| Large PL/SQL estate and rewriting is the blocker | EDB Postgres Advanced Server in Oracle compatibility mode |
| Team already runs MySQL or MariaDB, moderate stored code | MariaDB with Oracle mode |
| Oracle exit combined with a move to AWS or Google Cloud | Aurora PostgreSQL or AlloyDB |
| Writes must scale across nodes or regions | YugabyteDB or CockroachDB |
| Packaged application certified only on Oracle | Stay on Oracle, and review the support options in what to do when an Oracle audit or renewal lands |
Where OSSeva fits
OSSeva supports community PostgreSQL, not a fork of it. OSSeva for PostgreSQL covers current versions on the Assure and Operate tiers and ships patched builds for versions past community end of life, today 11, 12 and 13 and, from 12 November 2026, 14. That means the version you migrate onto stays supported however long the Oracle programme runs. Assure includes Oracle-to-Postgres migration design, and the same contract can cover the MySQL, MariaDB, Kafka, RabbitMQ and other open source systems around the database, with one renewal date, priced per cluster. If your plan depends on running PL/SQL unchanged, EDB's Oracle compatibility mode is the better fit; OSSeva vs EDB sets out the differences. For the migration itself, see Oracle to PostgreSQL with OSSeva, and for support providers across PostgreSQL versions, PostgreSQL support after end of life.
Frequently asked questions
What are the best Oracle database alternatives?
Community PostgreSQL for most custom applications, EDB Postgres Advanced Server where PL/SQL must run with few changes, MariaDB for MySQL-family teams, and Aurora PostgreSQL or AlloyDB when the move is also a cloud move.
What is the best open source alternative to Oracle Database?
PostgreSQL. It has the closest procedural language, a section on porting from Oracle in its manual, and the open source migration tools ora2pg and orafce.
Can PostgreSQL replace Oracle Database?
For most OLTP and reporting workloads, yes. The work is in converting PL/SQL and testing behaviour differences such as empty strings and DATE columns, not in missing database features.
Is EDB the same as PostgreSQL?
EDB Postgres Advanced Server is EDB's distribution built on PostgreSQL, with extra features and an Oracle compatibility mode. EDB also supports community PostgreSQL.
Is MariaDB compatible with Oracle?
Partly. With SQL_MODE=ORACLE, MariaDB accepts PL/SQL syntax for procedures, functions and packages. Its documentation lists the differences that remain.
Tags
Ready to get your open source under control?
Talk to an OSSeva engineer about CVE coverage, compliance, and migration support for your stack.