Supabase Bundled Change Data Capture Into Every Paid Plan. Right Now It Only Speaks BigQuery.

Every backend-as-a-service vendor eventually hits the same wall: your transactional database is not where your analytics live, and getting data from one to the other is somebody's weekend project. Supabase just shipped its answer — a managed change data capture (CDC) service called Pipelines, built directly into the platform, that streams your Postgres changes into a data warehouse without you standing up Debezium, wiring a Kafka Connect cluster, or paying a third-party ELT vendor by the gigabyte.

The pitch, straight from Supabase's own announcement, is disarmingly simple: "Your app runs on Postgres, but your analytics usually live somewhere else, like BigQuery. Pipelines keeps that data in sync for you in near real time, with no pipeline to build or maintain."

That's the headline. The interesting part is what's underneath it — and what isn't there yet. Pipelines shipped in public alpha, it is bundled into every paid plan with no visible separate line item, and right now it talks to exactly one destination: Google BigQuery. ClickHouse, Snowflake, and DuckLake are listed as "request early access" — which is marketing language for a waitlist, not a shipping feature.

That gap between the framing ("pipelines to your warehouse") and the reality ("a pipeline to BigQuery, with more promised") is exactly the angle worth digging into, because it tells you a lot about where this product actually sits on the maturity curve, and whether it's something you should build on this week or bookmark for later.

What Pipelines actually does

Strip away the marketing copy and Pipelines is a managed wrapper around Postgres's own logical replication mechanism. You define a publication on your Supabase Postgres database — the standard Postgres primitive that says "these tables, these operations, please" — and Pipelines takes over from there: it decodes the write-ahead log (WAL), transforms the row-level changes, and lands them in BigQuery in near real time.

Concretely, it captures:

• INSERT
• UPDATE
• DELETE
• TRUNCATE

for any table included in the publication you point it at. According to the Pipelines FAQ, you configure and monitor the whole thing from the Supabase dashboard — pipeline status, replication lag, per-table state, and errors are all visible without SSHing into anything or grepping a Kafka Connect log.

That last part matters more than it sounds. Anyone who has run Debezium in production knows the operational tax isn't setting it up once — it's the 2am page when a connector falls behind, a schema change breaks decoding, or a replication slot quietly fills up disk on the primary because nothing downstream is consuming it fast enough. Supabase is explicitly selling relief from that tax, not just the initial wiring.

The architecture, and why it has the same failure modes as everything else built on logical replication

This is not a novel replication engine. It's Postgres's native logical decoding, operated for you. That's a deliberate and reasonable choice — it's the same mechanism Fivetran, Airbyte, Estuary, and ClickHouse's own ClickPipes all lean on for Postgres CDC. But it means Pipelines inherits logical replication's well-known constraints:

• A replication slot holds WAL until it's consumed. If a pipeline stalls — because the destination is unreachable, or lag builds under load — the primary database's disk usage grows until someone notices. This is the single most common way to accidentally take down a production Postgres instance via CDC, and it's a property of Postgres, not of Supabase's implementation. Nothing in the public documentation suggests Pipelines has solved this differently than anyone else; it just gives you a dashboard to see the lag building before it becomes an outage.
• Tables without a primary key, or without REPLICA IDENTITY FULL set, don't decode UPDATE/DELETE payloads correctly. This is a standard Postgres logical-replication gotcha that trips up first-time CDC users regardless of vendor, and it's worth checking your schema against before you flip this on for anything beyond an append-only events table.
• "Near real time" is not "real time." Estuary, one of Pipelines' indirect competitors, markets itself specifically on sub-second, exactly-once streaming as a differentiator against exactly this kind of batched-microbatch CDC. Supabase hasn't published concrete lag SLAs for Pipelines, and given the alpha label, it likely can't yet.

None of this is a knock on the engineering — it's the same tradeoff every managed CDC product makes. The point is that "managed" removes the operational burden, not the architectural constraints of the underlying mechanism. You still need to understand what a replication slot is before you turn this on.

