Short answer: Snowflake Openflow is Snowflake's managed data integration service, built on Apache NiFi. It works in production, and Snowflake ships updates often. Teams running database CDC with it, however, report six recurring trade-offs: runtime sizing that is fixed at creation, costs spread across several billing meters, naming decisions that are hard to change later, strict rules on source schema changes, failures that need deliberate alerting, and a Gen 1 to Gen 2 transition that is only partly complete.
| Trade-off | What happens | Applies to | What to do |
|---|---|---|---|
| 1. Runtime sizing | CDC connectors run on one node, and a runtime's size can't be changed after creation | PostgreSQL, SQL Server, Oracle CDC | Size for peak volume; test the resize path |
| 2. Several cost meters | Runtime compute, warehouse merges, ingestion, and telemetry are billed separately | All deployments; BYOC adds a cloud bill | Model each meter during the proof of concept |
| 3. Naming decisions | Destination names default to source names and are set before the first snapshot | Database CDC connectors | Set the Destination Schema Pattern up front |
| 4. Schema-change rules | Primary key and numeric precision changes stop replication for that table | PostgreSQL, SQL Server | Plan source DDL; keep a re-snapshot runbook |
| 5. Failure handling | Failed tables and retry storms need configured alerts to surface | CDC connectors | Set up staleness alerts before go-live |
| 6. Gen 1 to Gen 2 transition | Gen 2 runtimes are GA; Gen 2 connectors are in preview for two sources | All new deployments | Check which connectors are Gen 2 today |
Each trade-off below states what happens and when it applies, as documented on October 26, 2026. The guide ends with when Openflow is a good fit, a proof-of-concept checklist, and alternatives.
What is Snowflake Openflow?
Snowflake Openflow is Snowflake's data integration service, built on Apache NiFi. It came from Snowflake's acquisition of Datavolo, a company founded by NiFi's original creators. Openflow reached general availability on May 30, 2025, with some connectors still in preview at launch.
Openflow runs in two deployment models:
- BYOC (bring your own cloud): runtimes run in your own cloud account, and you pay your cloud provider for the infrastructure in addition to Snowflake.
- Snowflake Deployment: runtimes run on Snowpark Container Services inside your Snowflake account. This option entered preview on September 17, 2025.
Openflow also has two generations. Gen 1 objects are managed mainly through the NiFi canvas. Gen 2 turns deployments, runtimes, and connectors into Snowflake SQL objects with standard role-based access control. Gen 2 deployment and runtime objects became generally available on AWS and Azure on September 8, 2026 and on GCP on September 11. Gen 2 connector configuration, including the setup wizard and the PostgreSQL and MySQL/MariaDB CDC connectors, remains in public preview.
Openflow's packaged connectors focus on database CDC (PostgreSQL, MySQL, SQL Server, Oracle, MongoDB) and SaaS sources such as Salesforce. Most limitations below come from that CDC use case, because it is where most teams evaluate Openflow.
Limitation 1: Runtime sizing is fixed, and CDC connectors don't scale out
Openflow's database CDC connectors run on a single node, and a runtime's size can't be changed after it is created. Capacity planning therefore happens up front, not as volume grows.
- Single node only. The PostgreSQL, SQL Server, and Oracle connectors don't support multi-node runtimes; min and max nodes must both be 1.
- Medium minimum. The SQL Server and Oracle connectors require a Medium or Large runtime, with Large recommended for high throughput or wide rows.
- Size is fixed at creation. To resize, you run the connector on a different runtime: either install a fresh connector, which means re-snapshotting tables, or migrate the existing connector to keep its progress.
- Shared capacity. Current documentation allows several SQL Server connector instances of the same type on one runtime. Those connectors share one node's CPU and memory, so a heavy workload on one can slow the others.
What this means in practice: Scaling an Openflow CDC pipeline isn't always as simple as adding more compute nodes. For connectors restricted to single-node runtimes, teams may need to monitor resource usage, choose a larger runtime size, and adjust their deployment as workloads grow. This adds capacity-planning work and can make sudden increases in data volume harder to handle.
Limitation 2: Cost is spread across several meters
An Openflow CDC pipeline is not one line item. Which charges apply depends on the deployment type and how telemetry is configured, but a typical database CDC pipeline incurs several of these:
| Cost meter | What it charges for | Applies to |
|---|---|---|
| Openflow runtime compute | vCPUs used by runtimes (BYOC), or SPCS compute pool instances billed per second with a 5-minute minimum (Snowflake Deployment) | All |
| Control pool | A control pool node that runs alongside active runtimes' compute pools | Snowflake Deployment |
| Warehouse | Database CDC connectors need a warehouse for the initial snapshot and incremental merges | All CDC connectors |
| Ingestion | Snowpipe or Snowpipe Streaming, based on data volume | All |
| Telemetry | Logs and metrics sent to your event table, billed per GB at the rate in Snowflake's Service Consumption Table (source) | All |
| Cloud infrastructure | Compute, storage, and networking in your own cloud account | BYOC only |
Even the smallest Snowflake-hosted setup runs two instances. Snowflake's example of one small runtime active for one hour totals 2 CPU_X64_S instance-hours: one control pool node and one compute node.
Cost tracking has a gap too. The OPENFLOW_USAGE_HISTORY view does not yet contain records for Snowflake Deployments, so teams on that model must assemble costs from other views.
What this means in practice: Teams need to account for more than connector runtime costs when estimating their monthly bill. Increased CDC volume, frequent warehouse merges, and additional infrastructure can all affect total spending. This makes cost forecasting more complicated, especially as new sources and pipelines are added.
Limitation 3: Naming decisions are set early and follow the source
Openflow lets you control destination schema names, but defaults come from the source, and the choice is made before the first snapshot.
- Configurable schema pattern. The SQL Server, PostgreSQL, MySQL, and Oracle connectors expose a Destination Schema Pattern parameter. A fixed name sends every table to one schema; variables build names from the source database and schema.
-
Defaults mirror the source. By default, SQL Server uses
<source_database>_<source_schema>and PostgreSQL uses the source schema name. - Table names follow the source. Snowflake's MySQL setup guide notes that destination objects are based on source schema and table names, so those names are not under your control and can change when the source changes. Snowflake also recommends a dedicated destination database per connector to avoid collisions.
What this means in practice: Teams with established Snowflake naming conventions need to plan their destination mappings before starting replication. Changing those mappings later may require additional configuration or migration work, potentially disrupting downstream queries and dashboards.
Limitation 4: Strict rules on schema changes, keys, and sources
Openflow's CDC connectors stop replicating a table when certain source changes happen. These rules are documented, but teams often discover them only in production.
| Limitation | Connectors affected | Source |
|---|---|---|
| Primary key changes and changes to numeric precision or scale are not supported; replication stops for the affected table | PostgreSQL, SQL Server | PostgreSQL docs, SQL Server CDC docs |
| Tables without a supported identity key replicate INSERTs only; UPDATEs and DELETEs need a key | PostgreSQL | PostgreSQL docs |
| Only username and password authentication to the source | SQL Server CDC | SQL Server CDC docs |
| CDC unavailable on SQL Server Express and Web editions, including Web edition on AWS RDS | SQL Server CDC | SQL Server CDC docs |
| Tables with data beyond Snowflake's type limits are not replicated (out-of-range dates excepted) | PostgreSQL | PostgreSQL docs |
SQL Server also has two separate Openflow connectors, and the choice affects what you capture. The Change Tracking connector polls for changed rows, so multiple updates to one row between polls arrive as a single change. The CDC connector captures every row-level change from the transaction log, but it requires SQL Server Agent and the Standard or Enterprise edition.
In fairness, Openflow handles common changes such as adding and dropping columns, and recent releases improved how failures surface. For example, the SQL Server CDC connector now moves tables to FAILED state on unsupported DDL instead of retrying indefinitely. Fixing a failed table, though, typically means removing it from replication and re-snapshotting it.
What this means in practice: Routine source changes, such as altering a primary key or widening a numeric column, can stop replication for a table. Coordinate DDL changes with the source database team, test them in a staging pipeline first, and keep a documented re-snapshot procedure ready for tables that fail.
Limitation 5: Failures need deliberate alerting
When something outside the connector breaks, Openflow pipelines can fail quietly. Snowflake's PostgreSQL documentation notes that the runtime canvas shows only current table status, not status changes; changes are recorded in logs.
A post-mortem published on r/snowflake shows how this can play out. The figures below are as reported by the team:
- A team upgraded its Openflow runtime from Small to Medium but kept a 25-credit monthly resource monitor on the connector's warehouse.
- The monitor suspended the warehouse on a Friday. The PostgreSQL CDC connector kept retrying its merges, up to its default of 10,000 retries per table.
- Over roughly 39 hours, more than a million rejected queries ran up cloud services charges that the team said far exceeded the monitor's whole quota.
- The tables moved to FAILED status without an alert. The team found four days of missing data on Monday, from stale dashboards.
- Recovery required a full re-snapshot of every affected table, which took several hours.
The trigger was the team's own undersized resource monitor, which they acknowledged. The lesson is that retry behavior plus unconfigured alerting turned a configuration mistake into a multi-day data outage. An Openflow product manager replied that Snowflake is changing how connectors behave when the warehouse is unavailable, so check the version history for that fix before treating this as current behavior.
Openflow does provide alerts for data staleness and queue buildup through its observability dashboard. The takeaway is to configure them, and to use resource monitors that notify rather than suspend for critical CDC warehouses.
What this means in practice: Without properly configured alerts, a failed replication task may go unnoticed until someone discovers stale data in a dashboard or report. Teams need to monitor pipeline health, configure failure and freshness alerts, and establish recovery procedures to prevent small issues from becoming extended outages.
Limitation 6: NiFi complexity and two generations to manage
The most common complaint about Openflow is that it exposes Apache NiFi concepts that many data teams have never used. In Gen 1, connectors are installed and configured on a NiFi canvas of processor groups, controller services, and parameter contexts. Users across r/snowflake and r/dataengineering describe the UI as confusing, say variables must be managed processor by processor, and note that people experienced with NiFi are harder to hire than dbt or Spark engineers.
Gen 2 addresses much of this, but the transition is only partly complete:
- Mixed maturity. Gen 2 deployment and runtime objects are generally available on AWS, Azure, and GCP. Gen 2 connector configuration, including the setup wizard and the PostgreSQL and MySQL/MariaDB CDC connectors, is still in public preview.
- Gen 1 is being phased out. Snowflake retired Gen 1 deployment creation on September 9, 2026, and migration of existing Gen 1 deployments to Gen 2 became generally available on October 1, 2026.
- Canvas-based connectors remain. Gen 2 runtimes run both Gen 1 and Gen 2 connectors. Connectors without a Gen 2 version yet, such as SQL Server and Oracle, are still configured as Gen 1 connectors.
- Two sets of objects. Gen 1 and Gen 2 use different SHOW commands, so a Gen 2 runtime does not appear in Gen 1 listings. Several users hit this when testing Gen 2.
- Object limits. Snowflake notes that GRANT OWNERSHIP on Gen 2 objects can break underlying functionality, and that CLONE and CREATE OR REPLACE aren't supported.
This is also Snowflake's second approach to PostgreSQL ingestion. Its earlier native connector's documentation now says Snowflake is focused on a next-generation solution, Openflow. Teams adopting Openflow today should plan for further migration work as Gen 2 matures.
What this means in practice: Teams using Gen 1 may need to learn NiFi-specific concepts to troubleshoot or customize pipelines. Moving to Gen 2 can simplify routine setup, but teams still need to understand which connectors and capabilities are supported before planning a migration. This adds evaluation and operational work during the transition.
What Openflow Gen 2 fixes
Gen 2 removes the canvas from routine setup for supported connectors and makes Openflow manageable as code. The generally available parts are deployment and runtime SQL objects. The connector-level features below are in public preview, according to Snowflake's Gen 2 release notes and the Openflow product team:
- Connector configuration is versioned, so teams can commit, roll back, and promote changes across environments with Git.
- Supported connectors use a guided setup wizard instead of the canvas, and Snowflake's Cortex Code assistant can configure them conversationally.
- Connectors can be created and managed with SQL, which makes automation in CI/CD pipelines practical.
Some users report a smooth upgrade. The release history also shows steady work on Openflow, with updates through 2026 including SQL Server CDC reaching general availability in March 2026. Claims that Openflow has been abandoned are not supported by the release record.
Gen 2 does not change the underlying architecture, though. Runtimes, warehouse merges, and multiple cost meters remain, and Gen 2 connectors cover two sources so far.
When Openflow is a good fit
Openflow makes the most sense for teams that are fully committed to Snowflake and want ingestion inside the same platform and bill. It suits teams that:
- Need high-volume database replication where per-row pricing from other tools would be expensive. Several practitioners report that Openflow costs less than Fivetran for SQL Server at scale.
- Already have NiFi expertise or need custom flows, such as decryption, protobuf decoding, or unusual transformations in flight.
- Must keep data movement inside their own cloud network through BYOC.
- Can adopt Gen 2 and its supported connectors.
It is a weaker fit for teams that need one pipeline to feed several destinations, want sub-minute freshness without tuning warehouse merge costs, or lack the time to manage runtimes, sizing, and alerting.
How to evaluate Openflow in a proof of concept
Test these five things with your own tables before committing to any CDC tool, Openflow included:
- Runtime sizing: run peak-hour volume and confirm the runtime keeps up without a resize.
- Schema changes: add a column, drop a column, and change a primary key on a test table; note which ones stop replication.
- Freshness vs. cost: measure end-to-end latency at two merge schedules and record warehouse credits for each.
- Failure recovery: suspend the warehouse or revoke a permission, then time how long until someone is alerted and how long recovery takes.
- Monthly cost: add up every meter (runtime, warehouse, ingestion, telemetry, cloud infrastructure) for a full week and project it to a month.
Openflow vs. Estuary: side-by-side
Both tools replicate databases into Snowflake with CDC, and each has real strengths. Openflow's advantage is that it lives inside Snowflake: billing through Snowflake (plus your own cloud bill on BYOC), Snowflake governance, and NiFi's flexibility for custom flows. Estuary's advantage is that there is no infrastructure to size and loading is decoupled from capture.
| Snowflake Openflow | Estuary | |
|---|---|---|
| Where it runs | Inside your Snowflake account (Snowpark Container Services) or your own cloud (BYOC) | Estuary's managed cloud, or private and BYOC deployments |
| Billing | Through Snowflake credits on your existing bill; BYOC adds your cloud provider's bill | Separate vendor bill: $0.50 per GB moved plus a per-connector-instance fee; Snowflake warehouse costs still apply |
| Infrastructure to manage | Runtimes you size up front; database CDC connectors are single-node, and runtime size is fixed at creation | No runtimes to size |
| Connector setup | NiFi canvas (Gen 1); wizard or SQL (Gen 2 preview, PostgreSQL and MySQL only) | Web dashboard or flowctl CLI with YAML specs |
| Custom in-flight processing | Full NiFi processor library for custom flows, such as decryption or protobuf decoding | Derivations for real-time transformations |
| Freshness vs. warehouse cost | Merge schedule controls warehouse use | Sync schedule per materialization, with faster syncs on chosen hours or days |
| Destination schema | Configurable schema pattern; SQL Server default is <source_db>_<source_schema>
|
Schema and table set per binding |
| Destinations | Built for Snowflake | Snowflake plus warehouses such as BigQuery, Databricks, Redshift, and MotherDuck from the same captured data |
| Failure alerting | Staleness and queue alerts available through the observability dashboard; must be set up | Built-in alerts for task failures, stalled data movement, and idle tasks |
| How cost grows | Practitioners report it costs less than per-row tools for large SQL Server CDC | One published rate per GB moved, plus connector fees that halve after six connectors; Enterprise plans have scaled pricing. No runtime or telemetry meters to estimate. |
Comparison reflects public documentation as of October 26, 2026. Both products change often.
Alternatives to Snowflake Openflow
The right alternative depends on your sources, how fresh the data must be, and whether everything must stay on the Snowflake bill. These are the tools practitioners most often compare with Openflow:
- Fivetran, including HVR: mature managed connectors. Practitioners praise HVR's real-time replication metrics, while several say usage-based pricing gets expensive as volume grows.
- Estuary: managed real-time CDC that decouples capture from loading, described below.
- Airbyte: a large connector catalog, available open source or as a cloud service. Self-hosting means running the infrastructure yourself.
- Cloud-native services (Azure Data Factory, AWS DMS): a natural fit if you already run on that cloud. Practitioner reports on their CDC reliability are mixed.
Estuary
Estuary reads changes from the source's log, such as PostgreSQL logical replication or SQL Server CDC, and stores them in durable collections. It then writes them to Snowflake through a materialization that runs on its own schedule. Capabilities that relate to the limitations above:
- No runtimes to size or scale.
- Per-materialization sync schedule: sync continuously, every 15 minutes, or faster only during business hours. Estuary's docs note that slower syncs reduce destination compute costs.
- Built-in alerts: Data Movement Stalled, Task Failed, and Task Idle alerts can email a person, a list, or a Slack channel. By default, a task-failure alert fires after 3 failures in 8 hours.
- Destination control: you choose the Snowflake schema and table for each binding, and the same captured data can feed other destinations.
Estuary is a weaker fit if you need everything on a single Snowflake bill or rely on custom NiFi flows.
Next step: run the same PostgreSQL or SQL Server tables through both tools and compare freshness, setup effort, and total cost. Estuary's free tier includes 10 GB per month and 2 connectors. See Estuary plans and start a free trial.
Top comments (0)