What an ELT Stack Really Costs: Fivetran, Airbyte, dbt

Most data teams budget for the warehouse and discover later that the pipeline feeding it costs as much. Ingestion and transformation vendors have quietly become the second-largest recurring line in the modern data stack, and unlike warehouse compute — which spikes and recovers — pipeline cost grows monotonically with the business. Every new source system, every new row, every new model build adds to a bill that rarely shrinks.

This article explains how the three dominant meters work: Fivetran’s monthly active rows, dbt’s per-seat and per-build model, and Airbyte’s credit-based structure. It then builds a realistic mid-market budget, identifies where costs inflate, and sets out when building in-house genuinely beats buying.

Three vendors, three completely different meters

Fivetran bills by monthly active rows (MAR). A row is counted as active in a given month if it was inserted, updated or deleted. Fivetran’s documentation states that a $5 base charge now applies to all standard connections generating between 1 and 1,000,000 MAR per month, a change effective from 1 January 2026 (Fivetran usage-based pricing). The practical consequence is that many small connectors which previously rounded to near-zero now each carry a minimum charge, so connector count itself has become a cost variable.

dbt bills by seat, with usage allowances per tier. The Developer plan is free for a single developer, and the Starter tier is listed at $100 per seat per month, including a monthly allowance of successful model builds and a single project (dbt pricing). Enterprise pricing is negotiated. Because dbt Cloud orchestrates jobs that consume warehouse compute, the visible subscription is often smaller than the warehouse cost those jobs trigger — a coupling that surprises teams migrating from cron-based scheduling.

Airbyte prices on credits. Its open-source connectors can be self-hosted at infrastructure cost, while the managed cloud product meters credits against sync volume and frequency. Exact credit-to-row ratios and plan inclusions change frequently, so any figure here would be stale by the time you read it; request a current quote mapped to your specific connector list rather than relying on comparison articles.

The comparison that matters: what each meter responds to

The strategic implication: MAR-based pricing is generous for narrow tables synced hourly and expensive for wide, frequently updated tables. A 40-column customer table with 200,000 rows updated three times a month counts as 600,000 MAR; a 4-column status table with the same row count and update pattern counts identically. Column width is free; update frequency is not.

A worked mid-market budget

Consider a 300-person company with 45 source connectors, roughly 12 million MAR across standard connectors, nine analytics engineers and four production dbt projects running 300 model builds per day.

Only the dbt seat line is a clean list-price calculation. That asymmetry is the central point: ingestion pricing is negotiated and volume-tiered, so the only reliable budget is a vendor quote built from your actual connector inventory and 90-day row counts.

Where pipeline costs inflate

Full re-syncs after schema drift. A single failed sync followed by a full historical reload can add tens of millions of MAR in one day. Connectors without schema-change handling are the most common cause of a billing spike that appears with no corresponding business growth.

Sync frequency without business justification. Moving a connector from 15-minute to hourly syncs rarely changes a dashboard’s usefulness but often reduces cost materially. Audit frequency against the actual refresh expectation of the consuming report.

Wide, update-heavy tables. Because MAR counts updates, a table with soft-deleted records or frequently recalculated columns generates active rows on every touch. Normalizing such tables, or excluding volatile columns from the sync, reduces both volume and warehouse merge cost.

Connector sprawl. With a per-connection minimum now in effect on standard Fivetran connections, dozens of low-traffic connectors (a Slack export, a small marketing tool) contribute a fixed floor to the bill regardless of data value. Consolidating them behind a single database extraction or retiring them is straightforward savings.

Model build proliferation. dbt projects accumulate models that nobody queries. Each build consumes warehouse compute and, on usage-limited tiers, counts against allowances. A monthly “unused model” review — cross-referencing warehouse query logs against the dbt manifest — keeps build volume aligned with demand.

Orchestration overlap. Running Airflow, dbt schedules and Fivetran’s own scheduling simultaneously creates duplicate runs and conflicting freshness guarantees. Pick one orchestrator of record.

Build versus buy, honestly assessed

Self-hosting open-source connectors looks cheaper on a spreadsheet and often is not. The true comparison is license or infrastructure cost plus engineering hours for connector maintenance, schema-change handling, retry logic, credential rotation and monitoring, multiplied by your fully loaded engineering rate.

As a rough decision rule: if your team maintains fewer than about fifteen connectors and data freshness tolerates daily syncs, self-hosting is usually economical. Above roughly thirty connectors, or where freshness requirements are measured in minutes, the maintenance burden generally exceeds the subscription unless you already employ dedicated pipeline engineers.

A middle path is common and underrated: managed ingestion for revenue-critical systems, self-hosted connectors for internal or low-volume sources, and a single transformation layer on top. This keeps the MAR meter pointed at data that actually matters.

Five cost controls that work

1. Inventory every connector with its 90-day row count and sync frequency. Most teams find two or three connectors responsible for the majority of MAR.
2. Set sync frequency from the consuming report, not from connector defaults.
3. Exclude volatile, unused columns from high-update tables before they reach the MAR meter.
4. Retire or consolidate low-value connectors that now carry a per-connection minimum.
5. Review dbt model usage monthly and deprecate models with no downstream queries.

Common mistakes

Assuming ingestion cost scales with storage rather than with row changes; budgeting only the subscription and forgetting the warehouse compute that dbt jobs trigger; signing multi-year ingestion commitments before instrumenting actual MAR; and treating connector count as free.

Conclusion

The ELT stack is now a three-meter problem, and each meter responds to a different engineering decision. Fivetran’s MAR meter rewards narrow, infrequent updates and punishes connector sprawl. dbt’s seat meter rewards small teams and shifts cost into warehouse compute. Airbyte’s credit meter sits between the two and depends heavily on connector choice.

Instrument your actual row-change volume for 90 days, map it to a vendor quote, and model the warehouse compute your transformation layer will consume. That three-part model is the only budget that survives contact with production.

Sources

• Fivetran usage-based pricing documentation
• Fivetran pricing page
• dbt Labs pricing
• dbt billing documentation
• Coupler: Fivetran pricing analysis