Common Pricing Models of Data Tools (& what costs more)

architecture leadership Apr 16, 2025

Data tools price themselves in a small number of repeating ways, and once you can name them the invoice stops being a surprise. Cloud databases split the bill into storage, charged by the gigabyte or terabyte you keep, and compute, charged either by how long a query runs or by how much data it scans. Most other tools in the stack add a per user monthly subscription on top of that, and ingestion tools usually bill by monthly active rows, by credits, or by a fixed fee for a capped amount of work. Compute almost always costs more than storage. And the single largest cost is rarely on any invoice at all: it is the salaried time your team spends operating whatever you picked.

Key takeaways

Storage and compute are billed separately in modern cloud platforms, and compute is usually the larger of the two.
Storage is priced by size, with cheaper tiers for data you rarely touch and higher rates for data you need available right now.
Compute is billed one of two ways: by time, often as credits while a query runs, or by volume, often as bytes scanned.
The same query can cost wildly different amounts under those two models, so know which one you are on before you tune anything.
The older model was a one time server purchase with a fixed capacity. The modern model is pay as you go, which scales both directions.
SaaS subscriptions and ingestion pricing are separate line items from your database compute, and ingestion is usually billed by monthly active rows, credits, or a fixed tier.
People do not work for free. The hours your team spends maintaining infrastructure are a real cost, and they often exceed the tool bill you were trying to avoid.

Storage and compute are priced separately

The biggest change I have seen in my time in this field is the separation of storage and compute. They used to be one purchase. Now they are two meters running side by side.

That split is why a cloud database bill has at least two lines on it, and why the two lines move for completely different reasons.

What storage costs

Storage is the straightforward one. You are putting data on a disk somewhere and you are charged for the size of it, usually per gigabyte or per terabyte.

Relative to compute it is cheap, and cheaper than it used to be. That is not the same as free. Keep enough data for long enough and it adds up.

Hot and cold tiers

You can pay less for data you rarely touch. Cloud storage is tiered by temperature, and the temperature is really a statement about access frequency.

Hot storage. Data you read hourly, daily or weekly. Available immediately, priced highest per gigabyte.
Cold or archive storage. Data you might read once a year, or never. Discounted per gigabyte, with slower or more expensive retrieval.

If you are holding years of history for compliance rather than analysis, that history does not belong in your hottest tier.

Compute is where the money goes

Compute is the processing side: running the queries. On Snowflake, Redshift, Databricks and the rest, you pay to store the data, and then you pay again every time you execute against it.

That second charge is typically the bigger one. It is also the one you have the most control over, because it responds directly to how you write and schedule your work.

Time based versus volume based compute

Within compute there are two common models, and they reward very different behavior.

Time based

You are charged for how long something runs. This is where you see credits. Picture a stopwatch starting the moment you press run, with some platforms applying a minimum billable duration.

Volume based

You are charged for how much data the query touched. bytes scanned is the usual unit, and the clock is irrelevant.

Why the difference matters

Take a hypothetical query that finishes in one second but scans 100 terabytes. Under volume pricing you pay for 100 terabytes. Under time pricing you pay for one second.

That is an extreme case and not one you would actually hit. It makes the point though: the same work has a completely different price tag depending on the meter.

It also tells you where to optimize. On a bytes scanned platform, partitioning, clustering and filtering early are cost controls, not just performance tuning.

One time purchase versus pay as you go

It helps to see where this came from. The historical model was buying a complete server, in a data center or in your own office, with everything living on that machine.

You were not billed extra for running more queries. You used whatever capacity you had, and adding storage or memory meant another one time purchase.

The modern model inverts that. You pay as you go, and you can scale up or down easily. That is good for data teams because costs become something you can influence rather than something you sized once and lived with.

It cuts the other way too. A fixed server has a ceiling on what it can cost you. A pay as you go platform does not, which is exactly why knowing the meter matters.

SaaS subscriptions and ingestion pricing

