POSTGRESQL → SNOWFLAKE
Replicate PostgreSQL tables into Snowflake with primary-key backfills, streamed incremental syncs, and full Postgres type fidelity.
Large Postgres backfills fail when pipelines rely on offset scans, and financial tables fail when arbitrary-precision numbers are squeezed into fixed-width integers. Supaflow reads primary-key tables in stable chunks, streams incremental changes from your selected column, preserves NUMERIC precision, keeps JSONB queryable in Snowflake, and respects case-sensitive quoted identifiers. Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume.
Used by data engineering teams running on RDS, Cloud SQL, Aurora, Supabase, and Crunchy Bridge that need Postgres data in Snowflake — with no per-row fees.
Every row below is an actual capability in the PostgreSQL connector, not a forward-looking promise.
| Feature | How it works | Limit / caveat |
|---|---|---|
| Replication strategy | Initial snapshots on primary-key tables are read in stable primary-key chunks. Incremental syncs stream rows from the column you choose, typically an updated-at timestamp or identity column. | This is not a database-log CDC connector today, so it does not capture hard deletes unless your source models deletes explicitly. Contact us if hard-delete capture is blocking. |
| Pagination (initial full-table reads) | Initial snapshots on tables with stable primary keys use keyset-style reads instead of offset scans, so each page can use the primary-key index even deep into a large table. | Primary-key pagination applies to snapshot reads. Tables without a stable primary key fall back to streamed full reads. |
| TLS / SSL | Full Postgres SSL mode coverage: `disable`, `allow`, `prefer` (default), `require`, `verify-ca`, `verify-full`. Compatible with managed Postgres providers (RDS, Cloud SQL, Supabase) and self-hosted with custom CA bundles. | — |
| Postgres-specific type handling | JSONB stays queryable as JSON instead of becoming a plain string. NUMERIC preserves large precision where Snowflake can represent it and falls back to text rather than silently truncating. TIMESTAMPTZ, BYTEA, UUID, ENUM, INET, CIDR, and INTERVAL are mapped deliberately instead of coerced generically. | Types without a direct Snowflake equivalent, such as composite types and intervals, land as readable text. |
| Schema discovery | Supaflow discovers tables, columns, and primary keys automatically, excludes Postgres system schemas, and includes materialized views or foreign tables when they are queryable by the configured role. | — |
| Quoted identifier handling | Postgres folds unquoted identifiers to lowercase but preserves case in double-quoted ones. The connector matches that semantics — `"MyTable"` and `mytable` are distinct, and the destination table name reflects the source casing. | — |
| Incremental ordering | Incremental reads use a stable ordering so retries resume predictably, including tables where some rows have empty incremental values. | — |
| Destination | Lands directly in Snowflake with generated tables, Snowflake-ready types, primary keys, queryable JSONB data, and incremental merges keyed on the source primary key. | — |
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 compute-hour on a Small node). No per-row fees.
Offset-based backfills get slower as the page number grows because Postgres still has to walk past earlier rows. Supaflow reads primary-key tables in stable chunks so large initial snapshots keep using the source index, then switches to streamed incremental reads from your selected column.
JSONB stays queryable as JSON instead of becoming text. NUMERIC keeps precision where Snowflake can represent it. TIMESTAMPTZ keeps timezone context. Postgres-specific types such as INET, CIDR, INTERVAL, and custom ENUMs land as readable values rather than being dropped or coerced generically.
Every one of these is something our connector handles specifically. A generic pipeline built in Airflow or a basic ELT tool will hit at least three of them in production.
Failure mode: Offset-based backfills get progressively slower because Postgres still has to walk past earlier rows before returning the next page.
Evidence: Standard Postgres planner behavior on large ordered tables.
Fix: Supaflow uses primary-key pagination on eligible tables so each page can seek from the previous primary-key boundary instead of scanning from the beginning.
Failure mode: Postgres NUMERIC can exceed the precision of a fixed-width destination type. Pipelines that force it into a smaller number column can truncate financial values without warning.
Evidence: Common in fintech, accounting, and billing schemas that use high-precision numeric columns.
Fix: Supaflow preserves numeric precision where Snowflake can represent it and falls back to readable text rather than silently truncating values.
Failure mode: Many ELT tools serialize JSONB into a string column. Downstream teams then have to parse text every time they query nested fields.
Evidence: Common pattern across hand-rolled and several commercial Postgres connectors.
Fix: Supaflow lands JSONB as queryable JSON in Snowflake so nested fields can be accessed directly.
Failure mode: Postgres folds unquoted identifiers to lowercase but preserves case for double-quoted ones — `"MyTable"` and `mytable` are distinct objects. Pipelines that lowercase everything collide; pipelines that preserve casing accidentally on unquoted identifiers create duplicate tables in the destination.
Evidence: Standard Postgres SQL identifier semantics; trips up most case-naive tools.
Fix: The connector matches Postgres semantics exactly: quoted identifiers preserve casing, unquoted fold to lowercase. The destination Snowflake table name reflects the source identifier as Postgres sees it.
Provide host, port, database, and credentials. Pick an SSL mode (`disable` / `prefer` / `require` / `verify-ca` / `verify-full`). The connector works against self-hosted Postgres and managed providers (RDS, Cloud SQL, Aurora, Supabase, Crunchy Bridge, Neon).
PostgreSQL source docs→Tables, columns, and primary keys are discovered automatically. For incremental sync, pick an incremental column per table, typically an updated-at or created-at timestamp.
Connect your Snowflake warehouse. Each Postgres table becomes a Snowflake table with primary keys preserved, JSONB kept queryable, and deliberate handling for NUMERIC, TIMESTAMPTZ, BYTEA, UUID, and other Postgres-specific types.
Snowflake destination docs→Run on a cron or interval schedule. Incremental sync reads rows past the last saved value for your selected column; the initial full-table backfill uses primary-key pagination on eligible tables.
Schedules docs→Supaflow reads Postgres tables into generated Snowflake tables with primary keys and Postgres-aware type handling. Initial snapshots on primary-key tables use stable primary-key pagination, and incremental syncs read rows past the last saved value for the incremental column you choose.
Not currently. The Postgres connector is an incremental-read connector, not a database-log CDC connector. That works for most analytical use cases, but it cannot capture hard deletes unless your source models deletes explicitly. Contact us if hard-delete capture is blocking.
JSONB lands in Snowflake as queryable JSON instead of a plain string. Downstream teams can query nested fields directly instead of parsing text on every read.
Postgres NUMERIC can carry more precision than many destination number types. Supaflow preserves precision where Snowflake can represent it and falls back to readable text rather than silently truncating values.
Yes. Full SSL mode coverage covers common managed-Postgres TLS configurations, including RDS, Supabase, Cloud SQL, and Neon. Initial full-table backfills use primary-key pagination on eligible tables, which is important on managed tiers where long-running offset scans can hit provider-side limits.
Fivetran and Hevo often price by rows or changed-record volume, which makes Postgres pricing unpredictable — a single backfill of a high-churn table can spike your bill mid-month. 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 compute-hour on a Small node). No per-row fees. See the pricing page for the credit packages and free tier.
Yes. The sync agent runs in your own VPC if you want Postgres credentials and row content to stay in your network. The control plane is managed; the data plane can be managed or self-hosted. This is the typical deployment pattern when the Postgres database is also inside your VPC.
The PostgreSQL source and Snowflake destination, plus other Supaflow connectors you can pair into a Snowflake pipeline.
Source connector overview and capabilities.
Destination connector overview and capabilities.
For Microsoft-side replication with full Change Tracking (delete capture).
Pair with Postgres for SaaS apps that combine product data with CRM.
Pair with Postgres for cross-system analytics joining product and marketing data.
Browse the full catalog of sources and destinations.
Connection setup, SSL modes, role and grant requirements, incremental configuration, and troubleshooting.
Connect your Snowflake warehouse, role requirements, type mapping, and sync semantics.
Every connector is included on every plan. Pay only for compute consumed (Supaflow Credits).
Browse every Supaflow source and destination.
Every connector is included on every Supaflow plan — you pay only for the compute your pipelines consume. Primary-key backfills, streamed incremental syncs, queryable JSONB, Postgres type fidelity, and managed-provider SSL support.