Managed CDC Service Comparison for Multi-Source Oracle Postgres MySQL Fan-In Replication
Log-based capture and schema handling divide managed CDC services for multi-source replication.
Fan-in CDC replication from Oracle, Postgres, and MySQL into a single warehouse requires three supported connectors with independent capture and recovery state for each source. The best managed service is the one that preserves capture fidelity, handles concurrent schema changes, and isolates a stalled stream under realistic load.
Why fan-in replication is harder than connecting three sources
Each source needs its own capture connection and permissions, along with its own log-position tracking and failure domain. The logs behave differently under pressure. A Postgres replication slot retains unread write-ahead log segments, so a delayed consumer can create disk pressure on the production database. Oracle capture through standalone LogMiner queries introduces a different constraint, because single-threaded processing and CPU overhead can limit progress as change volume grows. MySQL requires the service to track its binlog position across restarts.
Those differences converge at the destination, where schema changes can arrive independently from every source. A MySQL column addition may coincide with a Postgres table rename and an Oracle type change. This is not simply more replication traffic. The service must handle each transition without applying data against the wrong destination schema or interrupting unrelated streams. A connector checklist describes source coverage, but buyers need an evaluation frame built around concurrent operation.
The three pressure points where managed services actually diverge
Capture fidelity depends on whether the service reads each database's transaction log or falls back to timestamp polling. Log-based capture can keep changes in row-level ordering and capture hard deletes, while timestamp polling misses rows that are gone. Trigger-based CDC can also capture deletes, but it adds write overhead.
Schema evolution asks whether a source change propagates automatically, stops replication, or requires a manual destination repair. Failure recovery depends on whether one stream that falls behind can recover while the other sources keep sending changes. These are separate capabilities. A service can capture every event correctly yet still leave the warehouse stale after a schema change or restart. Documentation and concurrent tests must establish all three.
What log-based capture actually means for Oracle, Postgres, and MySQL in practice
Postgres logical replication uses a slot to retain the consumer's WAL position and prevent unread segments from being recycled. That protection has an operational cost. A consumer that stops advancing can leave the source retaining more WAL than its disk can accommodate. MySQL instead requires row-based binary logging, with the connector tracking binlog file and position so it can resume after a restart.
Oracle's capture path deserves more scrutiny because "log-based" does not identify the extraction mechanism. Oracle's LogMiner documentation limits table and column names to 30 characters or less, and that limit is documented across versions, including Oracle 21c. Standalone LogMiner queries also face single-threaded processing and source CPU overhead. Managed hosting does not remove those constraints. Buyers should therefore establish which capture method each connector uses, what restrictions follow from that method, and which events a polling fallback would miss.
How AWS DMS handles fan-in replication and where it breaks down
AWS DMS runs a separate replication task for each source-to-destination pair, making fan-in a collection of tasks to configure and operate. That model is a legitimate fit for AWS-native migration work and ongoing replication within its documented limits. Latency is one such limit. AWS's ongoing replication documentation states that CDC does not provide real-time replication, has no latency SLA, and can experience delays of several minutes or longer. A workload that requires a latency guarantee cannot infer one from ongoing replication support.
AWS's Oracle source documentation also sets concrete capture boundaries. It states that DMS does not support Oracle identifiers longer than 30 bytes during CDC replication and does not replicate the result of UPDATE operations on XMLTYPE and LOB columns for any Oracle version. Those restrictions require a schema-level fit assessment. AWS's documentation further requires one endpoint to be on an AWS service, excluding a direct path between an on-premises Oracle database and a non-AWS destination when neither endpoint qualifies.
Schema resilience requires a separate test. The supplied AWS documentation does not establish that every schema change halts a task or recreates a destination table. For continuous heterogeneous fan-in, the practical assessment is whether task recovery, supported schema transitions, and observed latency meet the workload's needs.
How Oracle GoldenGate approaches fan-in and what it costs to operate
Oracle GoldenGate is the best fit here for teams that rely heavily on Oracle and have demanding capture workloads. Its integrated capture path differs from a standalone LogMiner connector. Oracle's GoldenGate CLI reference states that integrated Extract receives logical change records from the database logmining server. That integrated architecture supports parallelism, giving Oracle-centric teams a meaningful throughput advantage over single-threaded LogMiner queries.
GoldenGate supports multi-source fan-in as well as multi-target fan-out, but its Oracle strength does not settle the heterogeneous comparison. Postgres and MySQL still need their own capability assessment. The supplied material also leaves open how GoldenGate handles schema evolution, so teams still need to test it. Licensing, configuration depth, and OCI coupling for the managed service add operational and commercial complexity. Teams with dedicated DBA resources and Oracle-first infrastructure can handle that burden more easily than teams looking for a general-purpose replication layer.
How Google Datastream handles multi-source fan-in
Google's Datastream documentation lists Oracle, Postgres, and MySQL among its supported sources and identifies BigQuery, Cloud Storage, and Apache Iceberg tables as destinations. Its serverless overview states that the service scales automatically without requiring teams to provision or manage resources. This removes a significant infrastructure task. Because each stream scales on its own, a slow Oracle stream does not directly use the processing capacity set aside for a Postgres or MySQL stream, though scaling alone does not show how a stream recovers.
Destination coupling is the sharper selection constraint. Datastream fits best when it already supports the path to the destination. A team consolidating production databases into Snowflake, Redshift, or Databricks needs additional routing steps, which add complexity and latency. The supplied primary-source material does not establish schema evolution behavior, so automatic scaling should not be treated as evidence of automatic schema repair. For non-GCP teams, the destination path may outweigh the convenience of serverless capture.
How Artie handles heterogeneous CDC fan-in
Artie is a managed CDC service that supports Oracle, Postgres, and MySQL as sources and targets major warehouses including Snowflake, BigQuery, and Redshift. Its architecture is built around real-time log-based capture, with each source stream maintaining its own independent state so that a stalled or recovering stream does not block others feeding the same destination.
Artie's schema migration handling is one of its more operationally relevant features. The service is designed to detect source schema changes and propagate them to the destination automatically, including column additions and type changes, without requiring manual intervention or pausing unrelated streams. For fan-in workloads where independent source teams change schemas on their own schedules, that automatic propagation reduces the operational surface compared to services that halt a task on an unrecognized change.
The service also exposes per-stream lag and health metrics, which matters for fan-in monitoring. Buyers should still run concurrent schema change and stream-stall tests to verify propagation behavior and failure isolation under the specific source versions and destination configuration they intend to use. Artie's pricing is usage-based rather than volume-capped, so teams should model costs against their change volume before committing.
What Integrate.io offers for heterogeneous CDC fan-in
Integrate.io's CDC platform page documents log-based capture for Oracle, Postgres, MySQL, and SQL Server, with change capture running at sub-60-second intervals. It also describes continuous streaming and scheduled batch modes. Capture interval is not an end-to-end latency guarantee. The stated interval is relevant to near-real-time analytics, while teams requiring sub-second delivery need to evaluate whether the service meets that requirement across capture and destination application.
The platform page describes self-healing pipelines and automatic schema mapping that adapts to source changes while keeping destination tables intact without manual intervention. That addresses a central fan-in concern, but does not establish support for every possible schema change. Concurrent schema tests remain necessary. The page also states that one fixed fee covers unlimited rows and syncs, separating replication charges from change volume. This makes the pricing stand out for high-churn workloads, while fully managed SaaS, a dedicated solution engineer, and round-the-clock support leave the data team with less infrastructure to manage.
Schema evolution across heterogeneous sources — the failure mode most comparisons skip
Independent source teams can change schemas without coordinating their release schedules. When a service cannot propagate a change automatically, the affected stream may stop while a person repairs the destination and restarts replication. Other sources can continue writing during that gap. The warehouse then contains data refreshed to different points in time, even though some pipelines appear healthy. Fan-in makes that partial freshness harder to interpret than a single stopped feed.
Automatic detection is only the first requirement. The destination schema must be ready before data using the new schema arrives, and the transition must not interrupt unrelated streams. Where sources share a destination table, a destructive repair could also affect data supplied by another source. For DMS, halting or table recreation should be tested because the supplied documentation leaves these outcomes uncertain. The concrete buyer test is to add a column during active replication and observe propagation, destination preservation, and the progress of every other stream.
Failure recovery when one source stream falls behind in a fan-in pipeline
If an Oracle RMAN retention policy deletes archived logs before the CDC consumer reads them, the missing change window cannot be recovered from those deleted logs. The service must detect the gap and alert, resume from a consistent snapshot, or both. Postgres can instead retain unread WAL through a lagging replication slot. That protects the consumer's position but can fill the source disk and put the database at risk of going down.
Capture, buffering, delivery state, and destination progress need independent tracking so a stalled Oracle stream does not prevent healthy Postgres and MySQL streams from advancing. A shared task or process can couple these failure domains if one stalled source blocks destination offset commits. Teams therefore need to see the replication lag, error state, and log-position health of each stream in the dashboard. Buyers should establish whether restarting one failed stream leaves all other streams feeding the same destination uninterrupted.
Exactly-once delivery in fan-in — what the guarantee actually covers
At the destination, idempotent upserts can handle repeated deliveries so that retries do not have the same effect on a row more than once, even when upstream delivery is at least once. That does not by itself resolve ordering between independent sources that update overlapping destination rows. Buyers should ask whether the service's claim covers each source stream on its own or the shared destination table, including interleaved updates and deletes.
How do you evaluate managed CDC for fan-in before committing
Run Oracle, Postgres, and MySQL in parallel against the intended warehouse, execute hard deletes on each, and verify their destination effects. A missing delete fails the capture test. During the same run, add a source column and record whether propagation is automatic, whether other streams continue, and how long recovery takes. Any manual repair becomes an operational responsibility multiplied by the frequency of source changes.
Next, deliberately stall one stream by pausing its source or blocking the service's log access, then check that the others keep advancing destination offsets. Inspect recovery as well as the interruption. Before committing, establish which Oracle extraction method the vendor uses, whether LogMiner, XStream, or an external reader, and request its documented throughput limit. Ask how the service responds when RMAN deletes archived logs before consumption. Require a dashboard or API that shows per-stream lag, errors, and log-position health.
Commercial and security fit belong in the same evaluation. For regulated workloads, establish whether customer data enters the service's infrastructure or passes through it, and confirm applicable HIPAA, SOC 2, BAA, and data residency requirements. The vendor shortlist should follow the architecture. GoldenGate fits Oracle-first estates, Datastream fits supported GCP destination paths, DMS fits AWS-native migration-scoped work, Artie fits teams that need real-time heterogeneous replication with automatic schema propagation, and Integrate.io offers a managed heterogeneous option with fixed-fee pricing.
