Airbyte OSS vs. Managed Ingestion: A Practical Guide to Pros and Cons
Running Airbyte OSS seems free, but it costs you in maintenance. See the real pros and cons and when it's time to switch to managed ingestion, featuring the Brick Seguros case study.
![[Airbyte OSS] Blog Header](https://framerusercontent.com/images/ehIqnj3yN2Kquz3eOClltXRja64.png?width=998&height=360)
![[Airbyte OSS] Blog Header](https://framerusercontent.com/images/ehIqnj3yN2Kquz3eOClltXRja64.png?width=998&height=360)
![[Airbyte OSS] Blog Header](https://framerusercontent.com/images/ehIqnj3yN2Kquz3eOClltXRja64.png?width=998&height=360)
What "free" really means in Airbyte OSS (Open Source)
Running Airbyte OSS (Open Source) doesn't cost license fees. That's true. But data ingestion was never just about running pipelines; it's about pipelines running reliably, with complete data, every single day, without someone babysitting them. That part has a cost, it just doesn't show up on a monthly bill. It shows up in hours.
Before deciding between hosting it yourself or hiring a managed solution, it's worth understanding exactly what's at stake on both sides.
The pros of running Airbyte OSS
Zero license cost. For those on a tight budget with someone available to manage the infrastructure, this is a strong argument.
Control over where to host. You choose the cloud provider or server, but that comes with a requirement: Airbyte is built to run on Kubernetes. Even the simplest local installation (via
abctl) spins up a Kubernetes cluster under the hood. There is no way to bypass this layer; you can only decide where it runs.Active community and open-source connectors. Most of the common connectors already exist, maintained by those who use them.
The cons that appear after pipelines are in production
Maintenance is not optional. An API changes a field, a schema changes format, and someone on your team needs to notice, fix, and backfill. This doesn't happen once; it happens every time a source changes something.
Official maintenance only covers a fraction of the connectors. The rest relies on community contributions—meaning, the users. If the connector you need is not in this officially maintained core, the responsibility of maintaining, updating, and fixing it falls on your team.
Self-hosted infrastructure needs ownership. Server uptime, monitoring, alerting, scaling. This isn't a weekend hobby; it's recurring work.
The cost shows up in the people you least want wasting time on this. Usually, it's your most senior engineer, or the technical founder, troubleshooting incidents at 10 PM instead of doing the work only they can do.
How to know if your company is ready to self-host
A simple question resolves most of the doubt: is there someone on your team whose role, today, is managing data infrastructure? If the answer is yes, Airbyte OSS might make sense, because the maintenance cost is already covered by an existing salary.
If the answer is no, and the maintenance will fall on someone who already has another role (analyst, product engineer, the founder), the math changes. The "free" license gets expensive quickly, but in time, not in cash.
The alternative: managed ingestion
A managed ingestion layer, like Erathos, handles exactly the part that Airbyte OSS leaves to you: connector maintenance. In practice, this means authentication, schema changes, backfilling, and data integrity are handled by whoever built the connector, not by your team.
Erathos connects the main data sources of Brazilian companies (CRMs, ERPs, production databases, financial tools) directly to the main data warehouses in the market (BigQuery, Snowflake, Redshift), with a free plan and a 14-day trial with no credit card required, for those who want to test before deciding.
If you want to understand point-by-point where Erathos and Airbyte differ, from OSS to Airbyte Cloud, we have a full comparison here.
In practice: the Brick Seguros case
This is not a hypothetical scenario. It was exactly the decision that Brick Seguros faced.
Before Erathos, Brick maintained its own ingestion using Airflow to orchestrate extractions and dbt running on top, managed by Carlos Schwabe, co-founder of the company. It worked, in the sense that the data arrived. But every different API (HubSpot, Conta Azul, Zendesk, production database) brought its own maintenance headache, and about twice a week Carlos had to stop what he was doing to fix a broken pipeline.
It's worth noting: Brick's case isn't about Airbyte OSS; their stack was Airflow orchestrating extractions with custom scripts. But it's the exact same underlying issue: hand-built ingestion infrastructure, maintained by someone who didn't have this as their primary role. The logic applies to any open-source tool that becomes a recurring team responsibility, Airbyte included.
After migrating their ingestion to Erathos, the time to deploy a new data source dropped from 2 to 3 months to 2 to 3 days, according to the team. Carlos, who used to spend 4 to 5 hours a week just keeping pipelines running, now spends zero. The full case study, featuring Carlos and the rest of the team, is available here.
Get started now
If your company is at this decision point, you can test what a managed ingestion layer changes in practice, with no commitment.
What "free" really means in Airbyte OSS (Open Source)
Running Airbyte OSS (Open Source) doesn't cost license fees. That's true. But data ingestion was never just about running pipelines; it's about pipelines running reliably, with complete data, every single day, without someone babysitting them. That part has a cost, it just doesn't show up on a monthly bill. It shows up in hours.
Before deciding between hosting it yourself or hiring a managed solution, it's worth understanding exactly what's at stake on both sides.
The pros of running Airbyte OSS
Zero license cost. For those on a tight budget with someone available to manage the infrastructure, this is a strong argument.
Control over where to host. You choose the cloud provider or server, but that comes with a requirement: Airbyte is built to run on Kubernetes. Even the simplest local installation (via
abctl) spins up a Kubernetes cluster under the hood. There is no way to bypass this layer; you can only decide where it runs.Active community and open-source connectors. Most of the common connectors already exist, maintained by those who use them.
The cons that appear after pipelines are in production
Maintenance is not optional. An API changes a field, a schema changes format, and someone on your team needs to notice, fix, and backfill. This doesn't happen once; it happens every time a source changes something.
Official maintenance only covers a fraction of the connectors. The rest relies on community contributions—meaning, the users. If the connector you need is not in this officially maintained core, the responsibility of maintaining, updating, and fixing it falls on your team.
Self-hosted infrastructure needs ownership. Server uptime, monitoring, alerting, scaling. This isn't a weekend hobby; it's recurring work.
The cost shows up in the people you least want wasting time on this. Usually, it's your most senior engineer, or the technical founder, troubleshooting incidents at 10 PM instead of doing the work only they can do.
How to know if your company is ready to self-host
A simple question resolves most of the doubt: is there someone on your team whose role, today, is managing data infrastructure? If the answer is yes, Airbyte OSS might make sense, because the maintenance cost is already covered by an existing salary.
If the answer is no, and the maintenance will fall on someone who already has another role (analyst, product engineer, the founder), the math changes. The "free" license gets expensive quickly, but in time, not in cash.
The alternative: managed ingestion
A managed ingestion layer, like Erathos, handles exactly the part that Airbyte OSS leaves to you: connector maintenance. In practice, this means authentication, schema changes, backfilling, and data integrity are handled by whoever built the connector, not by your team.
Erathos connects the main data sources of Brazilian companies (CRMs, ERPs, production databases, financial tools) directly to the main data warehouses in the market (BigQuery, Snowflake, Redshift), with a free plan and a 14-day trial with no credit card required, for those who want to test before deciding.
If you want to understand point-by-point where Erathos and Airbyte differ, from OSS to Airbyte Cloud, we have a full comparison here.
In practice: the Brick Seguros case
This is not a hypothetical scenario. It was exactly the decision that Brick Seguros faced.
Before Erathos, Brick maintained its own ingestion using Airflow to orchestrate extractions and dbt running on top, managed by Carlos Schwabe, co-founder of the company. It worked, in the sense that the data arrived. But every different API (HubSpot, Conta Azul, Zendesk, production database) brought its own maintenance headache, and about twice a week Carlos had to stop what he was doing to fix a broken pipeline.
It's worth noting: Brick's case isn't about Airbyte OSS; their stack was Airflow orchestrating extractions with custom scripts. But it's the exact same underlying issue: hand-built ingestion infrastructure, maintained by someone who didn't have this as their primary role. The logic applies to any open-source tool that becomes a recurring team responsibility, Airbyte included.
After migrating their ingestion to Erathos, the time to deploy a new data source dropped from 2 to 3 months to 2 to 3 days, according to the team. Carlos, who used to spend 4 to 5 hours a week just keeping pipelines running, now spends zero. The full case study, featuring Carlos and the rest of the team, is available here.
Get started now
If your company is at this decision point, you can test what a managed ingestion layer changes in practice, with no commitment.