Change tracking (CDC / change tracking)

Oracle

-- Read changes from redo logs with LogMiner:
-- 1) Add the archived/redo log file to analyze:
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(
  LOGFILENAME => '/u01/arch/1_1234_1122334455.arc',
  OPTIONS => DBMS_LOGMNR.NEW);
-- 2) Start the session:
EXECUTE DBMS_LOGMNR.START_LOGMNR(
  OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
SELECT sql_redo, sql_undo FROM V$LOGMNR_CONTENTS
WHERE seg_name = 'ORDERS';
-- 3) When finished: EXECUTE DBMS_LOGMNR.END_LOGMNR;
-- For enterprise CDC/replication, Oracle GoldenGate is used.

Oracle does change tracking based on the redo log. LogMiner translates redo/archived logs into SQL to inspect past DML; the log files to analyze are added with DBMS_LOGMNR.ADD_LOGFILE. For meaningful results, at least minimal supplemental logging must be enabled (ALTER DATABASE ADD SUPPLEMENTAL LOG DATA). For continuous, low-latency CDC and heterogeneous replication, Oracle GoldenGate (a separate product) is the standard; the old Streams/Change Data Capture features are deprecated.

PostgreSQL

-- Create a logical replication (logical decoding) slot:
SELECT * FROM pg_create_logical_replication_slot(
  'cdc_slot', 'wal2json');
-- Consume changes as JSON:
SELECT data FROM pg_logical_slot_get_changes('cdc_slot', NULL, NULL);

PostgreSQL logical decoding turns WAL records into a readable change stream through an output plugin (wal2json, pgoutput, test_decoding); the replication slot ensures changes are not lost. wal_level must be logical. Debezium uses this mechanism to provide enterprise CDC.

MySQL

-- The row-based binlog is the CDC source (binlog_format=ROW):
SHOW BINARY LOGS;
SHOW BINLOG EVENTS IN 'binlog.000042';
-- Usually Debezium/Maxwell reads the binlog and turns it into a stream.

In MySQL the CDC source is the binary log. With binlog_format=ROW every row change is recorded. Tools such as Debezium or Maxwell read the binlog like a replica and produce an event stream into Kafka. Enabling GTID makes reliable position tracking easier.

SQL Server

-- Enable Change Data Capture on the database and the table:
EXEC sys.sp_cdc_enable_db;
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo', @source_name = N'orders',
  @role_name = NULL;
-- For lightweight tracking: ALTER DATABASE ... SET CHANGE_TRACKING = ON;

SQL Server offers two mechanisms: Change Data Capture (CDC) writes all DML (with old/new values) from the transaction log into change tables and requires SQL Server Agent. Change Tracking only lightly tracks which rows changed (net changes) and keeps no full data history.

MongoDB

// Watch changes in real time with Change Streams:
const stream = db.orders.watch([
  { $match: { operationType: { $in: ["insert", "update"] } } }
]);
while (stream.hasNext()) { printjson(stream.next()); }

MongoDB Change Streams, built on the oplog, deliver insert, update and delete events at the collection/database/cluster level as a real-time stream. Requires a replica set or sharded cluster. With a resumeToken, a stream can resume where it left off after an interruption; it is the foundation of CDC integrations.

Redis

# Listen for key changes with keyspace notifications:
CONFIG SET notify-keyspace-events KEA
# Subscribe to changed keys via Pub/Sub:
PSUBSCRIBE __keyevent@0__:set
PSUBSCRIBE __keyevent@0__:expired

Redis keyspace notifications publish events on keys (SET, DEL, EXPIRE, etc.) through Pub/Sub channels; they are enabled with the notify-keyspace-events setting (K=keyspace, E=keyevent, A=all events). For a reliable, durable change stream, Redis Streams (XADD/XREAD) are preferred.

Elasticsearch

-- Not applicable: there is no built-in CDC/change stream.
# Closest equivalent: incremental query on a timestamp field:
GET orders/_search
{ "query": { "range": { "updated_ts": { "gt": "2026-07-05T00:00:00" } } },
  "sort": [ { "updated_ts": "asc" } ] }

Elasticsearch offers no change data capture (CDC) stream; it does not natively publish when a document changed. The common approach is to add an updated_ts field to every document and run incremental queries by timestamp (range + sort). Usually the source database's CDC is fed into Elasticsearch.

Open in DBAtlas →