Fivetran charges you per row. Nobody budgets per row
Rig rebuilds your pipelines, models and dashboards for free, on a flat monthly price, and runs them beside Fivetran until the numbers match. Then you switch Fivetran off.
What does it actually cost?
Fivetran bills on monthly active rows: every insert and every update, across every connector. That number is set by how often your sources change, which is not a thing you decide. Rig is a flat monthly fee with ingestion included. Move the sliders, and switch between the pipe on its own and the whole stack around it.
Inserts and updates, not total rows. Your Fivetran dashboard reports this.
Fivetran publishes one rate: $0.0005 per active row, which is what all four worked examples in their own pricing guide divide out to. Reproducing their worked example gives $496.14 against their $496.12, so the model is right where their numbers are public. They do not publish the declining rates above 1m rows, so those bands are our estimate and the real number depends on your contract.
Pricing is per connection, not on your account total: each connection runs its own cost curve, so the same volume spread across more connections costs more. We split your rows evenly across connections, which is the neutral assumption. A real account is lumpy, a few big connections and a long tail of small ones, and a lumpy split costs less than an even one. If you have an invoice, check it against this and tell us where we are wrong.
The $5 connection charge applies only to connections between 1 and 1m rows, never above. There is no free-row allowance on a paid plan: the 500k figure is the Free plan's cap. Model-run tiers and the 22% annual discount are published. Standard plan; Enterprise and Business Critical cost more. BI and engineering lines are the same assumptions as our pricing page, and the 22% never applies to them. Checked 11 August 2026.
- Rows
- $16,100
- Model runs
- $150
- Connection base
- $0
- BI tooling
- $1,500
- Engineering time
- $11,000
- Unlimited seats
- Ingestion included
- No per-row billing
- Migration built for free
Worth saying plainly: on ingestion alone, at 14 connections, Fivetran is the cheaper line until about 7.3m active rows a month. Below that, a Rig tier costs more than the pipe it replaces. The comparison that decides it is the whole stack, because a Rig tier also covers the BI tool and most of the engineering time that a Fivetran stack still needs on top.
One line is your data growing. The other is your bill
The re-sync problem
Change a column type and Fivetran re-syncs the table. Unchanged rows aren't billed, but everything the re-sync touches and updates is. The bill arrives after the decision.
The volatility problem
A row that updates forty times a month costs the same as forty rows. Status columns, order states, sync timestamps: the noisiest tables are the expensive ones.
The forecasting problem
Finance wants a number for next year. MAR pricing gives you a number that depends on how much your customers do next year. Those are not the same question.
Who's already done this
Two real migrations, anonymised because the numbers are theirs and not ours to publish with a logo attached. Happy to introduce you to either of them on a call.
Ninety-six connections on the books, fifty-seven actually doing anything. Snowflake ingestion from MongoDB, Postgres, Zendesk and Stripe. We reviewed every connector before quoting, phased the move with parallel runs and schema mapping, and cut the ones nobody had read in a year.
Compute was 80% of total data spend, on top of Fivetran ingestion. Rig replaced the ingestion, auto-migrated the Metabase dashboards, and the query patterns Rig learned fed straight into slot management on the warehouse side.
Do I lose my data or my history?
No, and this is the easiest question on the page. Your warehouse is yours. Fivetran lands data in your Snowflake, BigQuery, Databricks or Redshift, and Rig lands data in the same place. Nothing is copied out, nothing is held anywhere we control, and the history Fivetran has already written stays exactly where it is.
We match Fivetran's schema and naming conventions, including the _fivetran_synced style bookkeeping columns your models may depend on. That is the detail that decides whether your existing dbt project and dashboards survive the move untouched, so we treat it as a hard requirement rather than a nice-to-have.
Transformations come across as dbt Core, which is open source. If you ever leave, the models are plain SQL in a git repo you own, and the ingestion is dlt, which is also open source.
How painful is the move, and who does the work?
We do it. What we need from you is roughly an hour of access setup and someone who can tell us which dashboards actually matter. Everything else is our side.
- 1
Connector review
We read your Fivetran account and list every connection, what it costs and when it was last queried. On one migration that turned 96 connections into 57 worth keeping. This is where most of the saving is found, before a single row moves.
- 2
Parallel build
We rebuild the connectors, dbt models and dashboards on Rig while Fivetran keeps running. Nothing in production changes.
- 3
Row-level parity check
We compare the two outputs until they agree. You see the diff, not a promise.
- 4
Cutover
You point your BI at Rig and switch Fivetran off, connector by connector or all at once. Your call, and reversible until the contract lapses.
Will I have everything I have today?
Close to it, with one real exception that gets its own section below. Here is the honest mapping.
| Capability | Fivetran | Rig |
|---|---|---|
| Managed SaaS connectors | 700+ connectors | 300+ connectors, plus open-source dlt for anything missing |
| Database replication | Log-based CDC on enterprise DB connectors | Batch and incremental. Sub-minute CDC is not there yet |
| Schema drift handling | Automatic column and table propagation | Automatic, and the context layer re-reads the schema so models and metrics follow |
| Your warehouse | Loads into Snowflake, BigQuery, Databricks, Redshift | Same destinations, or Rig hosts the warehouse for you |
| dbt | dbt Core integration, billed per model run | dbt Core included, no per-run billing |
| Transformations | Quickstart data models | Generated dbt models plus virtual data models over the raw tables |
| Sync frequency | 15 min on Standard, 1 min on Enterprise | 15 min standard, configurable per source |
| RBAC | Role-based access to the Fivetran console | Role, schema, column and row-level access to the data itself |
| Audit trail | Sync and connector logs | Every query, by user and by agent, with the SQL attached |
What won't I have?
Four things, stated plainly, because you will find them in week two anyway.
Sub-minute, log-based CDC. If you replicate a high-write production Postgres or MongoDB with a second-level RPO, keep Fivetran on that one connector and run Rig for everything else. Several customers do exactly this.
700+ connectors is more than 300+. The long tail is where Fivetran wins, and if you depend on an obscure source we may need to build it. dlt is open source, so you can build it too, and we will not hold the pipeline hostage.
Fivetran has a decade of SOC 2 audits and a Fortune 500 reference list. We are a younger company. If your procurement team weights vendor age heavily, that is a fair thing to weigh.
No Audience Hub equivalent. Reverse ETL back into Salesforce and HubSpot works, but the campaign-audience tooling around it is thinner.
What do I get that I don't have today?
Fivetran is a pipeline company. It lands raw tables in your warehouse and its job is finished there. The gap between a landed table and an answered question is where the rest of your budget goes.
Flat pricing, so a bad sync isn't a bad invoice
A schema change that triggers a re-sync, a backfill, a chatty API, a table someone accidentally set to full refresh: on MAR pricing each of those is a bill. On Rig the number is the same every month.
The context layer, not just the pipes
Fivetran lands raw tables and stops. Rig reads the warehouse and builds the semantic layer on top: table and column meaning, joins, business terms, certified metrics. That is the part that makes the data answerable.
Governed AI access, built in
One MCP endpoint your whole company can point Claude at, with row and column-level permissions, sandboxed SQL and a full audit log. No per-team API keys, no ungoverned warehouse credentials in a config file.
Unlimited seats
Every plan. Analysts, ops, finance, the CEO. Nobody is priced out of asking a question.
We do the migration
Pipelines, models, dashboards, rebuilt by us, running in parallel with Fivetran until you are satisfied. No charge for the build.
Dashboards and automations on top
The things you would otherwise buy a BI seat and a workflow tool for. Included, and generated from the same certified metrics.
Should I just keep Fivetran and point Claude at the warehouse?
You can, and for one analyst on one warehouse it works well. It stops working when the second team joins, because the thing you are missing is not intelligence, it is governance and shared meaning.
| Fivetran + Claude direct | Through Rig | |
|---|---|---|
| Where the data lives | Whatever Fivetran landed, raw and undocumented | Same tables, plus meaning, joins and certified metrics |
| Permissions | Warehouse credentials in a config file, all or nothing | Role, schema, column and row-level, enforced per user |
| Cost control | An agent can write a query that scans your whole warehouse | Queries are cost-checked and blocked before they run |
| Consistency | Two people ask the same question, get two numbers | Certified metrics, so the answer is the same every time |
| Schema changes | Prompts silently go stale | Context re-reads the schema and follows the drift |
| Audit | None | Every query logged, by user and by agent |
What if Rig shuts down?
Fair question to ask a younger company, and the answer is structural rather than reassuring noises. You own the warehouse. The transformations are dbt Core. The ingestion is dlt. Both are open source, both run without us, and neither is a format only we can read.
That is the real difference between a lock-in risk and a vendor risk. If we disappeared tomorrow, your pipelines are Python modules and your models are SQL files, sitting in a repository you control, writing into a warehouse you pay for directly. What you would lose is the context layer and the interface, not the data and not the plumbing.
Everything else
A week is typical for a mid-sized stack. We rebuild your connectors, models and dashboards on Rig while Fivetran keeps running, compare the two outputs row by row until they agree, and only then do you switch Fivetran off. Larger estates with database replication and heavy dbt projects run to three or four weeks, phased connector by connector.
No, and most teams shouldn't. The normal pattern is to move the expensive SaaS connectors first, because that is where MAR pricing hurts most, and leave databases on Fivetran until you're comfortable. Running both side by side for a while is expected, not a failure mode.
Nothing. It is your warehouse and your data. Rig writes into the same destination, and we match Fivetran's schema and naming so your existing dbt models and dashboards keep resolving. History that Fivetran has already loaded stays exactly where it is.
Yes. Rig runs headless on the warehouse you already have, for a flat fee with no compute markup. Or we host the warehouse and bill platform fee plus compute. Both are on the pricing page, and unlimited seats apply either way.
It comes across as-is. Rig runs dbt Core and does not bill per model run, so the transformations line on your Fivetran invoice goes to zero. If your models were built against Fivetran's schema, they keep working, because we match it.
Not at sub-minute latency, and we'd rather say so up front. Batch and incremental replication are solid. If you have a high-write production database with a second-level recovery point objective, keep that one connector on Fivetran and move everything else. The savings are in the SaaS connectors anyway.
We build it, usually within the migration window, and it costs you nothing. Rig's ingestion is built on dlt, which is open source, so the connector is a Python module you can read, fork and run yourself if you ever leave.
Yes. Pipelines, models and dashboards rebuilt at no cost, plus a discount on year one once you're live. We do it because a migration we run is a migration that works, and because the fastest way to show the pricing difference is to put both bills next to each other.
Because we don't charge per row. Our cost is compute and storage, which is roughly flat in the number of tables and syncs, not in how often a row changes. MAR pricing charges you for volatility, and volatility is the thing you control least.
Start with your Fivetran bill
Twenty minutes. Bring last month's invoice and your connector list, and we'll tell you what we'd charge and which connectors we would not bother rebuilding. If the answer is that you should stay on Fivetran, we'll say so.
Twenty-minute call and connector review
Rig running in parallel, nothing switched off
Row-level parity check, then your call
Fivetran pricing, plan names and published rates checked 11 August 2026 against fivetran.com/pricing and Fivetran's own pricing guide. Rig prices are the public tiers on rig.so/pricing. Customer figures are from migrations we ran, anonymised at the customer's preference.