Demo Dive Series
Join Coalesce and Artie to see how to get SQL Server data into Coalesce, without taxing your production database.
Every standard way of doing CDC on SQL Server leans on the production database.
Every standard way of doing CDC on SQL Server leans on the production database. Change Tracking means querying the source for every changed row. Native CDC copies every change into shadow tables that sit on the same instance and grow with your write volume. This is acceptable at low volumes. But at scale, or when a DBA is protective of production, this is where SQL Server pipelines stall out and the data never makes it to the warehouse. There’s also a third, less discussed option: reading changes straight from the transaction-log backups SQL Server already writes, so you stop reading from the live database entirely.
This session walks through how all three actually work, what each one costs the source database, and how to tell which one your situation calls for. We’ll also cover ways to lighten the load no matter which method you pick: running CDC without a Kafka buffer to deploy and feed, and backfilling from a replica so the initial snapshot never touches your primary.
Then we’ll put the pipeline to work live: Artie Terra with real operational data behind it, from ticket bookings to visitor feedback. Flows from SQL Server into Snowflake, where Artie’s metadata columns feed the Coalesce models that turn the change stream into answers, refreshed the moment new data lands.
What You’ll Learn
- How Change Tracking, native CDC, and transaction-log backups each hit the source database differently, and when the backup-file approach is the right call
- How to backfill from a replica and skip the Kafka layer entirely, whichever capture method you choose
- How Artie’s system columns (operation type, transaction timestamps, source table) drive incremental models in Coalesce
- How to trigger Coalesce runs when data lands, so transformations follow events instead of a schedule
Save Your Seat
Instructors
