AWS Database Migration Service

These pages are a worked example rather than a general manual. They came out of one migration — a self-managed Oracle estate replicated into PostgreSQL on AWS with AWS Database Migration Service — and they keep that shape: the schemas, table names and SCNs are from that engagement, and the procedures assume Oracle as the source and PostgreSQL as the target. The mechanics generalise; the specifics should be read as illustration and adapted, not copied.

Three facts hold across everything here and are worth knowing before reading any of it.

DMS gives at-least-once delivery, not exactly-once. A task that stops and resumes, a TargetTablePrepMode of DO_NOTHING, or a target table with no primary key or unique index can each produce duplicate rows. Design the target to be idempotent and give every replicated table a primary key or unique index.

A task’s CDC start point is fixed when the task is created. AWS documents that it cannot be changed afterwards; to replicate from a different point, create a new CDC-only task. Recovery procedures that modify an existing task’s start position do not work.

CDC is not real-time. Latency varies with source workload, network, instance size and target ingestion rate, and AWS offers no latency SLA. Anything downstream that assumes sub-second freshness will be disappointed intermittently rather than consistently, which is worse.

Pages

• Multi-stage migration implementation plan — Oracle to a PostgreSQL staging schema, joined across databases with a foreign data wrapper, then loaded into a final target table.
• Oracle to PostgreSQL time-window data reload — reloading a specific date range from the source without disturbing an ongoing CDC task.
• How CDC checkpoints work — what DMS records as it replicates, and the recovery options when a task fails.
• Step-by-step CDC recovery guide — the long-form runbook: configuring Oracle and PostgreSQL for recoverable CDC, recovering from a known SCN, and the ongoing maintenance around it.
• Full-load task settings — what TargetTablePrepMode, the stop-after-full-load options and data validation actually do.
• GoldenGate to PostgreSQL with DMS — choosing between connecting DMS directly to production Oracle instances and putting a GoldenGate-fed instance in front of it.
• Joining tables across separate PostgreSQL databases — postgres_fdw, which is how the cross-database join in the multi-stage plan is done.