SUPABASE → SNOWFLAKE
Choose an RLS-scoped Supabase Auth connection or a PostgreSQL database user for warehouse-wide replication.
Use the dedicated Supabase source when Snowflake should receive the rows visible to an application user. Use the PostgreSQL source when a database user should replicate every table and row it is permitted to read. Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume.
Two access paths for tenant-scoped exports or centralized warehouse replication: with no per-row fees.
Verified connector behavior and known limits for this source.
| Feature | How it works | Limit / caveat |
|---|---|---|
| Supabase Auth and RLS | Connect with a publishable or legacy anon key, then sign in with email/password or magic link. Each row read uses the signed-in user session, so Supabase evaluates that user's Row Level Security policies. | RLS controls source-row visibility. The connector does not copy Supabase RLS policies into Snowflake. |
| PostgreSQL database-user replication | For centralized replication, connect the PostgreSQL source with a dedicated database username and password. It discovers schemas and tables visible to that user and reads every selected row the user is permitted to access. | Grant the database user CONNECT, schema USAGE, and table SELECT for the intended scope. This path uses PostgreSQL credentials, not Supabase Auth or API keys. |
| Metadata discovery without a service-role key | A metadata helper installed in the Supabase project exposes schemas, tables, columns, and primary keys to the authenticated role. Actual row reads still use the signed-in user session. | Install the helper in each connected project. Supabase secret keys are not required for discovery or reads. |
| Supported database objects | Discovers ordinary and partitioned tables in public and other Data API-exposed schemas when the authenticated role has schema usage and table read access. | Views and foreign tables are not discovered. Materialize view data into a table when it must be synced. |
| Timestamp-based incremental sync | Tables with a recognized modification column, such as `updated_at`, `modified_at`, or `last_modified_at`, can run in bounded incremental windows on your schedule. | This is not WAL or logical-replication CDC. Incremental reads do not emit hard-delete events. |
| Deterministic pagination | Read Page Size is configurable from 1 to 1,000 rows. Tables with a source primary key use stable key-based ordering across pages instead of relying on unordered offsets. | An unbounded read that needs more than one page requires a primary key. The connector stops rather than risk duplicated or skipped rows. |
| PostgreSQL value mapping | Common PostgreSQL values are mapped to Snowflake types. Arrays, JSON, and JSONB follow the JSON path into Snowflake VARIANT; numeric and timestamp values use their corresponding canonical types. | PostgreSQL types without a direct mapping fall back to readable strings rather than receiving a source-specific Snowflake type. |
| Rate limiting and session refresh | The connector refreshes Supabase Auth sessions before expiry. Transient throttling and server errors retry with backoff, jitter, cancellation checks, and Retry-After support. | A revoked refresh token requires reconnection. Expensive RLS policies can still exceed the source project's statement timeout. |
| Snowflake destination | Selected Supabase tables land in generated Snowflake tables. Choose the Snowflake load behavior separately from the Supabase source sync mode. | A Snowflake merge or overwrite strategy does not turn the Supabase source into a delete-event or CDC source. |
Every Supaflow connector is included on every plan at no extra cost. You pay only for compute consumed, measured in Supaflow Credits (1 credit = 1 billable job hour on an S (Small) Agent node). No per-row fees.
The dedicated Supabase source signs in as an application user, so a tenant-scoped export sees the rows allowed by that user's RLS policies. The PostgreSQL source signs in with an actual database username and password, so a centralized replication pipeline can read every selected table and row that database user is permitted to access.
The connector uses source primary keys to keep multi-page reads deterministic. If a large table has no primary key, it fails with a specific correction instead of continuing through unordered offset pages that can duplicate or skip rows.
These source-specific cases affect discovery, parsing, or incremental reads. The notes below explain the failure mode and connector behavior.
Failure mode: Treating a Supabase API key as a PostgreSQL login sends the pipeline down the wrong setup path and does not provide a database connection.
Evidence: The Supabase source uses a publishable or legacy anon key plus an Auth user session. The PostgreSQL source requires a database host, database name, username, and password.
Fix: Use Supabase Auth for RLS-scoped reads. For warehouse-wide replication, create a dedicated read-only PostgreSQL user, grant the intended schema and table access, and connect through the PostgreSQL source.
Failure mode: A row-only integration can read data but still miss schema, column, and primary-key metadata needed to build stable destination tables and paginate safely.
Evidence: The connector checks for the Supaflow metadata helper during setup and reports a specific error when the helper is missing or not visible.
Fix: Install the metadata helper once per Supabase project. It exposes metadata to the authenticated role while row reads remain RLS-controlled.
Failure mode: Unordered offset pages can shift while rows are inserted or updated, causing duplicate or skipped rows during a large full refresh.
Evidence: After a full REST page without a source primary key, the connector stops before requesting another unsafe offset page.
Fix: Add a primary key to the source table, use a reliable incremental column, or keep a bounded read within one page.
Failure mode: Postgres may evaluate many candidate rows before RLS returns the visible set. A request can exceed `statement_timeout` even when the result page is small.
Evidence: The connector detects PostgREST timeout code `57014` and reports the affected Supabase table instead of returning a generic read failure.
Fix: Increase the timeout for the authenticated role or simplify the expensive policy. Lowering Read Page Size alone may not reduce the policy scan.
Use the Supabase source when an application user's RLS visibility should govern the sync. Use the PostgreSQL source when a dedicated database user should provide broader replication access.
Install the metadata helper, enter the project reference and a publishable or legacy anon key, then sign in with email/password or magic link as the user whose RLS visibility should govern the sync.
Supabase source docs→Create a dedicated read-only PostgreSQL user, grant it CONNECT, schema USAGE, and table SELECT for the intended scope, then enter that user's database connection details.
PostgreSQL source docs→Choose the tables and columns to replicate, select full refresh or a reliable incremental cursor, connect Snowflake, and run the pipeline on the cadence your freshness target requires.
Snowflake destination docs→Supaflow signs in as a Supabase Auth user and reads selected tables through the Supabase Data API. The source project evaluates that user's RLS policies before rows are returned, and the resulting rows load into generated Snowflake tables. A metadata helper supplies schema and primary-key information without a service-role key.
The Supabase source uses a publishable or legacy anon key plus a Supabase Auth user session, so reads follow that application user's RLS policies. The PostgreSQL source uses an actual database username and password. It is the better fit for centralized replication because it can read every selected table and row that database user is permitted to access.
Yes. Use the PostgreSQL source with a dedicated database user that has CONNECT, schema USAGE, and table SELECT across the schemas and tables you intend to replicate. Supaflow can then read every selected row that user is permitted to access. Use the dedicated Supabase source instead when an application user's RLS visibility should limit the export.
Supaflow supports scheduled timestamp-based incremental sync for tables with a recognized modification column such as `updated_at`. It does not use Postgres WAL, logical replication, or CDC, and incremental reads do not capture hard deletes. Use full refresh or model deletions explicitly when downstream removal is required.
No. Supabase evaluates RLS at read time and returns only the rows visible to the configured Auth user. The connector copies those visible rows, not the policy definitions. Configure Snowflake roles, row-access policies, and grants separately for warehouse users.
Fivetran and Hevo commonly meter changed rows or volume, so a backfill or a high-churn application table can increase the month's bill. Every Supaflow connector is included on every plan at no extra cost. You pay only for compute consumed, measured in Supaflow Credits (1 credit = 1 billable job hour on an S (Small) Agent node). No per-row fees. See the pricing page for the credit packages and free tier.
Yes. Run the Supaflow Agent in your VPC, or run it in your Snowflake account through the Snowflake Native App. In customer-controlled deployments, the data plane connects to Supabase and Snowflake from that environment; Supaflow Cloud keeps orchestration and encrypted connection metadata rather than processing the row data.
Only when the selected read fits within one REST page or another explicit bound. Multi-page reads need a source primary key so the connector can order pages deterministically. Add a primary key, choose a reliable incremental column, or keep the selected read within the configured page limit.
The Supabase source and Snowflake destination, plus other Supaflow connectors you can pair into a Snowflake pipeline.
RLS-aware source connector overview and setup options.
Destination connector overview, authentication, and load behavior.
Use a dedicated database user for centralized, warehouse-wide Supabase replication.
Migrate warehouse tables with staged bulk loading and scheduled incremental updates.
Pair product data with CRM and marketing activity in Snowflake.
Browse the full catalog of sources and destinations.
Install the metadata helper, configure Supabase Auth, select tables, and troubleshoot RLS-controlled reads.
Connect your warehouse, choose authentication, and configure schema and load behavior.
Compare managed, VPC, and Snowflake Native App data-plane options.
Every connector is included on every plan. Pay only for compute consumed (Supaflow Credits).
Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume. Use RLS-scoped Supabase Auth or an actual PostgreSQL database user, then run full-refresh or cursor-based incremental loads into Snowflake.