
Fivetran Pricing Explained: Why MAR Billing Is Overkill for One Billing Sync
Fivetran prices on monthly active rows. Here is how MAR actually works, what changed in January 2026, and why the bill is hard to forecast for one sync.
You have one billing source, Stripe or QuickBooks or Xero or Paddle, and one Postgres database. You want the first to land in the second on a schedule. Somewhere in the research you end up on Fivetran, and the pricing page quotes you in a unit you have never used before: monthly active rows.
MAR is not a bad idea. It is a genuinely fairer meter than per-connector seat pricing for a company moving hundreds of tables. The problem for a reader in your position is narrower and worth naming precisely: MAR is priced on how much your data changes, and you cannot know that number before you start.
This post explains how MAR works, what changed on 1 January 2026, and where the model stops making sense for a single billing source.
What a Monthly Active Row Actually Is
A monthly active row is a distinct row that was inserted, updated or deleted in a calendar month, identified by its primary key.
The part people get wrong is the counting. From Fivetran's own documentation: "We only count a row once per month, even if it syncs multiple times." A subscription record that changes thirty times in March is one MAR, not thirty. That is the model working in your favour, and it is why running syncs more often does not directly cost more.
Two details matter more than the headline:
- MAR is measured per connection, not per account. Since March 2025, Fivetran calculates usage separately for each account, destination, connection and table. Syncing the same Stripe data to two destinations counts twice.
- Rows that did not change are free. Only churn is billable, which is why a table with a million static rows can cost almost nothing while a small, busy table costs more.
What Changed on 1 January 2026
Three things moved, and older comparison posts have not caught up.
Deletes now count toward paid MAR. Fivetran's 2026 pricing update states it plainly: "As of January 1, 2026, inserts, updates, and deletes will count toward paid MAR. Previously, deletes did not contribute to paid MAR." The reasoning is defensible, since a deletion is a real change with analytical value, but it is a straightforward increase for any source that removes records.
There is now a minimum charge per connection. A $5 base charge applies to every standard connection doing between 1 and 1 million MAR per month. If you have five small connections that barely move, you now have a $25 floor before any usage is counted. The Free plan is exempt.
The Starter and Private Deployment plans are gone. The current lineup is Free, Standard, Enterprise and Business Critical, the last of which adds customer-managed encryption keys, PCI DSS Level 1 and private networking.
Yes, the Free Plan Is Real
Most posts arguing against Fivetran skip this, and skipping it makes the argument worse rather than better.
Fivetran's Free plan includes 500,000 MAR per month, along with 3,500 activation MAR and 5,000 transformation model runs. It is a plan, not a trial. There is also a 14-day account trial, and separately each new connection gets 14 days of free use starting when incremental syncs are first detected.
For a single billing source at small scale, 500,000 changed rows in a month is a lot of headroom. A SaaS business with a few thousand customers and a few thousand invoices a month will not come close. If that is you, Fivetran may well cost you nothing, and any post telling you it is too expensive is selling you something.
So the honest question is not "is Fivetran expensive". It is "what happens after that, and can you see it coming".
Why the Bill Is Hard to Forecast
Here is the part that should decide it for a one-source setup.
There is no published per-MAR rate. Fivetran's pricing page describes a consumption curve where the per-row cost falls as volume rises, and points you to a Service Consumption Table and a pricing estimator. Neither renders a plain rate card you can read, quote or put in a spreadsheet. I went looking specifically to include real numbers here and could not verify a single per-MAR figure from Fivetran directly.
Third-party sites fill the gap badly. In the course of writing this I found published claims of $500 per million MAR and $2.50 per million MAR for the same Standard plan. Those differ by a factor of two hundred. At least one is wrong, possibly both, and there is no authoritative document to settle it. If you see a confident per-row number in a comparison post, treat it as a guess.
The meter tracks your customers' behaviour, not your requirements. This is the structural issue. Your infrastructure needs are flat: one Stripe account, a handful of tables, a nightly refresh. Your MAR is driven by how many subscriptions changed state, how many invoices moved from open to paid, how many records were removed. A billing month with a promotion, a price migration, a dunning wave or a bulk cleanup produces a bigger invoice than a quiet month, for the same pipeline doing the same job.
Cost arrives as a step, not a slope. Below 500,000 MAR you pay nothing. Above it you are on a paid plan with a $5 per-connection floor and a rate you had to run an estimator to discover. Nothing warns you as you approach the line, and the crossing is caused by your customers, not by a decision you made.
For a data team running fifteen sources into Snowflake, forecasting that is a normal part of the job and the volume discounts are worth having. For one billing sync into Postgres, you have taken on a variable cost and a modelling exercise to solve a fixed problem.
What Actually Drives MAR on a Billing Sync
It helps to see where the churn comes from, because it is rarely the table you expect.
Customers are the calmest table. A customer record changes when someone updates a card, an address or an email, so a few percent of the table per month is typical.
Subscriptions are busier than they look. Every status transition is an update: trialing to active, active to past_due, past_due to canceled, plus renewals, plan changes and quantity changes. A subscription can produce several distinct active months per year even when the customer does nothing unusual.
Invoices and charges are the volume driver, and they are lifecycle-heavy. A single invoice moves through draft, open, paid, and possibly through a failed payment and a retry. Because MAR counts a row once per month regardless of how many of those transitions happen, this is much better than it sounds, but the row count still scales directly with your transaction volume.
The rough shape: your monthly MAR is closer to "customers who did something" plus "invoices raised this month" than to the total size of your Stripe account. That is the number to estimate before signing anything, and it is also the number that moves without warning.
One thing that does not cost you: historical syncs are free. Fivetran's documentation confirms that initial syncs do not incur a charge for the historical data they load, and that tracked incremental updates are what may count outside a connection's free trial period. Backfilling five years of Stripe history is not what puts you over the line. Ordinary month-to-month operation is.
When Fivetran Is the Right Call
It would be dishonest to write this without the other side, so here it is.
Fivetran is a serious product and MAR is a serious pricing model. Choose it when you have many sources rather than one, when the destination is a warehouse like Snowflake, BigQuery, Redshift or Databricks, when you need 700+ connectors covering systems nobody else supports, or when you need the compliance posture in the Business Critical tier. At real volume the consumption curve works for you, since the per-row cost falls as usage rises, and an annual commitment takes up to 22% off.
If you are building a central analytics platform, the flexibility is worth the forecasting work.
When It Is Overkill
One billing provider. One Postgres database. A handful of tables. A once- or twice-daily refresh.
That workload has no need for 700 connectors, no warehouse, no transformation layer, and no reason to be metered on row churn. You are buying a platform to solve a problem that is closer to a scheduled copy, and paying for it in a unit that varies with your customers' behaviour.
What you want instead is a flat number you can put in a budget and forget.
The Flat-Fee Version
Codeless Sync does the narrow version of this job: Stripe, QuickBooks, Xero and Paddle into PostgreSQL, including Supabase, Neon, AWS RDS, Railway and DigitalOcean. You connect the provider, pick a data type, and the destination table is created for you.
The pricing is a short list of fixed numbers you can read before you sign up. Free is $0 for 2 manual syncs a day, 2 configurations and 1 database project. Paid tiers start at $19 a month for Starter, $29 for Pro and $99 for Business, and each adds scheduled syncs, more configurations and a larger monthly row allowance.
Every tier does include a monthly row allowance, so volume is not irrelevant. The difference is what happens at the boundary: an allowance is a ceiling you can read on the pricing page before you commit, not a meter that turns a busy billing month into a larger invoice. You can outgrow a plan. You cannot be surprised by one.
Scheduled syncs are the paid feature, and when you create a schedule you choose the sync mode. A full sync is the default and re-reads everything, or you can pick a fixed window that fetches records changed in the last day, 7 days or 30 days. Keep the window wider than the gap between runs, so a daily schedule pairs best with the last-7-days window and a failed run heals itself on the next one. Cron expressions for scheduled data syncs covers the syntax if you want a specific cadence.
Side by side, on the axes that actually differ:
| Fivetran Standard | Codeless Sync | |
|---|---|---|
| Pricing unit | Monthly active rows, per connection | Flat monthly fee |
| Published rate you can quote | No, estimator only | Yes, $19 to $99 a month |
| Same bill every month | No, tracks row churn | Yes |
| Sources | 700+ | Stripe, QuickBooks, Xero, Paddle |
| Destinations | Warehouses, databases, 200+ targets | PostgreSQL |
| Free tier | 500,000 MAR per month | 2 syncs per day, no card |
| Best for | Many sources into a warehouse | One or two billing sources into Postgres |
Fivetran wins the top half of that table and it is not close. The question is whether you need any of it.
If you want the wider field rather than a straight comparison, the best tools to sync Stripe data to a database covers seven options with honest trade-offs, and the best Stripe Sigma alternative for Postgres users covers the reporting angle specifically.
Frequently Asked Questions
What is a monthly active row in Fivetran?
A distinct row, identified by primary key, that was inserted, updated or deleted during a calendar month. It is counted once per month no matter how many times it syncs, and it is measured separately for each connection, destination and table.
Is Fivetran free for a small Stripe sync?
It can be. The Free plan includes 500,000 MAR per month, which is more changed rows than most small SaaS businesses generate. The catch is that nothing tells you how close you are getting, and crossing the line puts you on a paid plan with a rate you have to run an estimator to find.
Did Fivetran's pricing change in 2026?
Yes, on 1 January 2026. Deletes now count toward paid MAR where previously they did not, and a $5 minimum charge now applies to standard connections doing between 1 and 1 million MAR per month. The Starter and Private Deployment plans were also discontinued.
Why can't I find Fivetran's price per row?
Because it is not published as a flat rate. The per-MAR cost follows a consumption curve that falls as volume rises, and Fivetran directs you to a pricing estimator rather than a rate card. Per-row figures quoted on comparison sites are unreliable, and I found published claims differing by a factor of two hundred for the same plan.
Does a historical backfill count toward my MAR?
No. Fivetran's documentation states that initial syncs do not incur a cost for the historical data they load. It is the ongoing incremental updates that count, so loading years of Stripe history is not what pushes you over a threshold.
What is a cheaper alternative for one billing source?
If your requirement is one or two billing providers into PostgreSQL, a flat-fee tool is both cheaper and easier to budget. Codeless Sync is $0 for manual syncs, and scheduled syncs start at $19 a month, with the same bill regardless of how many rows changed.
Wrapping Up
MAR is a reasonable answer to a question you probably are not asking. It exists so that a company moving thousands of tables pays in proportion to the work done, and it does that job well.
For one billing source going into one Postgres database, it converts a fixed requirement into a variable cost, prices it in a unit you cannot look up, and hands you a threshold your customers control. Fivetran's free tier may cover you today. The thing worth weighing is what happens the month it does not, and whether you would rather just know the number.
Try the flat-fee version at codelesssync.com
Related:
Questions or feedback? Feel free to reach out. If you found this helpful, you can try Codeless Sync for free.