Custom Fivetran connector vs Airbyte vs building it yourself
Check whether a native connector already covers the objects you need, because that is cheapest by a wide margin. If not, build a custom Fivetran SDK connector when you already run Fivetran and want the source monitored alongside everything else. Choose Airbyte when you want open source or self-hosting, and build your own only when the source is odd enough that neither framework helps.
The options
Custom Fivetran SDK connector
A connector written in Python against the Fivetran Connector SDK, running inside your existing Fivetran account.
- Teams already running Fivetran for other sources.
- Wanting one place to monitor syncs, schedules, and failures.
- Getting scheduling, retries, state, and destination handling from the platform.
- Sources with no native connector but a workable API.
- You do not use Fivetran and would be adopting it for this one source.
- The pricing model does not suit the volume of change in this source.
- You need the connector to run somewhere Fivetran cannot reach.
Airbyte connector
An open-source connector, self-hosted or on Airbyte Cloud, built with their connector development kit.
- Teams already running Airbyte.
- Requirements that push toward self-hosting, including data residency.
- Wanting to modify an existing community connector rather than start over.
- Preferring open source and avoiding platform lock-in.
- Self-hosting means operating infrastructure nobody has time for.
- You are already on Fivetran and would be running two ingestion tools.
- The community connector for your source is unmaintained, which is worth checking.
Build the pipeline yourself
Your own extraction code, orchestrated in Airflow or similar, writing directly to the warehouse.
- Sources so unusual that neither framework model fits.
- Extraction needing substantial transformation before it can land.
- Teams with strong data engineering capacity and a reason to own it fully.
- One small source where adding a platform is disproportionate.
- A framework would have handled state, retries, and schema drift for you.
- You are underestimating the work, which is the usual failure here.
- Nobody will own it once the person who wrote it moves on.
How to decide
| If this is true | Pick |
|---|---|
| A native connector covers the objects you need | Use it. Stop here |
| Already on Fivetran, no native connector | Custom Fivetran SDK connector |
| Already on Airbyte, or need self-hosting | Airbyte connector |
| Source needs heavy transformation before landing | Your own pipeline |
| No ingestion platform yet and several sources coming | Pick a platform first |
What we actually think
The work is roughly the same whichever you choose, because the hard parts belong to the source API: pagination, rate limits, incremental state, and schema drift. Frameworks save you the scheduling and destination plumbing, which is real but is not the expensive part. Anyone quoting a custom connector without reading the API docs first is guessing.
Common questions
How do we know if a native connector really covers our source?
Check the objects, not just the platform name. A native connector may support a vendor while omitting the specific endpoints or custom fields you need. Read the connector schema documentation before assuming it is covered.
Is a custom connector hard to maintain?
It is production software and needs the same care as any other: tests, a runbook, and someone who owns it. Built well, it is quiet. The maintenance that does arrive comes from the source API changing, which no approach avoids.
Can we move between these later?
The extraction logic transfers reasonably well since it is mostly about the source API. The framework wrapping and state handling do not. Migrating is real work but not a rewrite from zero.
Still not sure which fits your case?
Describe the workflow and the constraints. You will get a straight recommendation, including the one where you do not hire us.