Openflow and dlt on Snowflake: which to use when

We first compared Openflow and dlt in October 2025. This is the 2026 update, and the comparison looks quite different, because Openflow has improved a lot in the last year.

TL;DR

• Openflow covers the short tail, maintained by Snowflake. A GA catalog of 43 connectors and variants across 26 sources: the most widely used databases, business applications, streams and document stores. Snowflake owns the connector; you configure it from Snowsight, the NiFi canvas or Cortex Code.
• dltHub covers the long tail, owned by you. Connectors that coding agents assemble from dltHub's maintained context for 10,000+ REST APIs and from verified sources. The code lives in your repo; agents write most of it.
• Both land data in Snowflake. They are two different paradigms for two different parts of your source list, so running both is the normal setup, not a compromise.

Two paradigms: pre-baked vs. assembled connectors

Openflow and dltHub sit at two ends of the same spectrum: pre-baked connectors versus connectors you assemble. Both start from a curated, maintained base. They differ in who finishes and owns the connector.

Openflow is a pre-baked connector catalog that you can’t beat on convenience. Snowflake builds, tests and maintains connectors for the sources most companies share: the big databases, CRMs, HR systems, ad platforms, event streams and document stores. It is the most common “short tail” of the source list, and for those sources a maintained, ready-to-deploy connector is the right answer.

dltHub is a maintained kit you assemble from. Instead of a fixed list, dltHub maintains the parts: source references and patterns for 10,000+ REST APIs in the dltHub context index, verified sources maintained by dltHub and the community, and skills that teach coding agents how to use them. The agent assembles the connector, your team reviews it, and the result is plain Python code that you own and can change. It covers the long tail: the sources only your company, or your industry, uses.

Owning the code used to mean owning the maintenance bill. dlt and dltHub automate much of that maintenance:

• Low total cost of ownership. With agents, a new custom connector typically reaches production in about a day, and dltHub's managed infrastructure runs it, so a long-tail source no longer costs an engineer's week to add or a platform team to host.
• High reliability. Agent-built pipelines follow dlt's conventions for credentials, incremental loading and schema handling, and we measure how well agents do it rather than assume.
• Maintenance by background agents. When a job fails, a verified background agent (in preview) diagnoses it read-only, within guardrails you set, and hands your team the cause with evidence.

What Openflow helps you do: 43 connectors conveniently maintained by Snowflake

Openflow covers the first four groups in the list: Postgres, Salesforce and Workday, Kafka, and SharePoint. These are the widely used systems where a connector maintained by Snowflake is exactly what you want. Its GA catalog has 43 connectors and variants.

• Replicate databases continuously. CDC from PostgreSQL, MySQL, SQL Server, Oracle and MongoDB into Snowflake tables, plus incremental replication from Google BigQuery. Nobody on your team writes replication code.
• Bring in core business applications. Salesforce, Workday, HubSpot, Microsoft Dataverse (Dynamics 365), Jira Cloud, Shopify, Slack and Veeva Vault, plus the major ad platforms: Google, Meta, LinkedIn and Amazon Ads.
• Stream events. Kafka and Amazon Kinesis flow in for near real-time analytics, and Snowflake tables can be streamed back out to Kafka.
• Feed documents to Cortex. SharePoint, Google Drive and Box content is ingested and made ready for chat in Cortex AI assistants, so the assistant can search and cite it.
• Run it all inside Snowflake. Deploy on Snowpark Container Services in AWS, Azure or GCP, or bring your own cloud on AWS with Snowflake running the control plane. Operate it from Snowsight, drop into the NiFi canvas when you need to, or work conversationally through Cortex Code and its Openflow skill. Monitoring runs on Snowsight and Snowflake event tables, flows are versioned in Git, and Snowflake roles govern access, so security and governance stay Snowflake-native.
• Build custom flows when you need them. For a source outside the catalog, you can build a custom flow from NiFi processors and controller services, and Cortex Code's Openflow skill helps you author it.

