ELT Connector Quality and Coverage Comparison

Raw connector counts are a misleading way to evaluate ELT tools. Fivetran lists 700+, Airbyte lists 600+, dlt lists 60+. These numbers don’t tell you much until you understand the quality model behind each.

The Three Coverage Models

The numbers look very different, but the practical coverage for common use cases converges faster than you’d expect. All three support the major sources: Google Ads, Meta/Facebook Ads, GA4, HubSpot, Salesforce, Shopify, and most mainstream SaaS platforms.

Where they diverge is in the long tail and in edge cases within popular connectors.

Fivetran: Connectors as a Product

Fivetran’s connectors aren’t features — they’re the product. Each one is built and maintained by Fivetran’s own engineers, who track API versions, handle breaking changes, and support customers when something breaks.

This has a concrete implication: when Google Ads releases a new API version and deprecates the old one, Fivetran handles the migration. You get an email notification. You don’t need to update code. When Meta restructures their Ads Insights API (something they do with some regularity), Fivetran updates the connector before the deadline.

The quality floor for Fivetran connectors is high precisely because they’re commercial products with SLAs attached. A broken connector is a support ticket, a potential SLA violation, and a reason a customer might churn. That commercial pressure produces consistently maintained connectors.

The limitation: you get what Fivetran built. You can’t modify connector behavior, add fields they don’t extract, or change the schema they produce. You work within their model.

Airbyte: Two Tiers of Quality

Airbyte’s connector catalog has two tiers that behave very differently.

Official connectors (roughly 350) are maintained by Airbyte’s engineering team. For the major sources — Google Ads, Meta Ads, Salesforce, HubSpot, Stripe — official connectors are production-quality and track API changes reliably. These connectors are what Airbyte’s commercial offering is built around.

Community connectors are contributed by third parties and vary in quality from production-ready to effectively unmaintained. Some are actively maintained by vendors building on Airbyte’s ecosystem. Others were contributed once and haven’t been touched since the source API changed.

The practical implication: before relying on a community connector for production data, investigate its maintenance history. When was it last updated? Does it track recent API changes? Are there open issues about known failures? A community connector with 200 GitHub stars and recent commits is very different from one with 3 stars and a two-year-old last commit.

Community feedback from r/dataengineering and dbt Slack confirms this pattern. Airbyte’s official connectors are generally solid; complaints cluster around reliability issues with community-maintained connectors.

dlt: Build Your Own, Fast

dlt takes the most different approach. Instead of trying to maintain a large pre-built connector library, it provides a framework for building connectors quickly and a verified catalog of 60+ commonly-used sources.

The REST API builder is the key tool. Point it at an API’s documentation (or provide the spec directly), and you can generate a working pipeline for almost any REST API. In September 2024, users created 50,000 custom connectors using this approach — a 20x increase from January 2024. That number tells you the REST API builder actually works as advertised.

import dlt
from dlt.sources.rest_api import rest_api_source

# Generate a pipeline for any REST API by describing its structure
source = rest_api_source({
    "client": {
        "base_url": "https://api.your-source.com/v1",
        "auth": {
            "type": "bearer",
            "token": dlt.secrets.value
        }
    },
    "resources": [
        {
            "name": "records",
            "endpoint": {
                "path": "records",
                "paginator": {
                    "type": "cursor",
                    "cursor_path": "next_page_token",
                    "cursor_param": "page_token"
                }
            }
        }
    ]
})

The AI-assisted workflow makes this practical: give an LLM the API documentation and dlt’s REST API reference, ask it to generate the configuration, and you have a working pipeline in minutes. See dlt Custom API Pipelines for the full pattern.

The trade-off with dlt’s approach: you’re responsible for maintenance when source APIs change. dlt handles schema evolution automatically (new fields get added to your warehouse tables without manual intervention), but if an API endpoint changes its URL structure or authentication method, you update your code. For sources where you’re already building something custom, that’s acceptable — you own it. For sources where you wanted a hands-off managed connector, it’s not.

The Marketing Data Edge Case

Marketing data is where connector quality differences are most consequential.

All three tools have connectors for the major ad platforms. But marketing data has specific characteristics that stress-test connector quality:

• Retroactive metric updates: Meta and Google regularly revise performance metrics over 3-7 day windows as attribution solidifies. A connector that snapshots rather than refreshes historical data will show stale numbers.
• API versioning: Ad platforms release new API versions with some regularity and deprecate old ones. A connector that doesn’t track API versions proactively breaks when the old version sunsets.
• Granularity limitations: Some connectors expose only campaign-level data when you need ad-set or ad-level granularity for meaningful optimization analysis.

Fivetran’s connectors handle these edge cases well because they’re commercial products with paying customers reporting issues. Airbyte’s official Google Ads and Meta connectors are solid; community connectors for smaller platforms are more variable. With dlt, you define exactly what you extract and at what granularity — which means you handle these edge cases in code, but you get complete control over how they’re handled.

Schema Change Handling

All three tools handle schema evolution — new fields appearing in source data — but with different approaches.

Fivetran automatically propagates schema changes with configurable handling. Removed columns get soft-deleted rather than dropped. Data type changes create new columns. You choose between Allow All, Allow Columns, or Block All modes.

Airbyte offers configurable schema propagation with column selection. You can choose which new columns to propagate.

dlt provides schema_contract options on each resource:

@dlt.resource(schema_contract={"columns": "evolve"})
def campaigns():
    yield from get_campaigns()

The evolve setting auto-adapts the destination schema. The freeze setting stores unexpected changes as JSON without modifying your warehouse tables. Most production dlt pipelines use evolve during development and tighten to freeze once the schema stabilizes.

The Practical Decision

Connector coverage is table stakes for the major sources — all three tools cover them. The real decision factors are:

• Need for a specific niche connector: Fivetran’s 700+ catalog is the widest, and the connectors are professionally maintained. If you need Zendesk, Jira, NetSuite, and fifteen other standard SaaS tools reliably, Fivetran’s breadth is a genuine advantage.
• Tolerance for community connector quality: Airbyte’s 600+ number includes connectors you shouldn’t use in production without vetting. The count is real; the quality is not uniform.
• Willingness to build: dlt’s 60+ verified sources plus the REST API builder is sufficient for teams that can and will build connectors for the remaining sources. The question is whether your team has Python proficiency and the time to own that code.