Database licensing, especially Oracle and SQL Server, is among the costliest line items in IT, and per-vCPU pricing makes virtualization savings hard to capture. Open engines like PostgreSQL, MySQL, and MariaDB remove the license entirely; the work is conversion and validation, not the data movement itself.
The economics
Commercial databases license by the vCPUs of the server. Oracle applies a core factor and generally expects you to license every core a workload can run on, which limits virtualization savings unless you use approved hard partitioning. PostgreSQL/MySQL/MariaDB cut the license to zero; ongoing cost becomes infrastructure plus optional commercial support (EDB, Percona, Crunchy, MariaDB plc).
What converts cleanly, and what doesn’t
Tools like ora2pg, pgloader, and AWS SCT automate the mechanical majority: schema, indexes, constraints, sequences, and much stored-procedure logic. Plan engineering time for:
- Stored procedures / packages, complex PL/SQL or T-SQL needs rework.
- Datatype & semantics,
NUMBER/DATE, empty-string-vs-NULL,ROWNUM, identity/sequence patterns. - Application SQL, hints, vendor outer-join syntax,
DUAL, and DB-specific functions.
If a SQL Server rewrite is the blocker, Babelfish for Aurora PostgreSQL can accept T-SQL directly; for Oracle, EDB Postgres Advanced Server maximizes compatibility at the cost of a subscription.
The engine you land on shapes everything
The engine you land on shapes the whole project. PostgreSQL is the default for most commercial-database exits: no license fee, a deep extensions ecosystem, and enough enterprise features (partitioning, parallel query, logical replication) to cover most Oracle, SQL Server, and Db2 workloads. MySQL or MariaDB fit high-volume, relatively simple OLTP and applications already built around that ecosystem, but are weaker on complex procedural and analytical SQL. Amazon Aurora hands database operations to AWS in exchange for usage-based pricing and cloud lock-in, and its PostgreSQL-compatible edition converts the same way self-managed PostgreSQL does. A document store like MongoDB is a different move again: you re-model documents into relational tables or Postgres JSONB and rewrite the query layer, so treat it as a re-platforming, not a dialect port.
The procedural code is the long pole
Across every path, the stored logic is where estimates go wrong. Oracle PL/SQL, SQL Server T-SQL, and Db2 SQL PL all convert to the target’s procedural language (usually PL/pgSQL), and the converters handle a large share of it, but packages, autonomous transactions, error-handling blocks, and vendor built-ins rarely convert at 100%. Read the assessment report each tool produces before committing to a schedule: it categorizes objects by difficulty and is the most honest early estimate you will get. Budget the manual review explicitly rather than assuming the automated output is production-ready.
A low-downtime flow
Assess → provision the target (primary + replicas) → convert and load the schema → migrate data via dump/restore for the rehearsal, then CDC replication to stay current → convert procedures and app SQL in parallel → validate with row counts, checksums, regression tests, and query-plan comparisons → cut over at zero replication lag, keeping the source recoverable.
Testing is the project
The depth of your parallel-run predicts cutover success. Replay representative workloads against both databases, compare results and plans, and only promote when the target meets documented correctness and performance criteria. NoSQL and analytics migrations follow the same shape, export, load, re-point, validate.
Open any source→target page for the pair-specific tooling (e.g. ora2pg/pgloader commands) and a TCO model sized on vCPUs.