Oracle GoldenGate to PostgreSQL with AWS DMS
An Oracle estate that already runs GoldenGate between its own instances has more than one route into PostgreSQL on AWS. The choice is mostly about where DMS attaches: directly to a production instance, or to a dedicated instance that GoldenGate feeds. This page compares the options and then covers the configuration the chosen one needs.
The starting position
Section titled “The starting position”The pattern this applies to, in general terms: several Oracle instances across two or more datacentres, GoldenGate performing homogeneous replication between them, and a business application connecting through an Oracle service name so that it reaches whichever instance is currently active. There is usually a private link to AWS already in place, some of the data is encrypted with Transparent Data Encryption, and application-to-database traffic is frequently not encrypted in transit because it never left the datacentre.
┌─────────────────┐ ┌─────────────────────────┐│ │ │ Datacenter A ││ Business │ │ ┌─────────────────┐ ││ Application │◄───Oracle Service Name──────────┼─►│ Oracle DB A1 │ ││ │ │ └─────────────────┘ │└─────────────────┘ │ │ │ ┌─────────────────┐ │ │ │ Oracle DB A2 │ │ │ └─────────────────┘ │ └─────────────────────────┘ │ │ GoldenGate │ Replication ▼ ┌─────────────────────────┐ │ Datacenter B │ │ ┌─────────────────┐ │ │ │ Oracle DB B1 │ │ │ └─────────────────┘ │ │ │ │ ┌─────────────────┐ │ │ │ Oracle DB B2 │ │ │ └─────────────────┘ │ └─────────────────────────┘The target is PostgreSQL on AWS with ongoing CDC, and — in most cases — TLS on the migration path whether or not the existing application connections have it, since that path leaves the building.
What the decision has to balance: minimal disruption to the application, consistency of the data during and after the migration, a secure transfer path, whatever value the existing GoldenGate investment still has, and the Oracle-to-PostgreSQL compatibility work that has to happen anyway.
Options
Section titled “Options”1. DMS connected directly to an Oracle instance
Section titled “1. DMS connected directly to an Oracle instance”DMS connects to one Oracle instance per datacentre, with TLS enabled on those connections specifically.
For: simplest architecture, no new components, and DMS’s own CDC does all the work. TLS can be turned on for the DMS connections without touching how the application connects.
Against: the DMS endpoint points at a specific instance, so a failover means reconfiguring it — and a task’s CDC start point cannot be changed, so that reconfiguration is a new task. It requires firewall rules from AWS into the production database, and it puts the migration’s read load on a production instance.
2. DMS reading a dedicated Oracle instance that GoldenGate feeds
Section titled “2. DMS reading a dedicated Oracle instance that GoldenGate feeds”GoldenGate consolidates changes from the production instances into one additional Oracle instance, which becomes the DMS source.
For: uses the GoldenGate replication that already exists; keeps migration traffic entirely off the production databases; gives DMS a single, stable endpoint regardless of which production instance is active, which removes the failover problem in option 1. TLS and network access controls can be applied to that one instance without affecting anything else.
Against: an additional Oracle instance to license, run and keep in step; more moving parts; and another replication hop, so slightly more end-to-end latency.
3. DMS for the initial load, GoldenGate for ongoing CDC
Section titled “3. DMS for the initial load, GoldenGate for ongoing CDC”DMS performs the full load into PostgreSQL, and GoldenGate handles heterogeneous replication from Oracle to PostgreSQL thereafter.
For: GoldenGate’s replication is mature and its transformation capabilities are more flexible than DMS transformation rules. DMS’s parallel full load is usually the faster way to move the initial dataset.
Against: heterogeneous replication requires a GoldenGate licence covering non-Oracle targets, which is a different and more expensive thing from the homogeneous licence the estate already has. It needs operational expertise in both tools, and the handover point between the DMS load and the GoldenGate stream has to be established precisely or rows are lost or duplicated.
4. Schema conversion plus DMS, with a GoldenGate-isolated source
Section titled “4. Schema conversion plus DMS, with a GoldenGate-isolated source”Option 2’s topology, with schema conversion treated as an explicit first stage.
For: the schema work is assessed and done before any data moves, which is where the Oracle-to-PostgreSQL effort actually lives; production stays isolated from the migration; TLS is confined to the dedicated path.
Against: the most components of any option, and it needs people comfortable across all of them.
Schema conversion is a stage in every one of these options rather than a differentiator — it is listed separately here only because treating it as an afterthought is a common and expensive mistake. Both the standalone AWS Schema Conversion Tool and DMS Schema Conversion, the managed console feature built on the same conversion engine, produce an assessment report first; run it early, because it tells you how much of the migration is schema work rather than data movement.
Choosing
Section titled “Choosing”Options 2 and 4 are the usual answer where GoldenGate is already in place and the application connects through a service name that can move between instances: the dedicated instance removes both the failover problem and the production read load, at the cost of one more Oracle instance. Option 1 is reasonable where the estate is a single instance with a stable address. Option 3 is worth the licence only where GoldenGate’s transformation capability is genuinely needed.
Target architecture for the dedicated-instance options
Section titled “Target architecture for the dedicated-instance options”┌─────────────────┐ ┌─────────────────────────┐│ │ │ Oracle Service ││ Business │◄───Oracle Service Name──────────┼─►┌─────────────────┐ ││ Application │ │ │ Connection │ ││ │ │ │ Manager Proxy │ │└─────────────────┘ │ └──────┬──────────┘ │ └──────────┼───────────────┘ │ ┌──────────────────────┐ │ ┌──────────────────────┐ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌─────────────────────────┐ ┌─────────────────────────┐ ┌─────────────────────────┐ │ Datacenter A │ │ Datacenter A │ │ Datacenter B │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ ┌─────────────────┐ │ │ │ Oracle DB A1 │ │ │ │ Oracle DB A2 │ │ │ │ Oracle DB B1 │ │ │ │ (TDE enabled) │ │ │ │ (TDE enabled) │ │ │ │ (TDE enabled) │ │ │ └─────────────────┘ │ │ └─────────────────┘ │ │ └─────────────────┘ │ └─────────────────────────┘ └─────────────────────────┘ └─────────────────────────┘ │ │ │ │ GoldenGate │ │ └───────────Replication─────┴─────────────────────────────┘ │ ▼┌───────────────────────┐ ┌─────────────────────────────────┐│ AWS │ │ Dedicated Migration ││ │ Direct │ Environment ││ ┌─────────────────┐ │ Connect │ ┌───────────────────────────┐ ││ │ │ │ │ │ Oracle TLS Listener │ ││ │ DMS │ │ │ │ (Port 2484) │ ││ │ Replication │◄─┼─TLS Connection──┼─►│ │ ││ │ Instance │ │ with TDE Wallet │ │ Migration Oracle DB │ ││ │ │ │ │ │ (TDE Keys Available) │ ││ └─────────────────┘ │ │ └───────────────────────────┘ ││ │ │ └─────────────────────────────────┘│ │ ││ ▼ ││ ┌─────────────────┐ ││ │ │ ││ │ PostgreSQL │ ││ │ Target with │ ││ │ pgcrypto │ ││ └─────────────────┘ ││ │└───────────────────────┘Oracle service components
Section titled “Oracle service components”Oracle Net Listener receives the connection request for a service name such as PROD_SERVICE
and forwards it according to the service configuration.
Connection Manager (CMAN) proxies between clients and database servers, balancing across available instances, multiplexing sessions, and applying network access control rules.
PROD_SERVICE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = oracle-cman.example.com)(PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = PROD_SERVICE) ) )A separate service for the migration path, TLS-only on port 2484:
MIGRATION_SERVICE = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCPS)(HOST = migration-oracle.example.com)(PORT = 2484)) (CONNECT_DATA = (SERVICE_NAME = MIGRATION_SERVICE) ) (SECURITY = (SSL_SERVER_CERT_DN = "CN=migration-oracle.example.com,O=Example Ltd") ) )Give the migration service its own listener and its own CMAN profile, point it only at the dedicated instance, and restrict access to the DMS replication instance’s addresses.
Implementation
Section titled “Implementation”1. Prepare the environment
Section titled “1. Prepare the environment”Stand up the dedicated Oracle instance that will be GoldenGate’s target and the DMS source, configure TLS on it, establish connectivity from AWS, and provision the DMS replication instance. Where the source data uses Transparent Data Encryption, set up the Oracle wallet on the dedicated instance with the TDE keys — DMS reads decrypted data from the instance, so the instance must be able to decrypt it.
2. Configure Connection Manager and services
Section titled “2. Configure Connection Manager and services”Create the dedicated TLS service described above, apply network access control rules to it, and test routing through both the standard and the TLS service before going further.
3. Configure GoldenGate
Section titled “3. Configure GoldenGate”Replicate from all production instances into the dedicated instance. Verify that every table and schema in scope is included — a table missing from the GoldenGate configuration is a table that silently never migrates. Confirm GoldenGate has wallet access for TDE-encrypted columns, and measure replication lag and consistency under production load rather than at rest.
4. Configure TLS on the dedicated instance
Section titled “4. Configure TLS on the dedicated instance”Generate a CSR, sign it with an internal CA or a private certificate authority, and import the certificate and chain into an Oracle wallet.
LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = migration-oracle.example.com)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCPS)(HOST = migration-oracle.example.com)(PORT = 2484)) ) )
WALLET_LOCATION = (SOURCE = (METHOD = FILE)(METHOD_DATA = (DIRECTORY = /oracle/wallet)))SSL_CLIENT_AUTHENTICATION = FALSETest TLS connectivity locally before involving DMS, and record the configuration — certificate expiry on a migration path is a failure mode that arrives without warning.
5. Convert the schema
Section titled “5. Convert the schema”Run the assessment, convert the schema, review what could not be converted automatically, and
create the target schema in PostgreSQL. Data-type decisions taken here — particularly Oracle
NUMBER without explicit precision, and DATE, which carries a time component — determine what
the DMS transformation rules have to do later.
6. Configure DMS
Section titled “6. Configure DMS”Source endpoint against the dedicated instance, TLS verified, credentials from Secrets Manager:
{ "EndpointIdentifier": "oracle-tde-source", "EndpointType": "source", "EngineName": "oracle", "ServerName": "migration-oracle.example.com", "Port": 2484, "DatabaseName": "MIGDB", "SslMode": "verify-full", "CertificateArn": "arn:aws:dms:region:account:certificate:cert-id", "SecretsManagerSecretId": "prod/oracle/dms_user", "SecretsManagerAccessRoleArn": "arn:aws:iam::account:role/dms-secrets-access", "ExtraConnectionAttributes": "useLogminerReader=N;useBfile=Y"}Two notes on those extra connection attributes.
The path-prefix attributes are Amazon RDS-specific. Binary Reader examples widely copied from
RDS documentation carry
accessAlternateDirectly=false;useAlternateFolderForOnline=true;oraclePathPrefix=/rdsdbdata/…;usePathPrefix=/rdsdbdata/log/;replacePathPrefix=true.
/rdsdbdata/ is RDS for Oracle’s internal directory layout. On a self-managed instance those
directories do not exist, Binary Reader cannot locate the redo logs, and the endpoint fails its
connection test. On a self-managed host Binary Reader reads the redo and archive destinations
configured on that host, so useLogminerReader=N;useBfile=Y is the whole of it. (For reference,
AWS documents the path-prefix set only for RDS Oracle 11.2 and 12.1; for RDS 12.2, 18 and 19 it
reduces to useLogminerReader=N;useBfile=Y as well.)
Pick Binary Reader or LogMiner once, and say why. useLogminerReader=N above selects Binary
Reader; the task settings in the other DMS guides here set "UseLogminerReader": true. AWS’s
recommendation is LogMiner in general, and Binary Reader where the redo volume is high, where
several DMS tasks read the same source, where LOB support or XA transactions are needed, or on
Oracle RAC. A dedicated GoldenGate-fed instance carrying the consolidated change volume of several
production databases is precisely the high-redo case, so Binary Reader is the reasonable default
here — but a mixture of both across tasks against the same source is a configuration accident
rather than a decision.
Then create the PostgreSQL target endpoint, a replication task for full load plus CDC, and the table mappings and transformation rules the schema conversion identified as necessary.
7. Encryption on the target
Section titled “7. Encryption on the target”TDE does not survive the migration: DMS reads decrypted values and writes them to PostgreSQL,
which has no equivalent feature. Decide what replaces it before the first load, not after.
Storage-level encryption on the RDS or Aurora instance covers data at rest. Where individual
columns need to stay encrypted from the application’s point of view, pgcrypto with keys held in
AWS KMS is the usual arrangement — and it changes how those columns can be queried, which is a
schema decision rather than an operational one.
8. Execute
Section titled “8. Execute”Run the initial full load while the application continues against Oracle. Validate the result in PostgreSQL against the source, paying particular attention to columns that were TDE-encrypted. Enable ongoing CDC and watch replication lag and data consistency until both are boring.
9. Cut over
Section titled “9. Cut over”Repoint the application at PostgreSQL, monitor its behaviour and performance, and keep the GoldenGate and DMS replication running for a rollback window before decommissioning anything.
Security
Section titled “Security”- TLS configured and verified on the dedicated Oracle instance, with certificate expiry monitored.
- The DMS replication instance in a private subnet with security groups that permit only what the migration needs.
- A private link between AWS and on-premises rather than traffic over the public internet.
- Database credentials in AWS Secrets Manager and referenced by the endpoints, never passed on a command line or written into a task definition.
- Audit logging enabled on source and target.
- Network ACLs and security groups restricted to the required flows, in both directions.
Monitoring and validation
Section titled “Monitoring and validation”- Checksum or row-level validation on the tables that matter, not only row counts.
- DMS task metrics in CloudWatch, with alarms on
CDCLatencySourceandCDCLatencyTargetcrossing an agreed threshold. - Periodic row-count and sample comparisons between source and target through the replication period.
- Application-level tests against the PostgreSQL target, because type and collation differences surface as wrong answers rather than as errors.
Network detail
Section titled “Network detail”- Security groups in the AWS VPC must allow outbound connections to the Oracle instance on port 2484 (TCPS).
- The on-premises firewall must allow inbound connections from the DMS replication instance’s addresses to that port.
- Upload the CA certificate to DMS and configure the endpoint for
verify-full, so the certificate is actually checked rather than merely presented. - Where a dedicated link carries both migration and production traffic, give the migration its own class so a full load cannot starve the application.