On 1 January 2026, Fivetran started charging you to delete data. A deleted row now counts toward your paid monthly active rows. Before that date it did not. Nothing about your pipeline changed on 31 December and nothing about your business did either.
That is from their own pricing page, which is where every claim in this post comes from. The billing horror stories going round prove nothing on their own. What their documentation says about how the product behaves proves quite a lot, and two things in it are worth reading closely if your business runs on rented connectors.
When your tables reload
Start with the behaviour the product is built around. Fivetran's own description of it is clear: "If your source adds a new column, we will detect the change and add the same column in our warehouse, backfilling the data if applicable."
That is the correct design for the job. An ELT tool exists to keep a destination faithful to a source it does not own, so it has to react to whatever the source does.
The cost of reacting is in the database connector documentation: "Schema changes in the source database are the most common trigger for a full table re-sync. When the schema changes in the source, a full table re-sync lets us propagate these changes to your destination."
Read that sentence from the operator's side. You do not decide when a schema change happens. On a multi-tenant SaaS source, a column can appear because the vendor shipped a feature for a different customer entirely. You did not ask for it, you may never use it, and the re-sync happens regardless.
Let's be accurate about the billing though, because this part is actually more generous than most assume. Fivetran's pricing documentation says "we only count a row once per month, even if it syncs multiple times", so a re-sync inside the same calendar month is not a second charge for the same row. The cost shows up as sync time and destination compute rather than as a line on the invoice. If you are mid-cutover, or feeding a report someone is waiting on, sync time is the expensive currency.
Whether a new column actually costs you a reload turns out to depend on things you did not pick. On SQL Server with Teleport Sync, "ADD COLUMN operations do not prompt a table re-sync because we are able to process the schema change without it", though DROP COLUMN does. On Oracle it inverts partway: "ADD COLUMN with a default value and RENAME COLUMN triggers a table re-sync. ADD COLUMN without a default value and DROP COLUMN are handled without triggering a table re-sync." On MySQL, Fivetran re-syncs the table instead of migrating it when the table has no primary key, when column order changes, when primary keys change, when ENUM or SET columns are modified, or when it cannot parse the DDL statement properly.
Read that list back as an operator. Your connector, your sync method, whether the table has a primary key, whether the new column carries a default value: those decide what a schema change costs you. A DBA on the source system picks most of them without knowing Fivetran is downstream.
What a row costs
The delete charge from the opening is one line in Fivetran's 2026 pricing updates, and it reads plainly enough: deletes now count toward paid MAR, where before they were excluded.
Sit with that operationally. Deleting rows is usually cleanup, or a retention policy doing its job, or a customer exercising a right to erasure. Under the old rule that activity was free. Under the new one it bills at the same rate as data arriving. Your pipelines did not change and your business did not change. The invoice did.
Two other changes landed the same day. History-mode rows are billed, including repeated updates, and connections generating between 1 and 1 million MAR on the Standard plan carry a $5 minimum. History mode at least you switch on deliberately. Nobody switches on deletes.
The three lines that moved on 1 January 2026.
For a sense of scale on how these adjustments land, one customer ahead of the March 2025 change ran Fivetran's estimator and posted the result: "we are due to increase ~36%." That is an estimator output rather than an invoice, from one account replicating MySQL to Snowflake at roughly 8 to 10 billion rows a month.
The part Fivetran gets right
The angriest recent Fivetran thread also produced the fairest comment on it, sitting at 43 points: "all these tools in the 'connector' space are varying degrees of bad." A few comments down, from someone who had read the whole complaint: "Personally I like Fivetran. It allows us to focus on other DE tasks (and let them deal with changing API's...etc)."
The second comment is the actual value proposition, and it is a good one. Handing someone else the job of tracking a changing API is a real saving, and most teams paying for it are getting it.
We sell integration software, so we are not a neutral party here. The person who started that price-increase thread called it before we could: "I imagine this thread will turn into people promoting their products, but I hope I get some valuable comments from people." He was right, and it did. Which is why the two claims above are sourced to Fivetran rather than to us. Check them.
What we chose instead
We build and operate the flows rather than sell connectors by the unit, which means the trade we made is a different one.
The first choice is that source logic stays explicit. A connector on our platform is code that states what it pulls and how it maps, readable and changeable by the people who own the data. When a source adds a column nobody asked for, that is a line you can go and look at rather than a behaviour you inherit and then discover on a Tuesday. It costs more up front than switching a connector on, and it means nothing in the path changes on a date we picked. We have written before about the mapping your ERP vendor never documented, which is the same argument aimed at a different system.
The second choice is about what happens at the other end, when the destination is a running business system such as an ERP rather than a warehouse. A warehouse is forgiving. Load the same rows twice and you deduplicate afterwards in SQL. A live system is not forgiving in the same way, because creating a customer or posting a transaction is an action with consequences. Run a half-finished load again and you get two of them, and no query cleans that up.
A retry into a warehouse is recoverable afterwards. A retry into a live system creates records.
So a write path into an operational system has to know what it already sent and what was already accepted, record by record, so that a re-run continues rather than repeats. That machinery is most of the actual work. It is also the same machinery whether you run it once during a migration or every 20 minutes forever, which is why we treat those as two modes of one data path instead of two products.
Checking that a load actually reconciled is its own problem, and worth its own post rather than a paragraph here. The nearest thing we have written is on the messy half of data quality.
One thing we do not claim: there is no transaction spanning two remote systems, because remote systems cannot give you one, and any tool implying otherwise is overselling. And we are a small team, so if your first criterion is which vendor still exists in 2030, Fivetran wins it outright.
Both of the behaviours in this post are published, and neither is a secret. That is the point. You can read exactly what your data platform will do to you and still have no say in when it happens, because the trigger sits with a DBA on a system you do not run, or with a pricing page revised in January. If that trade is worth it, take it knowingly. We built the other one.