Postgres to Snowflake: sync PostgreSQL data to Snowflake

If the destination is Snowflake, OptimaFlo still ingests Postgres the same way it does for any other target: read-only credentials, reflected schema, and an Iceberg-backed Raw layer in your own cloud. Snowflake only enters the picture at the last step, as an export target for finished Gold tables. Initial connector setup is about 15 to 20 minutes; the first full pipeline (Raw through Ready plus the Snowflake write) depends on how much modeling the Clean and Ready layers need.

Why Iceberg first, Snowflake second

A direct Postgres-to-Snowflake copy tool gives you one raw mirror. OptimaFlo's approach keeps the canonical, versioned copy of your data in open Apache Iceberg tables inside your own cloud account, and treats Snowflake, BigQuery, S3, GCS, and other databases as interchangeable export targets for the same Ready-layer output. If you later add a BigQuery-based BI tool alongside your Snowflake one, you export the same Gold table twice, you do not rebuild the pipeline.

How the Postgres side works

The connector reflects your database's schema through SQLAlchemy's inspect() API rather than a hand-maintained mapping, so a NUMERIC column becomes float, a TIMESTAMP becomes timestamp, and so on, using the same type vocabulary GCS, S3, BigQuery, and Redshift connectors share. You point it at a schema-qualified table, or hand it a raw SQL query for a source that does not map to one table. Table and schema identifiers are checked against a safe pattern before they reach SQL, so a data source name cannot become an injection vector even though the underlying read goes through a validated, reflected Table object rather than string concatenation.

The honest limit: full refresh, not CDC

Every run is a fresh SELECT. There is no write-ahead-log tailing, no binlog consumer, and no automatic "only pull what changed" behavior. For append-heavy tables (events, orders, form submissions) that is rarely a problem on a sensible schedule. For a table with frequent in-place updates and a hard freshness requirement, the workaround is a custom query with your own updated_at filter; the pipeline does not generate that watermark logic for you today.

Writing to Snowflake

The export step needs your Snowflake account identifier, target database, warehouse, table, and optionally a schema (Snowflake defaults to PUBLIC) and role. Write mode is one of append, overwrite, or upsert. OptimaFlo writes to the warehouse you specify; it does not provision or resize Snowflake compute on your behalf, and Snowflake credit usage is billed by Snowflake directly, the same way your cloud storage and compute are billed by GCP or AWS under OptimaFlo's BYOC model.

What is not supported

No CDC, no schema-from-query inference (a query-based Postgres source returns an empty schema, not a guess), and no automatic Snowflake warehouse management. If your requirement is millisecond-level Postgres-to-Snowflake replication, look at a dedicated CDC tool instead; OptimaFlo is built for the modeling and orchestration layer around a batch pipeline, not log shipping.