Skippr Docs

Appearance

When to Choose BigQuery for CDC Final State ​

May 2026

Choose BigQuery for CDC final state when you want atomic MERGE behavior, low infrastructure overhead, and a clear dataset-based warehouse contract.

Short Answer ​

Choose BigQuery for CDC final state when your team wants atomic and consistent MERGE behavior, a warehouse that is fully managed, and a destination where the final-state table can be queried immediately after warehouse-side reconciliation. It is especially strong when analysts and engineers want the warehouse contract to stay simple: newer rows win, deletes are protected by tombstones, and the main table is the thing everyone reads.

BigQuery also fits teams that prefer service-account auth and dataset-oriented administration over owning cluster operations. If the useful shape is "one project, one dataset, one current row per business key," BigQuery makes that model easy to explain and easy to operate.

Why Teams Struggle with This ​

The key trade-off is that destination choice should follow CDC semantics, not only existing vendor preference. BigQuery is compelling when the team wants strong final-state behavior with low infrastructure ceremony. It is less compelling if the main requirement is local-first operation, very specialized performance tuning, or a destination that behaves like an OLTP database.

  • BigQuery is strong when atomic MERGE semantics are the main warehouse requirement.
  • It is strong when dataset-level administration and service-account auth are a better fit than warehouse clusters and staging infrastructure.
  • It is less about hand-tuned engine behavior and more about predictable warehouse operations.
  • The team still needs clean business keys and source timestamps for good CDC usage.

How Skippr Handles It ​

Skippr makes the BigQuery fit clearer because the destination contract is explicit in the docs: MERGE DML, STRING order tokens, automatic tombstone tables, and exactly-once final-state semantics. That means you can choose BigQuery based on concrete behavior instead of generic cloud familiarity.

A concrete example is a SaaS team that needs current account, subscription, and invoice tables available to dbt without first writing deduplication repair models. BigQuery is a good fit because the warehouse can own the final-state reconciliation directly through MERGE and tombstone-aware deletes.

  • Choose it when you want warehouse-level final-state reconciliation without managing cluster infrastructure.
  • Choose it when atomic and consistent MERGE behavior matters more than custom engine tuning.
  • Choose it when service-account auth and dataset permissions fit the team well.
  • Do not choose it only because it is familiar if your actual CDC query pattern needs a different shape.

What the First Useful Version Looks Like ​

BigQuery is not the universal best CDC destination. It is the right one when its operating model and merge semantics match how your team wants to own final-state tables.

That is the useful selection rule.