Four layers, four jobs
Each layer owns exactly one job. Confusing the jobs is how teams end up with a warehouse full of numbers nobody will defend in a meeting.
| Layer | Owns | Does not own |
|---|---|---|
| Supabase Postgres | The record of what happened in the product | Analysis. It is a transactional database and you should not run funnels on it |
| Supabase Pipelines | Processing eligible changes at least once; consumers handle possible replays | Deciding whether the rows are correct |
| BigQuery | Modeling. Turning app tables into questions with answers | Knowing what your product meant by an active status |
| Your go-to-market tools | Acting on the answer | Any of the above |
Every guarantee is conditional
Read the layers left to right and something uncomfortable falls out. Pipelines processes eligible source changes; it does not establish truth. BigQuery models whatever arrives. Your CRM routes on whatever the model says.
A wrong source value can reach downstream consumers while infrastructure appears healthy. Nothing in the chain is designed to stop it, because stopping it is not any of these layers' job.
Which puts the real start of the stack one step before Postgres: the pull request that changes the schema.
The pull request changes the schema before replication begins. The database records what happened, Pipelines moves it, BigQuery models it, and your GTM tools act on the result.
Changed-code review and plan-versus-scan checks sit before Postgres. Runtime capture and downstream contracts still need their own validation.
Episode 8 is where that stops being a diagram and becomes a specific migration that breaks a specific query.