Oracle’s per-core licensing, support uplifts, and audit exposure make it a perennial cost target. Amazon Aurora (the PostgreSQL-compatible edition) is a common destination for teams that want to drop the Oracle license and hand off database operations to a managed service rather than run PostgreSQL themselves. You trade Oracle licensing for AWS usage-based pricing and managed convenience, and accept cloud lock-in in return.
Why Aurora rather than self-managed PostgreSQL
Aurora PostgreSQL speaks PostgreSQL, so the schema/SQL conversion is essentially the same as an Oracle→PostgreSQL move, but AWS runs the database for you: storage auto-scales, replicas and failover are managed, and backups are built in. The cost shifts from “Oracle license + your DBAs” to “Aurora usage (compute + storage + I/O) .” For cloud-committed teams this is attractive; if you’re not on AWS or want to avoid lock-in, self-managed PostgreSQL is the better fit. Be clear which you’re optimizing for.
What converts, and what doesn’t
The hard work is the same Oracle dialect conversion:
- PL/SQL → PL/pgSQL. Packages, autonomous transactions, and heavy Oracle built-ins need rework.
- Datatypes and semantics.
NUMBER, OracleDATE(carries time), empty-string-is-NULL, sequences/ROWNUM. - Oracle-only features. RAC, partitioning syntax,
CONNECT BY, certain analytic functions map to PostgreSQL/Aurora equivalents or extensions. - Application SQL, hints,
(+)joins,DUAL, usually the largest hidden cost.
There is no Babelfish for Oracle (that’s a SQL Server feature), so unlike a T-SQL move you can’t avoid the PL/SQL conversion. EDB compatibility exists but not on Aurora.
Tooling: SCT + DMS
- AWS Schema Conversion Tool (SCT) assesses complexity and converts schema and code, flagging manual items.
- AWS Database Migration Service (DMS) does the data load plus change-data-capture (CDC) so Aurora stays in sync with Oracle until cutover, minimizing downtime.
Read the SCT assessment report before writing a project plan: it categorizes objects by conversion difficulty and is the most honest early estimate you will get. DMS handles heterogeneous Oracle-to-PostgreSQL type mapping during the load, but it does not convert procedural code, that is SCT’s job, and it will not silently fix a datatype you mapped wrong in the schema. Validate the schema SCT produced before you start the full DMS load, because reloading terabytes to fix a column type is expensive.
The Oracle semantics that still bite
Because Aurora PostgreSQL is PostgreSQL under the hood, the same Oracle semantics bite here as in a self-managed move. Oracle DATE carries a time component and should map to timestamp; an unqualified NUMBER is arbitrary precision and belongs in numeric rather than an integer type; and Oracle’s empty-string-is-NULL rule differs from PostgreSQL, so normalize zero-length strings on load. ROWNUM filtering becomes LIMIT or row_number(), and CONNECT BY hierarchies become WITH RECURSIVE CTEs. SCT flags most of these, but it cannot judge intent, so review each flag rather than accepting the mechanical suggestion.
Making the cutover safe
The CDC design is what makes the cutover safe. Once DMS full-load plus CDC has Aurora tracking Oracle with near-zero lag, the cutover window is short: quiesce writes on Oracle (or set it read-only), let CDC drain to zero, run a final row-count and checksum diff, repoint connection strings at the Aurora writer endpoint, and smoke-test the critical paths. Keep Oracle intact and recoverable through hypercare so rollback is a matter of repointing connections back, not a restore. Because DMS replication is one-directional by default, plan how you would capture any writes that landed on Aurora if you did roll back, even if the realistic answer is a short read-only fallback window rather than a full reverse sync.
The sequence that works
- Assess with SCT; triage objects by conversion difficulty.
- Provision the Aurora cluster (writer + reader replicas), sized on vCPU/ACUs, with the right PostgreSQL major version.
- Convert schema and review SCT action items; load into Aurora.
- Migrate data with DMS full-load + CDC.
- Convert PL/SQL and application SQL in parallel.
- Validate, row counts, data-diffs, an application regression suite, and query-plan/performance comparison against the Oracle baseline.
- Cut over in a window: stop writes, let CDC drain, final diff, repoint connection strings, smoke-test, keep Oracle recoverable through hypercare.
Application SQL changes
The application-side work is the same as any Oracle-to-PostgreSQL move, because Aurora speaks PostgreSQL. Every embedded query, ORM mapping, reporting query, and ETL job that assumed Oracle has to be validated: SELECT ... FROM DUAL, the (+) outer-join operator, optimizer hints, NVL, DECODE, and SYSDATE all become PostgreSQL equivalents such as COALESCE, CASE, and now(). SCT can convert stored code and flag the app-facing constructs it finds, but it cannot reach SQL that lives outside the database, so inventory every place SQL is written before you size the effort. This is routinely the largest hidden cost, and it is unaffected by the fact that AWS is running the engine.
Watch the lock-in and the cost model
Aurora is AWS-specific, moving off it later is itself a project, and egress + I/O + storage billing needs modeling (it’s not just compute). Aurora PostgreSQL also trails community PostgreSQL by a version or two and limits some extensions; confirm yours are supported. The lock-in is a deliberate trade rather than a flaw: you are buying managed operations, auto-scaling storage, and built-in failover in exchange for portability. Decide up front whether that trade fits, because the escape cost is real if your priorities change later.
Weighing managed against lock-in
Oracle → Aurora removes Oracle licensing and database ops in exchange for AWS usage pricing and lock-in. The conversion effort (PL/SQL + app SQL + validation) is the same as any Oracle→PostgreSQL move; the difference is AWS runs it for you. Model Oracle’s per-core cost against Aurora usage in the calculator above, and treat the figures as illustrative until you price a real Aurora configuration and your egress.