Our v1 pricing had a known hole. We're closing it now.
Specifically: we charged $79/mo for "Pro" with a 15,000-runs-per-month quota and no cap on the volume of data those runs moved. On paper, fine. In practice, a single customer running one pipeline that shovels 1 TB of Postgres into BigQuery per month would cost us $50–$150 in infrastructure to serve — on a $79 bill. Repeat that across ten customers and the business is upside-down.
We don't have ten of those customers yet. We don't have one of them yet. Which is exactly why we're fixing this now, before the first one arrives — not after, when it turns into an apology post.
What changed
| Plan | Old | New |
|---|---|---|
| Free | 500 runs, no volume cap | 10 GB processed/mo + 500 runs |
| Pro ($79/mo) | 15,000 runs, no volume cap | 100 GB processed/mo, $0.50/extra GB, 15,000 runs |
| Enterprise (from $399/mo) | 50,000 runs, $0.01/run overage, no volume cap | 1 TB processed/mo, $0.25/extra GB, 50,000 runs |
Seats, connections, and schedules stay the same. SSO stays on Enterprise. The tiers haven't moved; the meter has.
Every GB on this page — and every number derived from one below — is the binary GB our meter counts: 1,073,741,824 bytes (230), which is 7.4% more data than the decimal GB most warehouse consoles report. Worth knowing before you check our arithmetic against your own, because counting in decimal makes your usage look larger than we meter it.
Why "volume" was missing
Because we shipped v1 with Paddle's default-shape subscription plans — a flat monthly fee plus a secondary usage meter (model runs). That captured the obvious cost driver (orchestration, scheduler CPU, log storage) but ignored the expensive one (the actual bytes that hit disk, get normalized, get re-read by dbt, and get written to the destination).
Run counts correlate with some costs. They don't correlate with the cost that scales with your success as a customer. A pipeline running 30×/day with 500 rows per run is cheap for us. A pipeline running once a day with a full-history dump of your production database is not. v1 charged both the same.
That's the hole.
The math that broke it
Take one customer running one pipeline: a nightly export of a Postgres table with a million wide rows. Each row is ~1 KB, so the raw export is ~1 GB. Nested JSON columns flatten to ~3 GB after normalization. A dbt model aggregates that to a 100 MB summary. Total bytes touched per run: roughly 3.1 GB. Repeat nightly for 30 days: ~93 GB/mo.
At v1, we billed $79 for this. At cloud-provider rates for storage + CPU + egress, we spent $12–$25 on infrastructure. That's fine. We're profitable on this shape.
Now scale it to the same customer adding three more pipelines: a Stripe export, a HubSpot sync, a Segment event feed. Each one amplifies 2–5× after normalization. Total bytes/mo: ~400–600 GB. Infrastructure cost: $50–$100. Still $79 on the bill.
Scale once more to a customer with a real data footprint — 1 TB/mo across 8 pipelines — and we're spending $120+ on a $79 subscription. That's the bill that convinced us the pricing was wrong.
If you're processing more than 740 GB/mo — binary GB, as above; about 795 GB as a warehouse console counts them — Enterprise's $0.25/GB rate saves you more than the subscription difference. The pricing calculator auto-picks the cheaper tier for you — no mental math required.
Why GB and not MAR
Fivetran's "monthly active rows" pricing is the obvious alternative. We looked at it; we're not doing it.
MAR punishes schema choices you didn't make. A table with 10M narrow rows and a table with 100K wide rows can hit an identical disk-and-CPU bill but a 100× MAR bill. MAR also re-counts edits — update one row ten times this month and Fivetran charges you for ten rows. The customer has no way to predict the bill until the sync runs.
GB measures the cost driver directly. A wide JSON blob and a narrow normalized row land on the same gram of disk for the same price. Updates don't inflate the count. You can predict your bill by looking at du -sh on your source and multiplying by a constant.
Fivetran publishes no per-MAR rate, so its side of this comparison is an illustrative estimate rather than a quote. Converting at ~200K rows/GB, 100 GB on Starter lands in the region of $3,800/mo and 1 TB somewhere around $22,000/mo. On Datanika Pro at 100 GB you pay $79, and on Enterprise at 1 TB, $399 + nothing (it's included) — those two are exact. The calculator on /why-cheaper/ shows the comparison side-by-side with a slider, and Fivetran's own estimator is where a binding number comes from.
That's what we mean by "you pay for bytes, not tables."
How we meter honestly
We count output bytes after normalization — the amplified number, not the raw input. We do this because the amplified number is what our infrastructure actually touches, and pretending otherwise creates a gap between the sticker and the bill.
Worked example: you have a 1 GB HubSpot JSON export. Our ingestion flattens nested objects into a wide table — that's ~3 GB of post-normalization data, and ~3 GB is what counts against your quota, not 1 GB. A dbt model that aggregates it to a 100 MB summary adds nothing to that: only uploads are metered in bytes, and a model run counts as a model run.
The reason we publish the amplification rather than hiding it is that it makes the bill something you can work out in advance yourself. A gigabyte is a unit you can count; the rate is on the pricing page; the multiplication is yours. MAR is the opposite kind of unit — it is defined and counted by the vendor, so the invoice is the first place you get to see it.
What a month costs
The meter reads what an upload wrote: your data is normalized on our side, so a 1 GB JSON export becomes ~3 GB of flat tables and the meter counts ~3 GB.
At $0.50/GB overage (Pro), each nightly run past your included 100 GB adds 3 GB to the month's metered volume — $1.50 worth. Over 30 nightly runs that's 90 GB: $45. (Overage is totalled once per billing cycle and rounded up to the next whole GB, so that per-run figure is the monthly bill decomposed — not a charge you're billed run by run.)
What stays
- Self-host is still $0 forever. The AGPL-3.0 open-source core has zero pricing dimensions. Run it on your own hardware, ingest 10 TB/mo, pay us nothing.
- 10 GB Free is real headroom. That's enough for a real side project or a 3-source trickle-volume evaluation stack — a genuine test with production-shaped data, not a crippled sandbox. Fivetran Free tops out at 500K MAR (~1–2 GB equivalent); Hevo Free at 1M events. We offer 5–10× more.
- All 36 connectors on every tier. Free users don't get a crippled connector list. Fivetran adds a $5 base charge to each standard connection using under 1M MAR a month; we don't, and we're not going to.
- Pro's 5 seats, Enterprise's 10 seats, schedules unlimited on paid tiers. Seat economics are unchanged.
- Annual discount at 17% (Pro $79 → $66/mo billed annually; Enterprise from $399 → $333). We'll revisit after 90 days of real signup data — if the math says 20% works, we'll adjust and blog about it.
What we'll do if we got the numbers wrong
We picked 10 GB / 100 GB / 1 TB based on the cost model in price_insights.md §7 and a napkin-margin target of 80–95% on variable cost. We don't yet have real signup data to validate those numbers against customer reality.
Commitment: 90 days from now we look at actual usage distributions against actual infrastructure cost. If 100 GB on Pro is the wrong number — too tight for the real median customer, or too generous for our margin — we adjust the Pro tier's included volume. We blog about it when we do. The overage rate won't move in year one; we picked $0.50/GB and $0.25/GB to sit comfortably above our variable cost at every volume we've modeled.
If you're already on Datanika when we adjust: your current tier honors its current numbers until your next renewal, and we email you the change at least 30 days before it hits. Not that there's anyone on paid Datanika yet — this is the policy for when there is.
What this doesn't mean
We are not becoming a per-row-pricing company. We are not adding event fees. We are not going to count deletes. "Processed GB" is the only new meter. Everything else on your bill — seats, connections, schedules, support — stays on the subscription.
If you've been evaluating Datanika on the v1 pricing page and waiting to decide: the economics on your bill are now predictable against your data volume, which is probably the thing you actually wanted.
The numbers, measured
On a standard Hetzner CPX32 (4 vCPU, 8 GB RAM, €13/mo), dlt — the library a Datanika upload runs — processed 17,704 rows/second on a 10.1M-row Postgres → DuckDB pipeline, full extract, normalize and load, with a p95 of 571s across 3 runs (569.9s, 570.5s, 571.4s). The benchmark script calls dlt directly rather than going through a Datanika upload, so it measures the library, not the product. Full benchmark log and methodology in Datanika vs. the Modern Data Stack.
The /why-cheaper/ calculator lets you drag a slider from 1 GB to 10 TB and see the cost side-by-side with Fivetran Starter, with Datanika auto-picking the cheapest tier: Free up to 10 GB, then Pro-with-overage or Enterprise-flat, whichever costs less.
Try it free at app.datanika.io — 10 GB/mo on Free, no credit card, and one published per-GB rate with no MAR arithmetic to reverse-engineer.
Correction, 2026-08-31. An earlier version of this post said Pro and Enterprise pipelines show a pre-run predicted_bytes estimate, derived from a moving average of the last five runs, before you click "Run." That was written from the pricing spec rather than from the product: the estimate is not computed today, on any plan. The paragraph has been replaced with what the meter actually does. Tracked in landing#375.
Correction, 2026-09-22. Three more passages described something other than the product. The post had a section titled "Pick ELT, pay less". That section said every pipeline has an ETL/ELT mode selector, and that ELT is metered at ~0.8 GB where ETL is metered at ~3 GB. No pipeline can be switched to ELT: the app shows no mode selector, and nothing saves a mode, so every run takes the normalizing path described above. The worked example also counted a dbt model's 100 MB against your quota. It does not: only uploads are metered in bytes. And the benchmark was credited to Datanika when it measured dlt called directly by a script. All three passages now say what the product does. Separately, the post said Fivetran charges $5 per connection on top of MAR; Fivetran's own pricing page applies that base charge only to standard connections using between 1 and 1M MAR a month, and not on its Free plan, so the sentence now says so. Tracked in landing#656.
Top comments (0)