TL;DR
A Snowflake Postgres connector moves data out of PostgreSQL and into Snowflake for analytics. Snowflake currently recommends the GA Openflow Connector for PostgreSQL for that job, not the older preview-only connector of a similar name.
Key Takeaways “Snowflake Postgres connector” can mean the legacy preview connector, the newer Openflow Connector for PostgreSQL, or the unrelated Snowflake Postgres database service. The original Snowflake Connector for PostgreSQL is preview-only, and Snowflake has said general availability is not on its roadmap. Openflow Connector for PostgreSQL is the current GA path, built on Apache NiFi and Snowpipe Streaming, with a snapshot load followed by incremental CDC. Snowflake Postgres, generally available since February 2026, is a managed Postgres database that runs inside Snowflake. It is not a connector. Third-party tools such as Fivetran, Airbyte, Debezium, and Streamkap remain solid choices for multi-destination delivery or existing Kafka infrastructure. Kanerika, a Snowflake Select Tier Partner, helped a distributed operations team cut manual data reconciliation by 60 percent through a connector-driven Snowflake migration. Why This Search Gets Confusing Fast A data engineer searches “snowflake postgres connector” expecting a short setup guide. The first result is Snowflake’s own documentation. Specifically, it says the connector is a preview feature with no general availability date planned.
Meanwhile, the second result introduces a different product with a nearly identical name. By the third click, the engineer is holding two Snowflake products and four vendor names. In fact, there is no clear answer for which one actually moves data from PostgreSQL into Snowflake.
First, this guide sorts out which product does what and walks through how the current recommended connector works. It also compares that connector against the third-party tools engineering teams reach for when Snowflake’s own path does not fit.
What Is the Snowflake Postgres Connector Three separate Snowflake products get lumped into the same search term, and mixing them up wastes real setup time. The original Snowflake Connector for PostgreSQL, the newer Openflow Connector for PostgreSQL, and Snowflake Postgres all touch the words “Snowflake” and “Postgres.” However, only two of them move data between the two systems. In turn, only one of those two is meant for new production work.
The Snowflake Connector for PostgreSQL was Snowflake’s first native path from PostgreSQL into Snowflake. Specifically, it ships as a Docker-distributed agent that runs inside a customer’s own network. It then pushes change data into Snowflake using logical replication.
That connector remains a preview feature. Indeed, Snowflake’s own documentation states that moving it to general availability “is currently not on our product roadmap.” It also notes that future bug fixes are not guaranteed.
Openflow Connector for PostgreSQL is the replacement Snowflake actually recommends today. Additionally, it runs on Snowflake’s Openflow service, ingests through Snowpipe Streaming, and is generally available. Its architecture is covered in detail later in this guide.
Both connectors move data in one direction only. Specifically, they copy selected PostgreSQL tables into Snowflake for reporting and analytics. Neither one pushes Snowflake data back into PostgreSQL. Similarly, neither one turns Snowflake into a database that applications write to directly.
Which One Should You Actually Use Table 1: Snowflake Postgres Connector Options at a Glance
Product What It Does Status Data Direction Recommended For Snowflake Connector for PostgreSQL (legacy) Replicates Postgres tables into Snowflake via a self-hosted Docker agent Preview only, no GA planned Postgres to Snowflake Existing deployments only, not new builds Openflow Connector for PostgreSQL Replicates Postgres tables into Snowflake using Apache NiFi and Snowpipe Streaming Generally available Postgres to Snowflake New Snowflake-native replication projects Snowflake Postgres A fully managed Postgres database hosted inside Snowflake Generally available (Feb 2026) Not applicable, it is a database, not a connector Teams that want a transactional Postgres instance alongside their Snowflake data
The practical rule is simple. First, if the goal is analytics on PostgreSQL data, Openflow is the current answer. Second, if the goal is running a transactional Postgres database, Snowflake Postgres is a different product entirely.
The two sometimes work together rather than as substitutes for each other. In turn, the next section covers how that Openflow connector actually moves data under the hood.
Kanerika Service
Snowflake Consulting and Implementation
Kanerika is a Snowflake Select Tier Partner that designs, migrates, and operates Snowflake environments end to end, from architecture and connector strategy to AI-ready pipelines.
Explore Snowflake Services Snowflake Postgres Is a Database, Not a Connector Snowflake Postgres deserves its own explanation because the naming collision with the connector confuses new searches. Specifically, it is a fully managed PostgreSQL database service that runs inside Snowflake’s platform architecture . In addition, that service is built on technology Snowflake gained through its acquisition of Crunchy Data. Indeed, it reached general availability on February 24, 2026, across AWS and Azure, according to Snowflake’s own release notes .
The difference in purpose matters more than the naming overlap. Indeed, Snowflake Postgres hosts a live, writable Postgres database, the kind an application connects to for transactional reads and writes. The Openflow connector, by contrast, replicates data out of an existing Postgres database elsewhere. It then lands that data in Snowflake’s analytical tables.
The two can coexist in the same architecture. For example, a team might run Snowflake Postgres for a new application’s transactional workload. It might then use Openflow to replicate that same data into Snowflake’s analytical layer for reporting. That layer can also pull in data from other systems. However, anyone who searched for a connector and landed on Snowflake Postgres marketing pages is looking at the wrong product. It does not fit that specific job.
How the Openflow Connector for PostgreSQL Works Openflow is Snowflake’s managed data integration service. Specifically, it is built on Apache NiFi rather than the external Docker agent the legacy connector used. In turn, the PostgreSQL connector runs as a NiFi flow inside that service, and Snowflake operates the underlying compute.
Setup starts with schema introspection, the first of three stages Snowflake’s own Openflow connector documentation lays out for the connector. Specifically, the connector reads the source database’s metadata and identifies the schemas and tables selected for replication. It then prepares matching objects on the Snowflake side.
Next comes an initial snapshot. In turn, the connector copies every existing row from the selected tables before it starts tracking ongoing changes. This is the same way any full-table load works.
After the snapshot finishes, the connector switches to incremental change data capture. Specifically, PostgreSQL exposes row-level changes through its write-ahead log. In turn, the connector reads that log through a replication slot and publication. That is the same mechanism PostgreSQL’s own logical replication is built on. As a result, only the deltas move, not repeated full scans.
Records reach Snowflake through Snowpipe Streaming. Indeed, Snowflake says this is why its newer database connectors cost less. They also run with lower latency than the older agent-based model. The connector writes to two kinds of tables. First, one is a current-state table that mirrors the source. Second, the other is a journal table that preserves the change history for audit or downstream processing.
None of this happens instantly. In fact, Openflow supports near-real-time and scheduled replication modes. In turn, actual latency depends on transaction volume, network conditions, and how the pipeline is sized. This guide returns to that topic further down.
Prerequisites and Setup Steps PostgreSQL-Side Requirements The source database needs PostgreSQL 11 or later, and it needs wal_level set to logical. In turn, that setting ensures the write-ahead log carries enough detail for logical replication. Additionally, Openflow supports standard PostgreSQL along with Amazon RDS and Aurora, Google Cloud SQL, and Azure Database for PostgreSQL. However, each of those platforms has its own path to enabling those settings.
The connection has to reach the writable primary instance. Indeed, logical replication does not work against a standard read replica. That is because the write-ahead log a replica streams from is not the source of new committed changes.
Every table selected for replication should carry a primary key or a unique index with replica identity set. It can also use a logical key defined in the connector configuration instead. As a result, tables without one of those can typically only replicate insert operations, which limits their usefulness for tracking updates and deletes.
Snowflake-Side Requirements Setup on the Snowflake side needs the ACCOUNTADMIN role or delegated privileges for initial configuration. It also needs a destination database and schema for the replicated tables. Additionally, it needs enough Snowpipe Streaming capacity for the expected table count and change volume. In turn, Openflow itself needs a runtime provisioned, either Snowflake-managed or inside a customer’s own cloud account under the BYOC deployment model.
Setup Steps Create a dedicated PostgreSQL replication account with least-privilege access, and keep its credentials out of the flow definition itself. Enable logical replication on the source, and create the replication slot and publication for the selected tables. Provision the Openflow runtime in Snowflake and install the PostgreSQL connector. Configure the source and destination parameters, including host, database, schema and table selection, and the target Snowflake objects. Run schema introspection and review the detected tables, keys, and any unsupported column types before starting replication. Start the initial snapshot, then reconcile source and destination row counts before trusting the pipeline. Confirm the handoff from snapshot to incremental CDC, and test inserts, updates, and deletes on the source to verify they arrive correctly. Indeed, every one of those steps is a real place for something to go quietly wrong. That is why validation deserves as much attention as configuration.
Data Types, Keys, and Schema Changes PostgreSQL and Snowflake do not share an identical type system. As a result, most of the friction in a connector setup shows up here rather than in the network configuration.
Table 2: Common PostgreSQL to Snowflake Type Mappings
PostgreSQL Type Snowflake Type Note integer, bigint NUMBER Direct mapping, no precision loss numeric(p,s) NUMBER(p,s) Precision beyond Snowflake’s supported range fails replication text, varchar VARCHAR Direct mapping boolean BOOLEAN Direct mapping timestamp, timestamptz TIMESTAMP_NTZ, TIMESTAMP_TZ Time zone handling must match on both sides json, jsonb VARIANT Semi-structured data lands as a single VARIANT column uuid VARCHAR Stored as its string representation array types ARRAY Supported, but nested structures need testing
Two categories cause most real-world failures. The first is numeric columns with precision Snowflake does not support. The second is TOAST-stored large values in the legacy connector, which are not replicated at all. Ultimately, testing the actual column types in a source table beats trusting a generic mapping table, including this one.
Schema changes during replication need a policy, not an assumption. Indeed, column additions, drops, renames, and type changes all behave differently depending on the connector version. Openflow’s automatic schema evolution, however, handles more of these than the legacy connector does. Therefore, any planned change on the PostgreSQL side is worth testing against a non-production pipeline first.
Openflow Compared with Fivetran, Airbyte, Debezium, and Other Tools Openflow is not the only way to get PostgreSQL data into Snowflake. It is also not automatically the right one for every team. In turn, the honest comparison depends on what a team already operates and how many destinations the data needs to reach.
Table 3: PostgreSQL-to-Snowflake Tool Comparison
Tool Model CDC Method Best Fit Openflow Connector for PostgreSQL Snowflake-managed Log-based, via Apache NiFi Teams standardized on Snowflake wanting a native, GA path Fivetran Fully managed SaaS Log-based Teams that want a hands-off connector with broad source coverage and can accept usage-based pricing Airbyte Cloud or self-managed Log-based, open-source core Teams that want deployment flexibility and control over connector code Debezium with Kafka Self-managed Log-based, streams to Kafka Teams already running Kafka that need the same change events feeding multiple systems Streamkap Managed streaming CDC Log-based Teams wanting low-latency streaming without operating Kafka themselves Qlik Replicate or HVR Enterprise licensed Log-based Large estates spanning many enterprise databases needing centralized replication governance
What the Comparison Means for Your Team Fivetran and Airbyte both compete on ease of setup and broad connector catalogs that go well beyond PostgreSQL. Debezium with Kafka, in contrast, trades that convenience for control. Indeed, that trade-off is useful when the same PostgreSQL changes need to reach more than one downstream system.
Debezium’s own documentation describes the same snapshot-then-stream pattern Openflow uses, which is not a coincidence. In fact, most PostgreSQL CDC tools read the same write-ahead log through the same logical replication mechanism. In turn, they differ mainly in how they operate, price, and where the data goes next.
The decision usually comes down to three questions. First, does the data only need to reach Snowflake, or does it have to feed other systems too? Second, does the team want to operate infrastructure like Kafka, or would it rather avoid that? Third, does an existing vendor relationship or pricing model already favor one platform over the others?
On-Demand Webinar
Snowflake + Fabric: Expert Strategies for Interoperability, Data Sharing & Migration
A recorded session on connecting Snowflake to the rest of the enterprise data estate, covering interoperability patterns, data sharing, and migration strategy.
Watch the Webinar → Performance, Latency, and Cost Factors Snapshot time scales with table size, row width, and how many tables replicate at once. For example, a handful of narrow tables snapshot in minutes. By contrast, dozens of wide tables with billions of rows take considerably longer. Running too many snapshots concurrently, meanwhile, competes for the same source database connections.
Ongoing CDC latency depends on PostgreSQL’s transaction volume and network distance between the source and Snowflake. It also depends on how the Openflow runtime is sized. Snowflake’s own setup guidance flags two situations. The first is sources generating roughly 15,000 events per second. The second is requirements under one minute of latency. Ultimately, both signal that a pipeline needs deliberate sizing rather than default settings.
Snowpipe Streaming pipe limits matter at scale too. A single replicated table, for example, can consume separate pipes for its snapshot and incremental data. Therefore, teams replicating hundreds of tables should check account-level pipe limits before committing to one connector instance for everything.
Cost adds up across several separate lines. Specifically, these include the Openflow runtime itself and Snowpipe Streaming ingestion. They also include the Snowflake compute that queries the replicated tables and the engineering time to monitor and maintain the pipeline. In fact, none of the tools in this comparison publish a single number covering all of it. That is why a short proof of concept against real table sizes and change volume is worth more than any published benchmark.
Checklist
Snowflake Performance Optimization Checklist
A practical checklist for right-sizing warehouses, controlling credit spend, and keeping query performance predictable as connector-driven data volume grows.
Get the Checklist → Snowflake Data Migration: How Kanerika Cut Manual Reconciliation by 60 Percent Kanerika is a Snowflake Select Tier Partner. Indeed, its data engineering team has run production migrations onto Snowflake across fragmented, multi-system environments. That is the same category of problem a Postgres-to-Snowflake connector project usually sits inside.
One published Kanerika case study covers a beverage manufacturer and distributor. Specifically, that company was running a fragmented mix of legacy SSAS and hybrid database systems across ERP, HR, and IoT sources. Slow, hourly refresh cycles were limiting real-time visibility. Meanwhile, multiple licenses and replication tools were driving up operational cost.
The migration consolidated those sources onto Snowflake, using Fivetran to move the data and Power BI on top for reporting. As a result, the reported outcomes were a 60 percent reduction in manual data reconciliation and 40 percent faster data reporting cycles. They also included three times quicker analytics delivery and $130,000 in annual savings from retired licenses and maintenance.
The connector in that engagement was not Postgres-specific, but the migration discipline transfers directly. Source assessment, snapshot reconciliation, CDC validation against production traffic, and a controlled cutover all matter. Indeed, they matter just as much whether the source system is SSAS, Azure SQL Database, Oracle , or PostgreSQL. In turn, Kanerika’s data engineering and migration teams apply the same validation approach to Postgres-to-Snowflake projects. Specifically, they check row counts, key coverage, and business-level aggregates before a pipeline goes into production.
Case Study
60% Less Manual Reconciliation via Snowflake Migration
A beverage manufacturer and distributor replaced manual reconciliation across a fragmented, multi-system environment with governed, centralized Snowflake data, cutting reconciliation effort by 60 percent.
Read the Case Study → How to Choose the Right Snowflake Postgres Connector The right choice depends less on feature lists and more on what a team already operates. It also depends on how much control the team needs over the pipeline.
Choose Openflow Connector for PostgreSQL when PostgreSQL 11 or later, standard authentication, and a Snowflake-only destination cover the requirement, and a Snowflake-native, GA path is preferred. Choose Fivetran or Airbyte when broader connector coverage beyond PostgreSQL, a fully managed experience, or an existing platform standard outweighs a Snowflake-native setup. Choose Debezium with Kafka when the same PostgreSQL changes need to feed more than one downstream system, and the team can operate the added Kafka infrastructure. Choose Qlik Replicate or HVR when the estate spans many enterprise databases and needs centralized replication governance at scale. Do not choose the legacy Snowflake Connector for PostgreSQL for a new production build, given its preview-only status and the absence of a GA roadmap. Do not choose Snowflake Postgres to solve a replication problem. It is a database service, not a connector. Whatever gets selected, run a real proof of concept before committing. Specifically, test snapshot time, CDC lag, a schema change, and a recovery scenario against representative data, not just a demo dataset. Indeed, the connector that looks simplest in a sales demo is not always the one that holds up at production volume.
Wrapping Up “Snowflake Postgres connector” covers more ground than it first appears. Specifically, Openflow Connector for PostgreSQL is the current, generally available path for moving live PostgreSQL data into Snowflake. It replaces a legacy connector that Snowflake has confirmed will not reach general availability. In contrast, Snowflake Postgres solves a different problem entirely, hosting a managed transactional database rather than replicating one.
Third-party tools like Fivetran, Airbyte, and Debezium remain valid alternatives. In fact, they are especially worth considering when broader source coverage or existing infrastructure matters more than a Snowflake-native setup. Additionally, teams weighing the decision should test real data volumes before committing. Ultimately, they should lean on migration partners who have already validated the pitfalls.
Frequently Asked Questions
Is the Snowflake Connector for PostgreSQL generally available? No. The Snowflake Connector for PostgreSQL is a preview feature, and Snowflake has stated that moving it to general availability is not currently on its product roadmap. Snowflake recommends the newer Openflow Connector for PostgreSQL for new projects instead. Existing deployments continue to run, but should not be treated as a long-term production standard.
Is the legacy Snowflake Postgres connector being discontinued? Snowflake has not announced a discontinuation date, but it has confirmed the connector will not reach general availability and that future fixes are not guaranteed. In practice, that makes it a maintenance-mode product. Teams running it in production should plan a migration to the Openflow Connector for PostgreSQL rather than waiting for an official end-of-life notice.
What is the difference between the Snowflake Postgres connector and the Openflow Connector for PostgreSQL? They are effectively the old and new versions of the same job. The original Snowflake Connector for PostgreSQL uses a self-hosted Docker agent and remains preview-only. The Openflow Connector for PostgreSQL is the generally available replacement, built on Apache NiFi and Snowpipe Streaming, and is the version Snowflake currently recommends.
Is Snowflake Postgres the same as connecting PostgreSQL to Snowflake? No. Snowflake Postgres is a fully managed Postgres database that runs inside Snowflake, built from Snowflake’s acquisition of Crunchy Data. Connecting an existing PostgreSQL database to Snowflake for analytics is a separate job, handled instead by the Openflow Connector for PostgreSQL or a third-party tool such as Fivetran or Airbyte. The two products solve different problems and are not interchangeable.
Does the Openflow Connector for PostgreSQL support change data capture? Yes. After an initial snapshot copies existing rows, the connector switches to incremental change data capture, reading insert, update, and delete operations from PostgreSQL’s write-ahead log through a replication slot. Changes flow into Snowflake through Snowpipe Streaming, landing in both a current-state table and a journal table that preserves the change history.
Can Snowflake Openflow replicate PostgreSQL tables without primary keys? Only in a limited way. A table needs a primary key, a unique index with replica identity set, or a configured logical key for full insert, update, and delete tracking. Tables without one of those can typically only replicate insert operations, which makes update and delete tracking unreliable for that table.
Can the PostgreSQL connector connect to an Amazon RDS or Aurora read replica? No. Logical replication requires a connection to the writable primary instance, not a read replica. Amazon RDS and Aurora both support the logical replication settings the connector needs, but those settings and the replication slot itself have to be configured on the primary, since a replica does not generate its own write-ahead log entries.
Which tool is better for PostgreSQL-to-Snowflake CDC, Openflow, Fivetran, Airbyte, or Debezium? There is no universal answer. Openflow fits teams standardized on Snowflake who want a native, generally available path. Fivetran and Airbyte suit teams that want a managed connector covering many source systems beyond PostgreSQL. Debezium with Kafka fits teams that already run Kafka and need the same change events feeding more than one downstream system.
