Pipelines FAQ
Common questions and answers about Supabase Pipelines.
Public Alpha
Supabase Pipelines is currently in public alpha. Features and behavior may change as we continue developing the product.
Which plans support Pipelines?#
Pipelines requires a Pro, Team, or Enterprise plan. During public alpha, availability varies by organization; an eligible plan does not guarantee access. If unavailable, request access from Database > Replication or contact your account manager.
What destinations are supported?#
BigQuery is in public alpha. ClickHouse, DuckLake, and Snowflake are in private alpha and require access approval. See supported destinations for their status and access request.
Does the destination's region affect performance?#
Yes. Distance between the source, pipeline, and destination adds network latency and can reduce throughput. Choose resources near the managed pipeline region, prioritizing the destination if you can optimize only one side.
What does Pipelines install in the database?#
Pipelines installs objects in your project's Postgres database to track replication and support schema changes:
- An
etlschema containing internal tables for replication state and progress, source table schemas, destination mappings, and migration history. - Helper functions in
etlthat read table definitions and prepare schema-change messages. - A database event trigger,
supabase_etl_ddl_message_trigger, that runs afterALTER TABLEandALTER PUBLICATION. It writes schema-change information for published tables to the write-ahead log (WAL), so Pipelines can process supported changes alongside row changes.
Each pipeline also uses replication slots to track its position in WAL. See initial sync and table-sync slots for how these retain changes during replication.
The etl schema is reserved for Pipelines. If your application already uses a schema named etl, rename it and update references to it before enabling Pipelines. Do not add application objects to the Pipelines-managed schema or include it in a publication.
To remove the installed objects, delete all pipelines, then disable Pipelines.
What does Pipelines check before creating a pipeline?#
The Dashboard validates source access, replication capacity, publication tables, and destination connectivity and requirements. Required issues block creation; Warnings require review. See creation checks.
What schema changes are supported?#
Support differs by destination. Check the schema-change guides before changing column types, defaults, keys, or constraints.
Can data be processed more than once?#
Yes. Pipelines provides at-least-once processing: recovery can replay acknowledged data, and consumers of append-only histories must tolerate repeated events. Destination deduplication does not provide an exactly-once processing guarantee.
See the data models for BigQuery, ClickHouse, DuckLake, and Snowflake, and the billing implications.
Why is a table not being replicated?#
Check that:
- The table is published. If you added it after starting the pipeline, restart the pipeline to discover it.
- The table and published columns satisfy the destination's primary-key and replica-identity requirements.
- Publication row filters include the expected rows.
- Missing columns aren't generated; Pipelines skips generated columns.
If new changes arrive but existing rows are missing, check the initial sync selection. Changing a row filter also does not copy newly included historical rows.
If inserts work but updates or deletes fail, review the source table requirements for BigQuery, ClickHouse, DuckLake, or Snowflake.
Why is a table in error state?#
An initial sync or ongoing replication operation failed, for example after an unsupported schema change. Some errors retry automatically; others require restarting replication for the affected tables from scratch. See Table errors for diagnosis and Restarting tables for the procedure and its effects.
Why is a pipeline failed or stopped?#
Failed reports a startup or runtime error and can recover automatically. Stopped requires a manual start. Follow pipeline error recovery to diagnose the cause before restarting.
Why is replication lag increasing?#
Postgres is producing WAL faster than Pipelines confirms progress. Follow Investigate the lag to distinguish source activity, destination throughput, and connectivity problems.
What does a Lost slot status mean?#
Required WAL is gone, so replication cannot continue from that slot. Follow slot recovery; recovery scope depends on whether the main slot or a table-sync slot was lost.
What happens if a table is deleted at the destination?#
Deleting or modifying managed objects can stop replication and require a new initial sync. To remove one safely, remove the source table from the publication and restart the pipeline before deleting its destination table.
What happens when a project becomes inactive or moves to the Free Plan?#
Project inactivity stops its pipelines. Start them manually after restarting the project. Downgrading to the Free Plan deletes its pipelines.
What happens when you disable Pipelines?#
Disabling Pipelines removes its database event trigger and the entire Pipelines-managed etl schema, including its tables and helper functions. Your source application tables and existing destination data remain.
Delete all pipelines first, then follow Disabling Pipelines. Deleting the pipelines alone does not remove the shared database installation.