What actually lands
Pipelines does not hand BigQuery a change log. For each published table it keeps a current-state table, applying inserts, updates, deletes and truncates as they arrive. There is no history of row versions to query afterwards, and a truncate or a table restart replaces what is there.
So the replicated tables are faithful copies of your app tables. They are faithful to the app’s shape, and not to any question your go-to-market team will ask. If you need to know what a row looked like last month, that is a model you build and schedule yourself, because the replica will not remember it.
Every table arrives as a view
Pipelines generates one view per source table, and the view is what you query. Its name joins the schema and the table with an underscore, so public.checks arrives as public_checks. An underscore already in the schema name is doubled: my_schema.checks becomes my__schema_checks.
Behind each view, Pipelines manages versioned physical tables. After a source truncate, the view points at a new version, and the old one can be removed.
Query the view, never the version
The rule that falls out of this is short. Point a scheduled query, a model or a dashboard at a physical version and it works right up until someone truncates the source. From then on it reads a copy nothing writes to, and once that version is removed it fails outright.
The view is the stable name. The version is an implementation detail that will move under you.
From faithful copies to models
From there, modeling is ordinary warehouse work. The replicated views are your raw layer, and you leave them alone. On top of them you build a thin analytical layer, in a dataset you own rather than the one Pipelines manages, with one model per question your go-to-market team actually asks.
Here is the smallest useful one, built on the workspaces columns episode 3 published: new workspaces per week, by plan. replica stands for the dataset Pipelines writes to and analytics for one you created.
create or replace view analytics.weekly_new_workspaces as
select
date_trunc(date(created_at), week(monday)) as week_start,
plan,
count(*) as new_workspaces
from replica.public_workspaces
group by week_start, plan;Every choice in that query is business logic. Weeks start on Monday, so a Sunday signup counts toward the week before. A workspace counts once, in the week it was created. Those are decisions somebody made, and a model is where a decision gets written down and reviewed. A saved query in someone’s BigQuery tab is where it gets forgotten.
Plan is today’s plan. Because the replica holds current state only, plan here is each workspace’s plan now, not the plan it signed up on. If the second one matters, snapshot it on a schedule before you need it.Episode 5 builds the first model with real stakes on it: activation, measured as one interval with two ends.