Oracle LogMiner vs Postgres Logical Replication for CDC

Oracle LogMiner and Postgres logical replication take opposite paths to CDC, and that architecture determines what a production connector must do. Oracle requires reconstruction from redo logs, while Postgres exposes a decoded change stream. Managed services such as Artie can take on much of the day-to-day work, but weighing either approach still means knowing who handles transaction correctness, retention, and recovery.

Why Oracle and Postgres take structurally opposite paths to CDC

Oracle’s redo log serves durability and recovery. LogMiner provides an interface for reading those records, but it began as a diagnostic and recovery utility. A LogMiner connector therefore mines log files and reconstructs the context needed to turn redo records into usable changes. The distinction is between access to recovery records and delivery of complete transactions.

Postgres also starts with a durability log, the WAL used for crash recovery. However, logical decoding exposes that log through a dedicated consumer pathway built around a replication slot and an output plugin. The consumer receives decoded changes whose delivery reflects transaction commits rather than having to reconstruct transactions from archived records itself.

What Oracle's redo log actually requires before a connector sees a single change

That boundary first appears in Oracle’s setup requirements. Archive log mode and supplemental logging are set for the database as a whole, and DBAs have historically managed them apart from application access. Without archive log mode, Oracle overwrites redo log segments when they fill, leaving no retained history for LogMiner to read. Enabling it on an existing production database requires a maintenance window to restart the instance. The resulting archive is also an ongoing retention obligation.

Supplemental logging controls whether the records kept in the archive have enough information for CDC. Oracle’s default redo has what crash recovery needs, often just the changed columns and the rowid. Primary key supplemental logging is the minimum viable level because delete events otherwise lack a reliable row identifier. ALL COLUMNS supplemental logging writes the full before-image on every change so that UPDATE and DELETE events can be fully reconstructed. Its cost is additional redo volume proportional to row width times update rate.

The practical pattern is to enable minimal supplemental logging at the database level and ALL COLUMNS selectively on captured tables to bound that overhead. Skipping the required logging can produce silently incomplete UPDATE events rather than an immediate connector error, with discrepancies appearing later in the warehouse. Postgres also requires a server-level setting, wal_level = logical, and a restart, but it has no equivalent supplemental-logging write amplification. Managed CDC services, including Artie, abstract the configuration work, although those database prerequisites and their costs still matter.

How the SCN and the replication slot handle position-tracking differently

Oracle’s System Change Number, or SCN, is a global, monotonically increasing transaction clock that gives committed changes an order and consumers a resume point. However, a valid SCN does not guarantee that the archived log containing it still exists. The connector must save its position, while the operator must retain the corresponding files long enough for it to read them.

Postgres binds those responsibilities more closely through the replication slot. The slot records the consumer’s position as an LSN, and Postgres retains the WAL segments that consumer still needs. This protects a stopped consumer from losing its place, but it transfers the danger to the database’s disk. If consumption stops while writes continue, retained WAL can grow until disk exhaustion crashes the server. The max_slot_wal_keep_size setting provides a safety valve by invalidating a lagging slot instead of allowing unbounded growth.

Neither mechanism is safe merely because it can record a position. Oracle relies on retention policy remaining compatible with connector lag, while Postgres relies on consumers keeping pace or a retention limit interrupting replication. Artie manages retention policy, failure recovery, and position tracking as part of its infrastructure, taking those tasks off the operator’s hands.

Why long-running transactions and LOBs are uniquely dangerous on Oracle LogMiner

An Oracle checkpoint also has to preserve enough context to reconstruct a transaction correctly. The starting SCN supplied to START_LOGMNR determines which logical events LogMiner can reconstruct. It is not equivalent to filtering an already-decoded stream for records where SCN >= start_scn. If mining starts midway through a transaction, the missing earlier context can make it impossible to reconstruct valid DML events. Long-running transactions need special care because their context may stretch across more than one mining session.

Rollback handling shows the consequence. A rollback record cannot be interpreted correctly without the original DML operations it reverses. If a connector misses that opening DML, it may send intermediate state to the destination and then be unable to reverse it. The destination can consequently contain rows that appear committed even though the source transaction rolled back. This is a correctness failure that can occur without a connector error.

LOB handling and fragmented SQL impose related reconstruction duties. The connector must preserve BLOB locator context through the full LOB_WRITE sequence and reassemble CSF fragments before emitting events. These requirements arise from the mining interface shared by tools that use it. By contrast, Postgres logical decoding withholds changes until the transaction commits, even though records from unfinished transactions already exist in WAL. An Oracle connector must establish that same committed-result boundary itself by carrying transaction state across sessions and suppressing unfinished or rolled-back work.

The two principal production failure modes: missing archive logs versus unbounded WAL growth

Oracle’s dominant operational failure occurs when its RMAN retention policy deletes an archived log before the connector processes it. The connector then fails with a missing log sequence error, despite still knowing the SCN it needs. If a backup contains the missing archive, restoring it can allow replication to resume. Otherwise, recovery needs a full re-snapshot of the affected tables. The failure follows directly from a retention policy that does not know the connector’s position.

