In a Debezium MySQL connector, how does snapshot.mode=never differ from schema_only?

## The shared behaviour: no rows Start with what the two modes have in common, because it is the source of most incidents. Neither mode produces a single `r` (read) event. A consumer that builds a table by replaying the topic from the beginning will therefore hold only the rows that changed *after* the connector started. Every row that existed and was never touched again is invisible to that consumer forever. If your destination needs a complete table, one of these modes is only ever half the plan — the other half is a backfill, usually an ad-hoc incremental snapshot afterwards. ## Why MySQL needs a schema at all MySQL's row-based binlog records changed rows as ordered lists of column values, together with a table map event carrying types but not the full DDL semantics the connector needs to build a proper event schema. Debezium therefore maintains its own **database schema history**: a record of the DDL applied to the captured tables, kept in a dedicated Kafka topic (or a file, for Debezium Server and the embedded engine). Every binlog event is decoded against the schema as of that point in the log, which is what lets the connector emit correct events for a table whose columns changed six months ago. The same requirement applies to the other connectors that read a log carrying no schema information — SQL Server, Oracle, Db2. The Postgres connector is the notable exception: it reads the current table definitions from the database catalog when it connects, so it has no schema history topic and the `schema_only` distinction does not arise there in the same way. ## schema_only (no_data) With `schema_only`, the connector connects, reads the current structure of every captured table, writes that into the schema history, records the current binlog position, and starts streaming from there. Cost: one cheap metadata pass. Benefit: a connector that is immediately correct and starts producing within seconds of deployment even against a multi-terabyte database. This is the mode behind the standard "stream now, backfill later" pattern: bring the connector up with `no_data` so the log is being consumed from the outset, then issue ad-hoc incremental snapshots table by table to fill in history at a pace you control. ## never `never` instructs the connector to take no snapshot of any kind — not the rows, not the schema. Having no recorded schema, the connector has to derive one from DDL statements found in the log. That is only sound when the binlog retained on the server reaches back to the creation of the tables you capture. Because binlog retention is finite on every real server, that condition is rarely true, which is why `never` is documented as a mode to configure with care rather than a routine choice. The exact starting position and failure behaviour for this mode have been tightened across Debezium releases, so verify against the docs for the version you run rather than assuming. ## The recovery mode people confuse with these A third, closely named mode exists for a different failure: `schema_only_recovery` (renamed `recovery`). Use it when the schema history topic has been lost or corrupted but the connector's *offsets* are intact. It re-reads the current table structures into a fresh history and then continues streaming from the stored offset. Reaching for `schema_only`/`no_data` in that situation is a classic mistake: it would restart from the current end of the binlog and silently drop every change that occurred while the connector was down. ## Picking between them Use `initial` when you want a complete copy. Use `schema_only`/`no_data` when you knowingly want changes from now on — a new analytics feed where history will be loaded separately, a second connector added beside an existing one, or a giant source where the snapshot is impractical and incremental snapshots will do the backfill. Reserve `never` for the rare case where you truly must not run even a metadata pass and you have reasoned about where the connector will begin in the log. And whichever you pick, write down how the pre-existing rows will get to the destination, because none of these modes will do it for you. ## Operational note Because `schema_only` and `never` skip the long data-reading phase, they also skip the operational risk that goes with it: the connector begins consuming the log immediately, so the source stops accumulating unread log segments on the connector's behalf almost at once. On a big database that is often the deciding argument, independent of any preference about backfills.