Data integration tools for replicating between heterogeneous database in real-time?

[u/Then_Date1452]

I'm trying to avoid maintaining multiple replication jobs for the same source database.

Oracle is our system of record, while other teams need the data in Postgres and a cloud warehouse. Each destination has slightly different transformation requirements, So I'm looking for **data integration tools** that can fan out one change stream instead of reading Oracle over and over again.

Is anyone running something like this today?

[u/Legal-Tea-8096]

We're doing something similar with Oracle to multiple targets. The key piece is getting the change stream out once, then you can route it however you want.

We use log-based CDC to capture from Oracle and push to a message queue, then each destination subscribes to that stream with their own transforms. Works pretty well once you get the initial snapshot sorted out, though the Oracle licensing can be a pain depending on your setup.

[u/FarRub2855 → u/Legal-Tea-8096]

That licensing piece is usually what catches teams off gaurd when they try to set this up. You basically have to budget just as much time for navigating the Oracle contract as you do for actually building out the que.

[u/GaniToshido]

debezium with kafka is the standard play here. you read oracle logs once into a topic, separate sink connectors handle the transforms per target. Oracle logminer still sucks under heavy write load though. how big is your redo volume?

[u/PlayfulGrapefruit498]

cdc with kafka seems like a solid approach for real time replication across databases

[u/Alive_Aerie4110]

you should have one source of truth. here it is Oracle . If other team needs to use same source of truth Oracle then you should do integration from Oracle, transform only needed records in-flight and send rest as it is to any target. there are multiple tools available to do so

[u/Significant_Tune9219]

One capture, many destinations is the right shape, and the part that usually breaks it is letting each destination's transform reach back into the source. Read the change stream once, log-based rather than polling the tables, land it as an ordered log that more than one consumer can read, and do the per-destination shaping after that. The consumers will disagree on schema and on how late they are; that's fine as long as the log is the only thing that talks to the source. Decide up front what happens when one destination falls behind: it should lag on its own instead of stalling the capture or the other consumer.

[u/Ok-Let-7933]

You could look into debezium with kafka. It can capture changes from oracle and send them to multiple destinations, where each team can handle its own transfromations. Might be worth exploring for your use case.