What setting one up actually looks like

Based on the documented workflow, adopting Pipelines is a three-step motion rather than a infrastructure project:

1. Define a publication on the tables you want captured — the standard CREATE PUBLICATION semantics, scoped to specific tables and operations, executed for you through the dashboard rather than a psql session.
2. Point it at a destination. Today that means authorizing a BigQuery project and dataset, which under the hood means creating a service account with write access and handing Supabase the credentials to stream into it — the same trust boundary you'd cross with any third-party ETL tool, except the vendor doing the writing is the same one already hosting your primary database.
3. Watch the dashboard. Lag, per-table sync state, and pipeline errors surface in the same UI you use for the rest of the project, rather than in a separate observability tool bolted onto a Kafka Connect deployment.

Compare that to a self-managed Debezium setup: provision a Kafka cluster (or use Debezium Server/Redpanda as a lighter alternative), configure a connector per source table, write or adopt a BigQuery sink connector, and then own the uptime of all three moving pieces indefinitely. Pipelines compresses that into dashboard clicks. The tradeoff is that you're trusting a single vendor's alpha-stage implementation with a job that used to be split across battle-tested, independently-operated components.

What actually changed for developers

Before Pipelines, a Supabase user who wanted their Postgres data in BigQuery had three realistic options: hand-roll logical replication and a consumer themselves, run a general-purpose ELT tool like Fivetran or Airbyte against their database as a source, or use a CDC-native platform like Estuary or ClickPipes. All three work. All three also mean paying and operating a second vendor, with its own auth model, its own billing, and its own place to check when something breaks.

Pipelines collapses that into the same dashboard you already use for your database, auth, and storage. That's the real product here — not the replication engine, but the fact that Supabase now owns both ends of the pipe. You provision the source and the sync from the same control plane, under the same account, and — during the alpha, at least — without an extra bill.

That's a meaningfully different value proposition than "another ETL tool," and it fits a pattern Supabase has been building toward all year. In the same recent stretch, Supabase also shipped Unified Logs (one searchable view across every Supabase service), open-sourced Supabase Evals (a benchmark harness that runs AI coding agents against real Supabase tasks and publishes the scores), added one-click Grafana Cloud dashboards on every plan including Free, and rolled out ChatGPT account sign-in. Individually these are small features. Together they describe a company deliberately expanding from "hosted Postgres plus auth" into "the full operating surface around your data" — observability, benchmarking, and now the pipe out to your warehouse, all inside one login.

Why the cost story matters — and why it's probably temporary

Here's where the "less obvious" angle pays off. Supabase's own pricing lists Pro at $25/month and Team at $599/month, and Pipelines is currently included on all paid plans with no separate metering visible in the docs.

Compare that to how the rest of the CDC/ELT market prices this exact workload:

• Airbyte moved to capacity-based pricing in 2025 — roughly $2.50 per credit, with 1 million rows costing on the order of 6 credits, or around $10 per GB moved from a database source.
• Estuary offers a free tier around 10 GB/month before usage-based pricing kicks in.
• Fivetran prices by monthly active rows (MAR), a model notorious for surprising customers as their data volume scales.

If you're a Supabase customer already paying for Pro or Team, getting Postgres-to-BigQuery CDC with no incremental line item is a genuinely good deal relative to bolting on any of the above. But read that as what it is: an alpha-period subsidy, not a permanent pricing commitment. Bundling an unmetered feature into existing plan tiers while a product is still being validated, then introducing usage-based pricing once it's proven out, is a well-worn SaaS playbook — the same market has just watched Composio raise its own overage pricing sharply after establishing its user base. There is no indication Supabase has announced future metering for Pipelines, and it would be wrong to claim otherwise — but budgeting as if today's "free with your plan" price is durable would be a mistake for anyone planning production usage around it.

Practical use cases

Where does this actually fit into a real stack right now, given the BigQuery-only limitation?

