Supabase Pipelines Public Alpha: A 6-Step Playbook for Offloading Analytics from Postgres

Supabase shipped Pipelines into public alpha on July 21, 2026, which makes this a good moment to stop hand-rolling warehouse sync jobs from app code. The product is aimed at one job: moving selected Postgres data into analytical destinations in near real time, with an initial sync first and change-data-capture after that.

This playbook is the practical version: how to stand up a first pipeline without turning your production database into an analytics sandbox. I'm using BigQuery as the example destination because it has the most concrete public docs today, including the new schema-change behavior.

1. Start with the right problem

If your goal is live UI updates, use Supabase Realtime. If your goal is durable analytics replication, use Pipelines. That distinction matters more than the setup steps. Supabase's own guidance is blunt here: Realtime is for browsers and apps that can tolerate gaps; Pipelines is for managed data movement that can resume from retained WAL.

That means Pipelines is the better fit when you want to:

run BI queries away from production
feed a warehouse or feature store
keep dashboards fresh without polling Postgres
avoid writing your own reconnect, retry, and backfill logic

If you were about to subscribe to postgres_changes and forward rows into an analytics system, stop here and switch tools.

2. Design the smallest publication that answers your analytics question

The lazy setup is the right one: publish fewer tables and fewer columns first. Pipelines can replicate a whole schema or all tables, but that is rarely the clean first move. Start with one business flow you actually need, like orders, subscriptions, or events.

A minimal publication looks like this:

sql

create publication analytics_pub
for table public.orders, public.order_items;

If you need tighter control, Supabase documents support for column lists and row filters through SQL-based publications. Use that to avoid leaking operational-only columns into your warehouse.

Two practical checks before you move on:

Make sure the source tables have primary keys. BigQuery pipelines require them.
Keep derived values in normal columns if you need them downstream. Generated columns are skipped.

3. Pick your destination with the alpha constraints in mind

Today's public docs make BigQuery the safest first destination because the setup and limitation pages are explicit. Also note the network detail that is easy to miss: managed Pipelines run in AWS `eu-central-1` (Frankfurt). Put your destination region as close to Frankfurt as you can, or you are volunteering for extra replication lag.

The pricing is usage-based, not magical: $0.053 per configured pipeline hour, $0.60/GB for initial sync, and $3.00/GB for ongoing replication on Pro and Team plans. That should influence your first cut of replicated tables more than enthusiasm does.

There is also a product boundary worth planning around: Pipelines maps names and types for the destination, but it does not run user-defined transformations. If you need heavy reshaping, keep that in your warehouse layer or in a separate downstream job.

4. Create the pipeline in the Dashboard, then watch the initial sync

After your publication exists, create the destination in the Supabase Dashboard and point it at that publication. Under the hood, Pipelines does two phases:

an initial sync of existing rows
ongoing CDC for inserts, updates, deletes, and truncates

This is where most teams overshoot. Don't start with every historical table in the product. Start with one slice, let the initial copy finish, then validate row counts and destination schemas. Public alpha is exactly when you want small blast radius.

If the dashboard does not show your publication, Supabase's docs call out the usual fix: create it with SQL, then refresh the dashboard view. If a pipeline fails to start, check the pipeline status error directly instead of changing database settings blindly.

5. Use the new schema-change support, but don't trust it beyond the documented set

The public alpha launch added one feature that makes Pipelines much more usable in real teams: automatic schema change support. For BigQuery, the documented supported set is still intentionally narrow:

add a scalar top-level column
remove a column
rename a column
drop a NOT NULL constraint
set or drop supported default metadata

That is enough for common product iteration, but not for every migration. A few important non-supports remain:

changing a column's data type
adding NOT NULL with SET NOT NULL
backfilling old rows through ADD COLUMN ... DEFAULT

So the safe pattern is simple: do additive, boring schema moves first; schedule risky type changes as explicit warehouse maintenance. Alpha means fewer surprises when you stay inside the paved road.

6. Plan for correctness, not just connectivity

Pipelines is at-least-once, not exactly-once. That is the right tradeoff for reliable CDC, but it means your destination side should tolerate repeated batches. BigQuery converges through primary-key-based CDC, which is why the primary-key requirement matters so much.

You should also expect a few operational limits from day one:

a stopped pipeline can leave WAL accumulating upstream
long pauses can invalidate the slot and force a new initial sync
updates and deletes may need REPLICA IDENTITY FULL on some tables

If you need that last one, the Postgres change is straightforward:

sql

alter table public.orders replica identity full;

Use it only where update correctness beats WAL volume, because it makes Postgres log more old-row data.

The real win here is not that Supabase gave you another toggle in the dashboard. The win is that as of July 2026, there is finally a managed path for warehouse replication that is better than wiring together WebSocket listeners, cron jobs, and apology-driven ops. Start small, validate the first sync, and treat schema support as helpful but still bounded. That is enough to get real analytical isolation without inventing a data platform on a Thursday.