In Debezium, what does snapshot.select.statement.overrides change about a table's snapshot?

## What it is During the snapshot phase, Debezium reads each captured table with a straightforward SELECT over the whole table. `snapshot.select.statement.overrides` lets you substitute your own query for specific tables. The configuration comes in two parts: the property itself lists the fully-qualified tables you want to override, and one further property per table — suffixed with that table's qualified name — carries the SELECT statement. Qualification follows the connector's convention, so the suffix is schema-and-table on Postgres and database-and-table on MySQL. ## Why you would use it Three situations account for nearly all real use. **Volume**: a table holds ten years of history but the destination only needs the last two, and copying the rest would add hours to a snapshot during which the source retains log segments. **Cost**: a table carries a large payload column that the destination does not consume, so selecting the needed columns keeps the copy small. **Hygiene**: rows flagged as soft-deleted or belonging to decommissioned tenants should never reach the destination in the first place. There is a natural companion setting: `snapshot.include.collection.list` restricts which tables are snapshotted at all. Use that when the unit of exclusion is a whole table, and the statement overrides when the unit is rows or columns within one. ## The consequence people miss The override applies to the snapshot query and nothing else. The streaming phase reads the log and emits every change to every captured row, with no awareness of the predicate you wrote. So a row excluded from the snapshot is invisible at the destination until someone updates it — at which point an `u` event arrives for a key the destination has never seen. Whether that is harmless or damaging depends entirely on the sink. A sink that applies events as key-addressed upserts simply inserts the row and carries on; the destination gains a row that arguably should not be there, but nothing breaks. A sink that translates change events into literal UPDATE statements, or that maintains counts and expects every key to have been introduced by a prior read event, produces errors or wrong aggregates. Decide which you have before you write the predicate. The mirror-image mistake is the assumption that filtering the snapshot also filters the stream — that a `WHERE tenant_id = 7` override yields a single-tenant feed. It does not. To restrict what is captured at all, you need capture-set configuration (table and column include/exclude lists) or transformation and filtering downstream. ## Writing the statement safely A few practical rules. Return the columns the connector expects: if the captured column set is not restricted elsewhere, omitting a column from the SELECT can produce events whose schema does not match what streaming will later emit for the same table, and inconsistent event shapes are painful downstream. Make the predicate stable — a filter on `created_at >= now() - interval '1 year'` evaluates at snapshot time and is fine, but reasoning about which rows it admitted becomes hard later; a literal boundary date documents itself. Include an `ORDER BY` on the key when the connector's snapshot behaviour benefits from deterministic ordering. And keep the statement cheap enough to run against production — an override with an unindexed predicate can be slower than the full-table read it replaced, which defeats the purpose entirely. ## Where it fits among the alternatives If the goal is a shorter snapshot, weigh the override against simply not snapshotting the data at all: start the connector in a mode that skips rows and backfill with ad-hoc incremental snapshots, whose signal payload also accepts a filter condition. That path gives per-table control at request time rather than at deploy time, is resumable, and can be paused — advantages the static override does not have. The override remains the better tool when the filter is a permanent property of the pipeline (this destination never wants archived rows) rather than a one-off backfill decision. ## Interview framing This is a differentiator question rather than a screening one. The answer that lands is not the syntax; it is the boundary. Say what the override changes, say plainly that streaming ignores it, and name the concrete downstream consequence — an update for a row the destination never received an insert for — along with which kind of sink survives that and which does not.