Postgres fails in the opposite way because the slot keeps unread WAL from being removed. When a consumer stops, that protection can keep accumulating files until the database runs out of disk. Setting max_slot_wal_keep_size puts replication continuity at risk to keep the source available. Instead of retaining unlimited WAL, Postgres invalidates the lagging slot, leaving the consumer unable to resume from it.

The operational choice is therefore not between a risky mechanism and a safe one. Oracle places the critical dependency in archive retention, while Postgres places it in consumer uptime and bounded WAL retention. Once Oracle’s missing archive cannot be restored, or a Postgres slot has been invalidated, both failure modes converge on re-snapshotting as the recovery path.

How schema changes break replication differently on each platform

Schema evolution needs more work because neither native mechanism keeps the destination’s schema in step with the source on its own. Postgres logical replication does not stream DDL. If the publisher sends data for a new column that the subscriber does not have, replication stops with an error until the subscriber schema is updated. Additive changes must therefore be applied to the subscriber first. The failure is visible, but it still interrupts delivery.

Oracle’s corresponding risk is dictionary drift. LogMiner needs a data dictionary that matches the redo being decoded, and major schema changes can break that correspondence when mining uses an extracted, offline dictionary separate from the live online catalog. The gap lies between the schema represented by the dictionary and the schema in effect when the redo was written. It can produce decode errors or silent misinterpretation of records. Unlike a missing Postgres destination column, dictionary drift may not announce itself as a hard replication stop.

A managed connector must therefore do more than recognize that a table changed. It must detect schema changes, propagate them in the right order, and distinguish additive changes from destructive ones. Column additions, type changes, and table renames all require handling beyond the native change-delivery mechanism. The connector or managed service layer must handle automatic schema evolution because neither database interface does all of that work on its own.

How Oracle's three CDC pathways differ in latency, overhead, and licensing cost

Oracle CDC is not a single implementation choice. The three broad pathways are LogMiner, direct redo log parsing, and XStream, with LogMiner itself offering Oracle-buffered and connector-buffered approaches. Those choices move parsing and transaction assembly between the database and the connector. They also create different tradeoffs in source impact, latency, compatibility, and licensing. Postgres presents a more uniform consumer pathway through logical decoding, a replication slot, and an output plugin such as pgoutput.

In Oracle-buffered LogMiner, Oracle parses redo entries and materializes them in V$LOGMNR_CONTENTS, which the connector queries. This approach is included with Oracle and is well documented, but its CPU work sits on Oracle’s SQL engine. Latency follows polling frequency and is typically in the seconds range. When transaction volumes are high, that work on the database can slow the source down. The approach is better suited to simple, low-volume setups than to workloads where source impact dominates the decision.

Connector-buffered LogMiner shifts transaction assembly into the connector’s memory and emits changes only after commit. It puts less pressure on Oracle’s SQL engine and needs no additional license. But the connector must now handle the complex work of transaction assembly and the long-transaction risks described earlier. Lower database-side pressure does not remove that work.

Direct redo parsing bypasses LogMiner and reads the binary redo stream from the primary or a standby. It offers high throughput and the lowest Oracle CPU overhead among the described approaches, with no additional license required. The price is compatibility work because the connector must follow Oracle’s internal redo format as versions change. XStream is a separate API pathway, but Oracle’s documentation says that using it requires buying an Oracle GoldenGate license. The supplied evidence gives no comparable XStream latency figure, so licensing alone is not enough to choose based on performance.

What a connector must handle on each platform to stay correct in production

For Oracle, production correctness begins with preserving transaction context across mining sessions. The connector must reassemble CSF-fragmented SQL, retain BLOB locator context through LOB_WRITE, and suppress rolled-back transactions to prevent publication of intermediate state. It must also detect supplemental logging gaps without silently emitting incomplete events. Beyond decoding, it must track archive retention against lag and alert before a gap becomes unrecoverable. Oracle 12c and later add multitenant CDB/PDB privileges and common-user requirements to that operational burden.

For Postgres, the connector’s main responsibilities move from reconstruction to continuity and destination correctness. It must monitor slot WAL retention and enforce a max_slot_wal_keep_size-equivalent policy to prevent disk exhaustion. It must propagate schema changes in the correct order and handle failover through failover slots on Postgres 17 and later, or reconnection and re-snapshot logic on earlier versions. The slot provides at-least-once delivery on the source side, so exactly-once results still depend on deduplication or idempotent application at the destination. A native decoded stream simplifies capture, but it does not complete the replication system.

The practical choice is therefore between implementing these safeguards in the connector layer and obtaining them as managed infrastructure. For teams choosing the managed route, Artie provides sub-minute latency, exactly-once delivery, automatic schema evolution, and failure recovery for Postgres and other supported sources, with destinations including Snowflake, BigQuery, Redshift, Databricks, and ClickHouse.