Supabase Pipelines is faithful. Your tracking has to be too.

As reviewed on 16 September 2026, Supabase Pipelines is in public alpha. BigQuery is managed; ClickHouse, DuckLake and Snowflake are Early Access. Eligible Pro, Team and Enterprise projects can request access, but eligibility does not guarantee access. Processing is at least once, so replays are possible. BigQuery supports constrained column add, drop and rename behavior in beta; data-type changes are unsupported.

That faithfulness is the whole point. It is also the risk nobody is talking about yet.

Faithful replication is only as good as the source it is faithful to.

Pipelines treats eligible Postgres changes as its source. Its hard problem is surviving infrastructure failure, not deciding whether the source data is correct. So when your tracking breaks in a pull request, Pipelines does not stop it. It carries the break all the way to the warehouse, schema change and all, and every hop stays green while it does.

Here is what that looks like. Flip the toggle.

Key takeaways

• Supabase Pipelines uses at-least-once processing, so consumers must handle possible replays. Its documented job does not decide whether source events are correct or complete.
• Changing an event-name field value is a data-contract change, not a DDL column rename. BigQuery column add, drop and rename support is beta and constrained; downstream query effects must be tested.
• The most dangerous breaks look healthy. Volume is fine, the pipeline dashboard is green, and a funnel quietly goes flat or loses a dimension from the merge date.
• Skene GitHub review can inspect tracking changed or removed in a pull request. A separate deterministic plan-versus-scan check can report planned events absent from scanned code; neither path proves complete capture.
• The tools cover different evidence boundaries. Replication health, changed-code review, plan-versus-scan results and downstream validation remain separate checks.

Replication and tracking review have different boundaries

Pipelines operates after eligible writes reach Postgres. Skene can review a pull-request diff for changed tracking and run deterministic plan-versus-scan checks through supported API or MCP paths. Those checks can name observed gaps; they do not guarantee that every intended event is captured.

  code (PR)   ->   Postgres (events)   ->   Pipelines (CDC + schema)   ->   BigQuery   ->   dashboards
     ^                                              ^                                          ^
  Skene reviews changed tracking          Pipelines processes eligible changes          downstream models consume results
  (PR diff or plan-vs-scan check)          (at least once; replays possible)              (validate contracts separately)

Faithful replication makes the first arrow matter more, not less. If the event is wrong when it enters Postgres, replication can carry that bad input downstream; its timing and downstream effects still need observation.

Four ways a green pull request poisons your warehouse

The setup is the same for all four. A product-led SaaS on Supabase turns on Pipelines to replicate its events table into BigQuery, so the growth team can run funnels off the warehouse without loading production. Initial sync ran. CDC is live. Everyone has stopped double-checking.

Now watch four ordinary pull requests.

1. The rename Pipelines carries downstream

A coding agent tidies the checkout module and renames the event.

// checkout.ts
- track("checkout_completed", { plan, amount })
+ track("purchase_completed", { plan, amount })

Green build. Merged. Postgres stops receiving checkout_completed. Pipelines replicates the new rows faithfully, so BigQuery now has purchase_completed and zero new checkout_completed. The activation funnel filters on the old name. It does not error. It goes flat from the merge date, and the pipeline health dashboard stays green.

A DDL change such as alter table events rename column plan_tier to tier differs from changing the event_name string stored in a row. Supabase documents BigQuery column rename support in beta with constraints; test the specific schema change and dependent queries rather than assuming universal propagation.

Skene GitHub review can flag tracking removed by the PR and name the changed location. /skene fix is limited to restoring tracking removed by that PR; it does not propagate a rename throughout every downstream system.

2. The dropped field that goes null all the way

A cleanup drops a property that "nobody uses."

// signup.ts
- track("signup", { source, plan })
+ track("signup", { source })

Volume looks perfect, so nothing trips. But plan is null from the merge date, and Pipelines carries the nulls across without complaint. "Signups by plan" quietly loses its dimension. The person who reads that chart is not in the pull request.

Skene GitHub review can flag that the PR removed the plan property. It does not establish which downstream breakdowns depend on that field.

3. The event that never existed, so there is nothing to replicate

An agent ships a new share-to-Slack flow. It works. There is no tracking.

// share.ts
  await postToSlack(channel, summary)
+ // TODO: analytics (never written)

Pipelines does nothing here, correctly. There is no event to move, so BigQuery has no such rows and never will. A month later the question "how many shares, and do sharers retain better?" has no answer and cannot be backfilled. This is the gap Pipelines structurally cannot see. It moves what exists. It cannot tell you what should exist and does not.

A deterministic plan-versus-scan check can report a planned event absent from scanned code when the saved plan names it. GitHub changed-code review alone does not infer every new user-meaningful action or guarantee the required property set.

4. The firing condition that quietly narrows

A refactor moves a capture inside a branch.

// feature.ts
- track("feature_used", { feature })
+ if (user.plan !== "free") {
+   track("feature_used", { feature })
+ }

The event still exists in BigQuery, so nothing looks broken at all. But it is now missing every free-tier user. Free-tier engagement and retention silently skew upward, because the users who churn are the ones no longer counted. The most dangerous break, because the number only moves a little.

Skene GitHub review can inspect the changed tracking call and surrounding diff. This example illustrates a narrowed firing condition; it is not a promise that every branch-coverage change is detected automatically.

The same discipline, one layer up

The team did not make Pipelines correct by hoping. They encoded invariants in the type system, added assertions such as a debug check that replication progress never moves backward, and wrote fault-injection tests that fail after a destination write but before acknowledgement. That is correctness discipline for the pipe.

A saved measurement plan can state expected events and properties. Deterministic API or MCP checks compare that plan with scanned code, while GitHub review examines tracking changed by a pull request. Neither path verifies every runtime path, every downstream consumer or every intended event.

Why this matters now

Two waves are arriving together. Teams are turning on Pipelines and starting to trust the warehouse. The same teams are shipping with coding agents that rewrite the code that writes the events, with no model of why an event exists. Replication can expose a source-contract change to downstream consumers. Validate the relevant event field or DDL change, destination behavior and dependent models rather than assuming universal propagation or timing.

Skene can use repository evidence and a read-only Supabase schema connection in their documented paths. GitHub review comments on relevant changed tracking; deterministic plan-versus-scan checks are separate. Runtime capture and downstream effects still require observation.

Run uvx skene analyse-journey . to see the customer journey your repo actually describes. Then choose the documented review or deterministic check path, validate runtime capture, and evaluate Pipelines against its current alpha constraints.