Skippr Docs

Appearance

When BigQuery Is the Right Final-State Destination ​

July 2026

BigQuery is the right final-state destination when the team wants fully managed warehouse operations and current-row CDC tables that stay trustworthy through atomic MERGE behavior.

Short Answer ​

BigQuery is the right final-state destination when the team wants a fully managed warehouse with a simple project-and-dataset boundary and a documented CDC model based on atomic MERGE DML. The destination docs call out project, dataset, and optional location, while the CDC docs explain that Skippr adds _skippr_order_token plus tombstone tables so older replays do not overwrite newer rows or resurrect deleted keys.

That makes BigQuery a strong fit when the desired warehouse interface is one current row per business key and the team prefers service-account-driven operations over owning staging infrastructure or cluster behavior. A GCP-first team landing operational tables into raw_data can get current-state tables directly in the warehouse without inventing its own replay and delete policy in downstream SQL.

Why Teams Struggle with This ​

BigQuery is a weak fit when the organization cannot satisfy the dataset and job permissions the load path actually needs. It is also less appealing when the main objective is an append-only mutation archive rather than final-state tables that stay reconciled inside the warehouse.

  • The service account needs dataset creation, table write, and job creation permissions before the first load will feel smooth.
  • Dataset location matters early, because a wrong regional assumption becomes expensive to unwind later.
  • BigQuery is designed around querying reconciled tables, not around exposing every intermediate mutation as the main read surface.
  • If the team cannot use GOOGLE_APPLICATION_CREDENTIALS with a service account JSON key, setup friction appears immediately.

How Skippr Handles It ​

Skippr matches BigQuery well because the warehouse surface is narrow and the CDC contract is explicit. The connector expects a project and dataset, and the CDC destination docs explain exactly how MERGE, order-token comparison, and tombstones produce exactly-once final state.

That clarity matters in production. Analysts can read the target table as the current truth, while operators know the anti-stale-write logic lives in the warehouse itself rather than in a repair model added later.

  • Simple project, dataset, and optional location configuration.
  • Authentication through a GCP service account key referenced by GOOGLE_APPLICATION_CREDENTIALS.
  • Atomic and consistent MERGE-based final-state CDC reconciliation.
  • Automatic _skippr_order_token columns and tombstone tables for anti-resurrection safety.

What the First Useful Version Looks Like ​

The first useful version is one dataset, one service account with BigQuery Data Editor and BigQuery Job User, and one CDC-managed table that downstream SQL users can trust as current state.

If the team really wants a lighter local evaluation surface or does not control the necessary GCP IAM and dataset setup, another destination may fit better.