CDC without the drama

Change data capture has a reputation for being fragile and frightening — triggers everywhere, replication that falls over at three in the morning, a schema you are afraid to touch. It does not have to be that way. At its core, CDC is just the opposite of brute force: instead of copying an entire table every night, you read only what actually changed. The complexity comes from the fact that every database keeps that record differently.

On SQL Server, BARRY uses Change Tracking. The database already knows which rows changed since a given version, so BARRY reads that lightweight bookkeeping and fetches just those rows — no triggers, no shadow tables — and it works the same on SQL Server 2016 and later, Azure SQL Database, Managed Instance and RDS.

On PostgreSQL the source of truth is the write-ahead log. BARRY connects through a logical replication slot and reads inserts, updates and deletes straight from the WAL, including on the managed Postgres services. On MySQL and MariaDB it is the binary log: BARRY tails the binlog using GTIDs or file positions, so a table stays current without ever being rescanned.

Three databases, three mechanisms — and behind all of them, BARRY presents a single idea. A transport just says keep this table current, and the runtime picks the right approach underneath. Where true log-based capture is not available — Oracle through the managed driver, for instance — it falls back to watermark-based incremental loads, reading only rows past a high-water mark.

Every one of these routes is read-only and low-impact: no triggers on your tables, no changes to your source schema, and no long-held locks on production. The drama in CDC almost always comes from wiring it by hand. Let the runtime own the plumbing and it turns back into what it was supposed to be — a quiet, efficient way to keep data fresh.

← All posts