• Warehouse-native product analytics for teams already standardized on BigQuery and Looker/Looker Studio, who want their operational Postgres tables queryable alongside marketing and event data without a second sync tool.
• Lightweight reverse ETL avoidance — instead of syncing BigQuery-computed aggregates back into the app database via a separate tool, keep the raw operational tables flowing one direction into the warehouse and do the heavy computation there.
• Audit and event trails — TRUNCATE and DELETE capture makes it plausible to reconstruct row history in BigQuery even after the operational table itself has been cleaned up, useful for compliance-adjacent use cases (with the caveat that this is alpha software, not something to hang an actual compliance program on yet).
• ML feature pipelines that need a warehouse-side copy of production data for training without querying the live OLTP database directly and risking load on it.

If your target isn't BigQuery, none of this is actionable today — you're on the waitlist with everyone else asking for ClickHouse or Snowflake.

One more pattern worth naming: none of the above requires giving up your existing ETL tool entirely. A team already running Airbyte for ten upstream SaaS sources doesn't need to rip it out to also pick up Pipelines for the one Postgres-to-BigQuery leg that used to be the highest-maintenance connector in the stack. The realistic adoption path for most teams is additive — replace the single most annoying, most bespoke CDC job with the bundled option, and keep the general-purpose ELT tool for everything that isn't a first-party Postgres database.

Security posture and lock-in, specifically

Two questions worth asking before enabling this on a real project, since neither is answered by the feature-page pitch:

Where does the data actually live? The BigQuery dataset Pipelines writes to is a dataset in your own Google Cloud project, not a Supabase-managed copy. That's a meaningful point in favor of avoiding destination lock-in — the moment you stop using Pipelines, your warehouse data doesn't evaporate or need exporting from a Supabase-controlled store, because it was never there. That's a real, structural difference from vendors that land your synced data inside their own managed warehouse.

What does it do to your source-side lock-in? The opposite is true on the Postgres side. The publication, replication slot, and sync configuration all live inside Supabase's control plane and dashboard tooling. Migrating off Supabase to self-hosted Postgres or another provider means rebuilding the CDC layer from scratch with a different tool — Pipelines gives you nothing portable there. So the net effect is: warehouse-side lock-in goes down (you own the BigQuery dataset), source-side lock-in goes up (the pipeline itself only exists inside Supabase). For a team already committed to Supabase as their system of record, that's a reasonable trade. For a team hedging against vendor risk on the database layer, it's worth naming explicitly rather than discovering later.

On maintainability specifically: the dashboard-based lag and error visibility is a genuine win over the typical self-hosted setup, where "is the pipeline healthy" often means someone remembering to check a Grafana panel nobody built alerts for. Whether that visibility is enough to trust with revenue-critical data during an alpha is a judgment call each team has to make for itself.

What the marketing leaves out

• It's alpha. That word appears in Supabase's own changelog title — "[Public Alpha] Supabase Pipelines" — but doesn't show up prominently in the feature-page pitch. Alpha means no committed SLA, and reasonably means expect breaking changes to configuration or behavior before general availability.
• One live destination. The "keeps your analytics in sync" framing reads as warehouse-agnostic. It currently is not. If your organization runs ClickHouse or Snowflake, Pipelines is a roadmap item to watch, not a tool you can adopt this quarter.
• Replication slot risk is on you. Nothing about "managed" changes the fact that a stalled or misconfigured pipeline can grow WAL on your primary database. The dashboard gives you visibility into lag; it doesn't remove the underlying failure mode.
• Schema evolution isn't discussed. Adding or dropping columns, or changing types, on a table that's actively part of a CDC publication is one of the trickiest parts of running logical replication in production. The public docs describe pipeline status and table state monitoring, but not a documented story for handling schema drift mid-stream.
• No committed pricing model for GA. "Available on all paid plans" tells you today's price. It says nothing about tomorrow's.
• No mention of alerting. The dashboard shows lag and errors, but the documentation doesn't describe a way to get paged or notified when a pipeline stalls — you still have to remember to look, or wire your own polling against whatever status the dashboard exposes. For a feature explicitly designed to remove the "nobody's watching the Kafka Connect logs" failure mode of self-hosted CDC, shipping without a first-class alert path is a gap that undercuts the pitch.

