Airbyte vs Fivetran: Connector Coverage, the Bill You Cannot Predict, and Who Fixes It at 2 a.m.

Every ELT evaluation I have sat through compared connector counts. Nobody has ever chosen correctly on that basis. A connector catalog of 400 sources is irrelevant when you need six of them and one of those six is a legacy ERP with a custom API.

The real comparison is a cost model you cannot fully forecast versus infrastructure you have to keep alive, plus one question people ask too late: when the connector silently stops emitting rows, who is responsible for noticing?

flowchart LR
  src["Sources: Postgres, Salesforce, Stripe, S3"] --> tool{ELT tool}
  tool -->|Fivetran| bill["Bill: monthly active rows"]
  tool -->|Airbyte OSS| ops["Ops: K8s, upgrades, on-call"]
  bill --> raw[Raw schemas in warehouse]
  ops --> raw
  raw --> dbt["dbt models (both paths)"]

Both tools stop at raw. The difference is which cost you prefer to carry.

The cost models, and why they surprise people

Fivetran charges on monthly active rows: distinct primary keys inserted, updated, or deleted in a month. The trap is that MAR counts rows changed, not rows you care about. A source table with a last_seen_at column that updates on every session will bill you its entire row count every month, forever, whether or not anyone queries it. I wrote up the specifics in Fivetran MAR, and the same post covers the second invoice everyone forgets: the warehouse credits Fivetran’s writes consume in your account.

Airbyte Cloud uses its own credit model that varies by source type, which is more predictable for high-volume database replication and less so for API sources.

Airbyte self-hosted has no license cost and a real operational one. You are running the platform on Kubernetes, upgrading it, sizing workers, watching sync pods, and owning the incidents. If your team already runs Kubernetes for data jobs, that marginal cost is genuinely low. If this would be your first cluster, price it honestly — it is not free, it is denominated in engineer-weeks.

The honest framing: Fivetran converts an engineering problem into a line item. Whether that is a good trade depends on what your engineers cost and whether the line item stays sane as volume grows.

Connector quality is bimodal in both products

For the top sources — Postgres, MySQL, Salesforce, Stripe, Shopify, NetSuite — Fivetran’s connectors are more mature. They handle schema drift, they resync sensibly, and the incremental logic has been beaten on by thousands of customers.

For the long tail, both products degrade, and Airbyte’s community connectors vary from excellent to abandoned. The advantage is that you can read the source, patch it, and build your own with the CDK. That advantage is only real if someone on your team will actually do it. I have watched teams choose Airbyte specifically for extensibility and then never write a connector, which leaves them with the operational burden and none of the upside.

The question to ask during evaluation is not “is this source supported” but “what happens when this source adds a column”. Schema drift handling is where connectors separate.

The failure mode that matters: a green sync of zero rows

Both tools will report success on a sync that moved nothing. The connector authenticated, the cursor did not advance, no rows were emitted, the job went green. Nobody is paged. The dashboard shows yesterday’s numbers and looks plausible for about four days.

This is the single most common ELT incident I have dealt with, and neither vendor solves it for you. I wrote the Airbyte version of this story in a successful sync of zero rows, and the fix is identical on Fivetran: a freshness test on the landed table, owned by you, in the warehouse.

-- The test that catches what the sync status does not.
-- Run it in dbt after every load; alert on failure, not on sync status.
select
    count(*)                                as rows_today,
    max(_airbyte_extracted_at)              as last_row_at,
    datediff('minute', max(_airbyte_extracted_at), current_timestamp()) as staleness_minutes
from raw.salesforce.opportunity
having
    rows_today = 0
    or staleness_minutes > 180

Every source table gets a freshness and volume assertion. That is not a nice-to-have you add later; it is the thing that makes managed ELT trustworthy. The data quality tools sheet covers where these checks belong, and fail the job or open a ticket covers what to do when one fires.

CDC changes the comparison

