Monthly Active Rows and Foundational Agentic Plays on Commoditized ETL Solutions

ETL has been the same job for thirty years. Pull data out of the systems a business runs on, reshape it, and load it somewhere you can analyze it. Extract, transform, load. Informatica and Talend built the first big businesses on it in the 1990s and 2000s, back when you cleaned the data before it landed because warehouse storage was expensive. Then cloud warehouses made storage cheap, the order flipped to extract-load-transform, and Fivetran turned the connector into a utility you rent. Airbyte arrived in 2020 arguing the connectors should be open source and commoditized. dlt, the open-source data load tool, is where that argument lands: movement as a Python library you own.

I pulled the history and pricing details from a past data project, and the through-line is consistent. The people who built these companies mostly agree that moving rows from A to B is a commodity. Fivetran’s CEO has called the product a button you push, where the data appears and the details stay unknown to you. Airbyte’s founders said their goal was to commoditize data integration. Benn Stancil wrote years ago that an undifferentiated syncing service between a handful of apps and databases was never much of a business. The disagreement was never whether it’s a commodity. It was who should capture the margin on it.

The number I’ve always questioned

Fivetran is one of the best ETL products on the market, and I’ve recommended it. But Monthly Active Rows on CRM and email marketing connectors are the part I’ve never been able to justify.

MAR is simple. Every row inserted, updated, or deleted in a source counts once a month, and you pay per thousand. As of this year deletes count too, so a record that gets created, worked, and later removed bills at both ends. For a lot of sources that’s fair. For a CRM or an email marketing platform, it’s a tax on the one thing those systems exist to do. Their job is to move records through a lifecycle. A deal changes stage, a rep updates a status, a subscriber opens, clicks, or unsubscribes, and each of those is a new active row. The data isn’t growing. The same records are churning, and you’re billed for the churn. An email list at scale is the sharpest version of it: a row per recipient per campaign, status moving from sent to opened to clicked, every move billable.

What the invoices showed

A client’s new CEO asked whether they still needed Fivetran for everything. We had already moved most of their pipelines to dlt, so I pulled a year of invoices to see what was left. The bill ran about $1,000 a month, and two connectors carried the bulk of it: the CRM and the email marketing platform. The two sources built to churn records were the two most expensive to sync.

Each of those two connectors ran a few hundred dollars a month, moving on the order of a million active rows while the underlying data barely changed size. A CRM with a few thousand accounts, an email list working through campaigns, both should be cheap to move. On row-based pricing they were the opposite. The connectors that should have cost the least cost the most.

So we moved them. Not to save on movement itself, which is nearly free either way, but to stop paying a subscription that scales with churn. On dlt the same email pipeline runs on flat compute, a few dollars a month, no matter how much the list moves. You decide what counts as a change instead of paying for all of them.

Owning what churns

None of this was worth doing two years ago, because building and maintaining your own connectors was expensive. That changed. dlt was built for LLMs as much as for people, and by the start of this year most new dlt pipelines were written by agents, not humans. You describe a source to a coding agent, it scaffolds the pipeline and the tests, and you review it. It used to take real engineering time to stand up and babysit each source. Now, with a template and an agent, I can stand up a new dlt source in about ninety minutes, often under an hour, plus an hour of fine-tuning later if it needs it. The work is heavy up front and then it nearly stops.

The one thing the vendor genuinely did was notice when a source broke, and that job is now yours. It does not need an expensive tool. dlt’s schema contracts stop a pipeline the moment the source shape changes. A free tool called oasdiff diffs an OpenAPI spec on a schedule. A lightweight page watcher catches a changelog moving. The agent writes the pipeline, and a deterministic layer around it, the contracts and the diffs and the tests, is what makes the output something you can trust. It is the same pattern I’ve written about for putting LLMs on your data. The model proposes, the code decides.

When to own it and when to rent it

The invoice narrowed my own rule. AI changed the cost of building a pipeline. It did not change the cost of owning one, and owning is still the hard part. So I wouldn’t tell anyone to self-host everything. I’d own the sources that churn, because that is where MAR punishes you hardest, and the CRM and email connectors prove it. I’d own the long tail no vendor will build a connector for, because you’re writing that code anyway. And I’d keep renting the boring, low-volume connectors until the day the meter tells me to bring them in.

If you want to check your own version of this, don’t start with a migration. Start with the invoice. Find the connector eating the bill, and ask whether it’s expensive because the data is valuable or because it’s just changing. That’s the one to migrate first.