Skip to content

How to Query Recent CDC Tables in BigQuery

May 2026

In BigQuery, the right recent-data query usually starts on the final-state table and only uses tombstones when delete visibility matters.

Short Answer

To query recent CDC tables in BigQuery, read the final-state target table directly for current rows and filter by a real business timestamp such as updated_at, committed_at, or another source-derived time column. BigQuery MERGE application is atomic and consistent, so the target table is the correct starting point for recent-state queries.

If you need recent deletes, query the companion tombstone table alongside the main table. The _skippr_order_token column is for row ordering and replay safety, not for a human-friendly time window, so it should not be your first choice for "last 24 hours" style filters.

Why Teams Struggle with This

Teams often mix together three different questions: what is the current row, which rows changed recently, and which keys were deleted recently. BigQuery makes the first question easy because the MERGE result is the warehouse truth. The other two still need the right columns and tables.

  • Do not treat _skippr_order_token as if it were a wall-clock timestamp.
  • Do use the reconciled target table for current-state analytics.
  • Do inspect skippr_tombstones when delete recency matters.
  • Do keep the business timestamp that readers actually want to filter on.

How Skippr Handles It

Skippr helps because the BigQuery destination already gives you a stable final-state table plus a visible tombstone companion. That means the query pattern can stay simple: current rows from the target, delete events from tombstones, and time slicing from your actual domain timestamp.

A concrete example: for recent shipped orders, query the final-state orders table where status = shipped and updated_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY). If you also need orders deleted in that same period, check the companion tombstone table for the matching business keys.

  • BigQuery target tables are the primary read path for current-state queries.
  • Tombstone tables are the primary read path for recent delete visibility.
  • Order tokens protect mutation order but are not a substitute for business time.
  • Atomic MERGE behavior means you do not need to read a staging table for fresh correctness.

What the First Useful Version Looks Like

The useful BigQuery pattern is simple: ask the final-state table for current truth, ask the tombstone table about deletes, and use a real timestamp for recency.

That keeps recent CDC queries readable instead of turning them into ingestion archaeology.