NEW: Scale AI Case Study — ~1,900 data requests per week across 4 business units Read now →
Contents
Fivetran
Fivetran is the dominant managed-connector service for moving data from SaaS apps and databases into cloud data warehouses. Founded in 2012, it pioneered the ELT pattern and made pipeline maintenance somebody else's problem.
Fivetran is the company that turned data ingestion into a managed service. Founded in 2012 by George Fraser and Taylor Brown, Fivetran's pitch was almost provocatively simple: stop building and maintaining pipelines yourself. Pay Fivetran to keep ~700 connectors working with the APIs of Salesforce, HubSpot, Stripe, NetSuite, Postgres, and everything else, and never read another "Salesforce field type changed" error log again.
Plain English: Fivetran is a service that copies your data from wherever it lives into your warehouse, and keeps it copied as the source data changes. You click "connect Salesforce," authenticate, choose a destination schema in Snowflake, and within an hour you have every Salesforce object as a table in your warehouse, refreshing on a schedule you set. No code. No DAG. No maintenance.
Fivetran was not originally an integration company. George Fraser (a PhD biologist by training) and Taylor Brown started in Y Combinator's S12 batch building an analytics product — a kind of in-browser BI tool. To make the BI tool work, they had to write connectors to pull data from their customers' source systems. The connectors ate their entire engineering budget. Every Salesforce API change broke things. Every customer wanted a new source. The actual analytics product was almost an afterthought.
By 2015, the founders made the decision that changed the company: kill the BI product and sell the connectors. It was a counterintuitive move because the conventional wisdom was that connectors were a commodity — table stakes, not a product. Fraser disagreed. He believed connectors were unbelievably hard to do well at scale, that nobody else wanted to do them, and that a managed service with a ruthless commitment to "no transformation" could become indispensable infrastructure.
The bet worked. Fivetran caught the cloud-warehouse wave (Redshift, then Snowflake, then BigQuery) and grew into the default ingest layer for the modern data stack. By 2021 it had raised $565M at a $5.6B valuation and acquired HVR for $700M to bolt on real-time database change-data-capture (CDC) — the one area where Fivetran's polling-based connectors were weak.
The phrase "Fivetran killed ETL" is a meme in the data community, and like most memes it's half-true. ETL workloads still exist. Informatica is still a public company. But Fivetran killed the idea that extraction and transformation belong in the same product.
Fivetran's founding insight was that transformation is a separate problem with separate users. Data engineers want extraction to be reliable, schema-aware, and incremental. Analysts want transformations to be in SQL, version-controlled, and testable. Putting both in the same proprietary tool (the Informatica model) made both groups miserable. By doing only EL and explicitly leaving T to other tools (eventually dbt), Fivetran could focus obsessively on connector quality and let the transformation layer evolve independently.
This was the architectural decoupling that created the modern data stack as we know it. Fivetran handles ingest. dbt handles transform. Snowflake/BigQuery/Databricks handle compute. Each component is best-in-class because no single vendor is trying to do everything. Fivetran's success was the proof point that the unbundled stack worked.
A Fivetran "connector" is not a thin API wrapper. For a high-traffic source like Salesforce, the connector is a substantial piece of engineering: schema discovery, type mapping, incremental sync via change tracking or polling, deleted-row handling, custom-field handling, rate-limit backoff, error recovery, and historical re-syncs. Fivetran maintains a team of engineers per connector category whose only job is to keep these working as upstream APIs change.
Beyond connectors, the product includes:
dbt_fivetran_log, salesforce__source, etc.Every honest article about Fivetran has to talk about the price. Fivetran charges based on monthly active rows (MAR) — distinct primary keys that change in a given month. The pricing is opaque, the MAR meter is hard to predict, and many teams have stories of bills that 3x'd overnight when a junior engineer enabled a high-volume connector or when an upstream system started dirty-flagging more rows.
Fivetran's defense is that managed pipelines are valuable and the price reflects that value. This is true, until your CFO sees a $40,000 monthly invoice for moving Salesforce tables that haven't changed. Pricing surprises are the single biggest reason teams switch off Fivetran — usually to Airbyte, occasionally to a custom solution, occasionally back to Fivetran six months later when they remember why they paid in the first place.
Fivetran is the gold standard for managed connectors. Their connector quality, particularly for the heavyweight ones (Salesforce, NetSuite, SAP, Oracle, HubSpot), is genuinely best-in-class. For mid-market and enterprise teams who would rather pay than maintain, there is no real competitor on quality.
The threats are mostly economic. Airbyte undercuts on price with an open-source model and a thriving connector contributor base. Native warehouse ingestion — Snowflake's connectors, Databricks Lakehouse Federation, BigQuery Data Transfer Service — chips away at the edges. The big cloud providers (AWS Glue, Azure Data Factory, Google Datastream) don't have Fivetran's polish but are bundled with the bill you're already paying.
What Fivetran owns, decisively, is the buyer who values their data engineers' time more than their AWS bill. As long as that buyer exists — and they always will — Fivetran will be fine. The interesting question is whether, in a world of cheap LLM-generated code, the difficulty of building a connector goes from "needs a team of specialists" to "spend an afternoon with Claude and ship it." If that happens, Fivetran's moat shrinks. There is no public sign of it shrinking yet.
TextQL doesn't connect to Fivetran directly — it connects to the warehouse Fivetran loads into. But the Fivetran-shaped raw schemas matter a lot for AI accuracy. Fivetran's pre-built dbt packages turn raw connector tables (Salesforce custom fields, weird HubSpot enums, NetSuite multibook ledgers) into clean, documented staging models that TextQL Ana can read with much higher confidence than the raw tables. If you run Fivetran + dbt + a warehouse, you have given TextQL the exact substrate it needs to answer business questions accurately in natural language.
See TextQL in action