Winner: core systems that need a dependable, maintained connector. Log-based CDC is hard to get right and tedious to keep right; it belongs with the vendor.

Follower: custom sources. Custom Openflow flows are possible, but they mean working with NiFi processors and controller services. For custom extraction in Python, dlt is the lighter option. The same applies to sources whose shape doesn't match a catalog connector's assumptions (more on that below).

What dlt helps you do: 10,000+ REST APIs and any source you can code

dlt covers everything the catalog doesn't: here, the billing API, the niche SaaS tool, the internal pricing service and the partner's SFTP drop. Every company has dozens of these, and no connector catalog will ever list them all.

• Reach any source, in code. REST APIs, internal services, file systems, legacy databases and industry systems like Epic, Temenos Transact or Murex, loaded into Snowflake with schema inference and evolution handled for you. dlt doesn't wait on a vendor's connector catalog.
• Put business logic at extraction. Incremental loading, flattening nested JSON, schema contracts, PII masking before data lands. A few lines of Python, reviewed in a pull request.
• Keep changes reviewable for regulated data. Every pipeline change is code: reviewed in a pull request, versioned in Git and deployed the same way each time. For GxP-style environments that need to show what changed, who approved it and when, that record comes from the workflow itself.
• Build with coding assistants. Coding agents like Claude, Codex or Cursor write and deploy dlt pipelines. dlt was built for this workflow early, and it is still where dlt leads. The dltHub AI Workbench gives agents the skills and rules to do it the right way, and the dltHub context index covers 10,000+ REST APIs. Where this is heading: the autonomous data platform.
• Run and maintain them on dltHub. dltHub provides managed infrastructure for dlt pipelines on top of Snowflake, with alerts, CI workflows and performance tuning, under SOC 2 controls. Background agents (in preview) diagnose failed jobs read-only, within guardrails you set, and hand you a diagnosis with evidence. Pipelines can also run in any Python environment or orchestrator you already use.

Winner: the long tail. Sources that matter to the business but would never justify a vendor-maintained connector, now cheap enough to build and maintain that you can cover all of them.

Follower: Comes with an ownership cost, your team owns the code. Where a catalog connector fits your source as it is, a connector maintained by Snowflake is the better default. dltHub helps you minimize the cost of ownership but nevertheless it remains yours.

How they fit together

Catalog sources go through Openflow, everything else goes through dlt, and both land in the same Snowflake account. Teams downstream work in one set of databases, governed by one set of roles.

In practice:

1. Start with the Openflow catalog. If your source is there and the connector does what you need, use it.
2. For anything not covered, build it with dlt. Point a coding agent at the API docs and review the pipeline it writes like any other pull request.
3. Land both in the same databases and schemas, governed by the same Snowflake roles, so transformations and Cortex use cases treat all of it the same way.

Pick by source, not by tool

Openflow and dlt don't compete for the same sources, and they suit different operating models. Openflow fits teams that want to define and deploy connectors, and teams that need Snowflake's own integration, security, governance and operations. dlt fits code-first teams that keep pipelines in Git and build them with coding assistants. Together they get all of a company's data into Snowflake, which is what the assistant, the dashboards and the people using them need.

dltHub is the 2026 Snowflake Startup Program Product Partner of the Year. As of October 2026, over 1,500 companies use dlt to load data into Snowflake, across financial services, healthcare and life sciences, manufacturing and technology. Flatiron Health uses dlt in its privacy-first healthcare data processing, and Stellantis runs 60,000 Snowflake pipelines a month on dlt.

If the catalog has your source, let Snowflake own it. If it doesn't, own it yourself and let the agent write it.

Try dltHub and tell us what we should build next.

Paste this prompt into Claude, Codex, or Cursor: “Run uvx dlthub-start@latest to build my first pipeline and run it on dltHub”

Or book a demo!