Database compute is not the whole bill. Two other pricing structures show up in almost every stack.

Per user SaaS subscriptions

Plenty of tools are free and open source to start, and then charge a monthly subscription for the hosted version with the polished interface.

That is usually billed per user, or per block of users, with tiers that change what features and what level of support you get. It is a completely separate price from your compute.

Ingestion pricing

Ingestion billing is the one people find most confusing. There are three common shapes:

Monthly active rows. You pay based on how many records the tool loads or touches in a month, often counted in the millions. This is the volume based equivalent in the ingestion world.
Credits. You buy usage credits and get billed for how much processing a sync consumes. This is the time based equivalent.
Fixed fee with conditions. A set amount per month covering a capped number of rows or hours of operation.

Every vendor defines its own terms, so read what counts as an active row before you commit. Pricing sits alongside connector coverage and support quality when you pick a loader.

The biggest cost is your team's time

All of the above is tooling cost. The largest cost in most data organizations is people, and it almost never appears on a vendor invoice.

Salaries, hourly rates and project fees are real money spent on building and maintaining these systems. Because it is lumped into payroll, you do not feel it the way you feel a bill.

The on premise example

A team keeps an on site server for the data warehouse and feels good about avoiding cloud database charges.

Meanwhile someone is checking on it, patching it, handling networking, fixing issues and running upgrades. Priced honestly, that person's time can exceed the usage bill by a wide margin.

Not always. It is worth calculating rather than assuming, and in my experience the calculation surprises people.

Good design is a cost control

The most effective way to protect both budgets is to build well structured pipelines in the first place.

On a bytes scanned platform, writing queries with real filters and designing tables so you are not reading more than you need lowers the bill directly. Efficient architecture and cheap architecture are usually the same architecture.

Key terms

Separation of storage and compute

The cloud pricing model where keeping data and processing it are billed independently, so each one scales and costs on its own.

Storage tier

A pricing level for stored data based on how often you expect to access it, with hot tiers costing more per gigabyte than cold or archive tiers.

Credit based pricing

A time based compute model where you are billed for how long a warehouse or job runs, measured in platform credits.

Bytes scanned

A volume based compute model where you are billed for how much data a query reads, regardless of how long it takes.

Monthly active rows

An ingestion pricing unit based on how many records a tool loads or syncs in a billing month, with each vendor defining what counts.

Common questions

Does storage or compute cost more in a cloud data warehouse?

Compute, in almost every case. Storage has become relatively inexpensive per gigabyte, while query processing is metered continuously and grows with how much work your team and your BI tools generate. Storage still deserves attention over multi year horizons, but compute is where to look first.

What is the difference between credit based and bytes scanned pricing?

Credit based pricing charges for elapsed runtime, so a long slow query is expensive. Bytes scanned pricing charges for data read, so a wide unfiltered query is expensive even if it finishes fast. The tuning you do to save money is different under each.

How do data ingestion tools charge?

Most use one of three models: monthly active rows, consumption credits, or a fixed monthly fee covering a capped volume. Definitions vary between vendors, so check how an active row is counted and whether updates and deletes count separately.

Is self hosting cheaper than paying for a managed service?

Only if you price your own time honestly. The license saving is visible and the maintenance hours are not, so the comparison usually looks better than it is. Put a real hourly figure on setup, support and upgrades, then compare.

How can I lower compute costs without switching tools?

Start with the meter you are on. On volume based pricing, filter early, avoid select star and design tables so queries read less. On time based pricing, look at how long jobs run, how often they run, and whether idle warehouses are suspending properly.

Final takeaway

When I work with small data teams on architecture, the pricing conversation is never really about finding the cheapest tool. It is about knowing which meter each tool runs on so you can design around it, and remembering that the hours your team spends is the line item nobody is tracking.

Additional Free Resources

Starter Guides & Checklists

Explore additional free resources built on the same patterns I use with real clients so you can build your own with structure and confidence. Topics include data architecture, modeling and more specifically for small data teams.

Browse Resources