If your main requirement is replicating operational databases with low latency, evaluate both against a third option: running Debezium yourself.

Fivetran’s database connectors use log-based CDC and handle the replication slot, snapshot, and schema evolution well. This is where the product is strongest and where MAR pricing is most painful, because an update-heavy OLTP table is exactly the shape that maximizes billable rows.

Airbyte supports CDC through Debezium under the hood. It works, and you inherit Debezium’s operational reality — replication slot growth filling your primary’s disk if a sync stalls, snapshot behavior on large tables, and the idempotency requirements on apply. The CDC patterns sheet is the reference I keep open during those setups.

The uncomfortable middle: for two or three high-volume tables, hand-rolled CDC into Kafka is often both cheaper and more reliable than either tool. For thirty tables across five databases, it is not.

What neither tool does

Both land raw, vendor-shaped schemas in your warehouse. Neither one models your data. The Fivetran dbt packages and Airbyte’s basic normalization give you a starting point, and I have never seen either survive contact with actual business logic.

Plan for the full path: raw landing from the ELT tool, staging models that rename and cast, then marts. That is the dbt project structure conversation, and it is the same regardless of which tool you pick. If your evaluation does not include who writes those models, you have not scoped the project.

Pitfalls

Syncing every table because you can. Every table is MAR you pay for or a sync pod you operate, plus warehouse storage and a schema someone will eventually query by accident. Sync what is modeled.

Setting sync frequency by intuition. Hourly on a source nobody looks at before 9 a.m. is money for nothing. Match frequency to the downstream SLA.

Trusting the vendor dashboard as your monitoring. It reports its own job status, not whether data arrived. Test in the warehouse.

Self-hosting Airbyte on one VM with Docker Compose. It runs, and it will fall over on a large sync. If you self-host, do it properly on Kubernetes with resourced workers.

Assuming a migration between them is easy. The raw schemas, metadata columns, and cursor semantics differ. Every staging model you wrote is coupled to the tool that landed the data. Isolate that coupling in staging so a future migration is one layer, not fifty.

Ignoring the destination bill. Frequent small writes into Snowflake or BigQuery cost credits and create small files. That appears on your warehouse invoice, not the ELT one.

FAQ

Which is cheaper? Below a few hundred million monthly active rows with a small team, Fivetran usually wins on total cost once you price engineer time. Above that, or with an existing platform team, self-hosted Airbyte pulls ahead. The crossover is real and worth modeling with your own row counts before signing anything.

Can I use both? Yes, and plenty of teams do: Fivetran for the critical SaaS sources where reliability is worth the premium, Airbyte or custom extractors for internal and long-tail sources. Keep the raw schema conventions identical so downstream models do not care.

What about Meltano, dlt, or Estuary? dlt in particular is worth evaluating if your team writes Python comfortably — it is a library, not a platform, so there is nothing to operate and the extractor lives in your repo next to your DAGs. For a handful of sources it is frequently the lowest-total-cost option.

Do I still need an orchestrator? Yes. Both tools can schedule syncs, but you need the load to complete before dbt runs. Trigger syncs from Airflow or Dagster and build the dependency explicitly, or use dataset-aware scheduling.

How do I stop MAR from growing? Drop columns that update constantly and nobody uses, exclude tables you do not model, and reduce sync frequency on low-value sources. MAR is a function of what you choose to replicate, which is the one lever entirely under your control.

What this means for data engineers

Pick on operations, not connectors. If you have no platform team, buy the managed product and spend the saved time on modeling — that is where the value your business sees is actually created. If you already run Kubernetes and have someone who will maintain connectors, self-hosted Airbyte is a genuine cost advantage rather than a spreadsheet fantasy.

Whichever you choose, own the verification yourself. A freshness and volume test on every landed table, alerting to your on-call, is what turns either tool into something you can trust. The green checkmark in the vendor UI is a statement about their job, not about your data.