Filter rows during a Debezium ad-hoc incremental snapshot using a signal additional-condition
domain: data-engineering · 5 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Insert a signal row into the configured signaling table (columns must be exactly id, type, data) with type = execute-snapshot.
In the data JSON payload, set data-collections to the fully-qualified table(s) to snapshot, and optionally type: incremental (the default) or blocking.
Add an additional-conditions array to scope the snapshot, with each entry specifying data-collection (which table the filter applies to) and filter (a SQL-like predicate, e.g. "color=blue AND quantity>10").
Submit the same signal via a Kafka signal topic instead of the signaling table if your deployment uses topic-based signaling.
Verify the resulting snapshot only emits events for matching rows by checking downstream topic contents, since a mis-scoped filter can silently under- or over-select rows without an explicit error.
Known gotchas
additional-conditions is an array keyed per data-collection — a single flat filter string without the data-collection wrapper won't apply when snapshotting multiple tables in one signal.
Ad-hoc filtered incremental snapshots don't retroactively affect rows already streamed via regular CDC — they only control which rows get (re-)snapshotted, not ongoing change capture.
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?