How it stacks up against the field

The honest read: Supabase isn't trying to out-connector Fivetran or Airbyte, and it isn't trying to out-latency Estuary. It's making a narrower, structural bet — that owning the source database gives it a distribution advantage a standalone ELT vendor can never have, because the sync is a checkbox in a product you're already paying for, not a new vendor relationship to set up. That bet only pays off if Supabase actually ships the promised destinations and keeps the reliability bar high enough that people trust it with data that matters. Alpha software bundled for free is a good way to find out fast, at low cost to early adopters and low risk to Supabase's reputation if it doesn't work out.

The closest precedent for this move isn't a general ELT vendor at all — it's ClickHouse's own ClickPipes, which does the same thing in reverse: the destination database vendor owns the managed CDC pipe, rather than a neutral third party sitting between source and destination. What both have in common is the bet that owning one side of the pipe and offering the sync for free (or nearly free) is a better distribution strategy than competing as a standalone integration vendor. It's a sign of where the CDC market is heading generally: the standalone ELT middleman is being squeezed from both ends, by source-side platforms like Supabase and destination-side platforms like ClickHouse Cloud, each bundling the pipe into a product you were already going to buy. Fivetran and Airbyte's differentiator against that squeeze is connector breadth — hundreds of sources and destinations neither Supabase nor ClickHouse has any incentive to build — which is exactly why "ignore it if you need multi-source integration" is likely to remain true even after Pipelines exits alpha.

There's also a pricing signal worth watching independent of the product itself. Supabase has generally been willing to include heavier features — Grafana dashboards, Unified Logs — on the Free tier as well as paid ones. Pipelines notably is not on Free; it starts at Pro. That's a small tell that Supabase already sees this as a plan-differentiating, resource-intensive feature rather than a loss-leader, even before it introduces any usage-based metering on top.

Who should try it, who should wait, who should ignore it

Try it now if you're already on a paid Supabase plan, your warehouse is BigQuery, your tables have clean primary keys and reasonable write volume, and you're comfortable treating alpha software as alpha software — meaning you keep your existing backup/export path around as a fallback rather than cutting it over on day one.

Wait if you need ClickHouse, Snowflake, or DuckLake as a destination, need a documented SLA for a production data pipeline, or run high-write-volume tables where replication slot lag under load is a real operational risk you can't afford to discover live.

Ignore it if you're not on Supabase for your primary database, or if your integration needs span multiple source systems beyond a single Postgres instance — that's squarely Fivetran and Airbyte territory, and neither pretends otherwise.

Supabase has been on a clear trajectory this year: own more of the surface area around the database, not just the database itself. Pipelines is a real, useful step in that direction, and the bundled pricing during alpha is a genuinely good deal if it fits your stack today. Just don't mistake "public alpha, one destination, plan-bundled" for "production-ready warehouse replication," because the changelog itself is more honest about that gap than the announcement post is.

If you've stood up your own Postgres CDC with Debezium or plain logical replication before, how much of the operational burden was actually the initial pipeline setup versus the ongoing care and feeding of replication slots and schema drift — and does a managed layer like this change that ratio enough to justify handing a vendor your CDC pipeline this early in its life?

Sources:

• Supabase Pipelines | Supabase Features
• [Public Alpha] Supabase Pipelines · Changelog
• BigQuery destination | Supabase Docs
• Pipelines FAQ | Supabase Docs
• Supabase announcement on X
• Supabase to BigQuery: Real-Time Sync in Minutes - Estuary
• Airbyte vs Fivetran: Data Integration Tools Compared - Estuary
• Fivetran Alternatives + Engineering Time Costs (2026) - Definite
• Supabase Pricing 2026 Explained - Automation Atlas