How does ScyllaDB implement Change Data Capture internally?

When CDC is enabled on a table, ScyllaDB automatically creates a companion log table alongside it, and every insert, update, or delete on the base table also writes a corresponding row into that log table describing the change, as part of the same write path.

The CDC log table is a regular ScyllaDB table under the hood, partitioned by time-based "streams" so that reading recent changes is an efficient, sequential operation rather than a full scan, and it carries its own TTL so change history doesn't grow unbounded. Consumers, whether custom CQL clients or the official Kafka Source Connector, read from this log table incrementally, tracking their own progress per stream so they can resume where they left off after a restart. Because the log write happens as part of the same mutation as the base table write, CDC records are captured with the same durability and ordering guarantees as the underlying data, avoiding the missed-event problems that separate, out-of-band change-tracking mechanisms can suffer from.