The defining feature of the modern data platform — the thing every vendor put on the front of the deck around 2018 — was elastic, consumption-based pricing. You pay for what you use. No-CapEx-Scale-to-Zero. Different shapes (Snowflake credits, Databricks DBUs, BigQuery slot-hours), same essential pitch.
Six years in, most enterprise data teams have a more complicated relationship with this model than the original brochures admit. The consumption bill is now the largest single source of variance in their cloud spend, and the second-largest source of friction with the CFO — right after the hyperscaler bill itself.
What consumption pricing actually optimises
To be fair to the vendors: there are real workloads where consumption is the right model.
- Bursty, predictable workloads (the nightly ETL job, the monthly reconciliation, the quarterly close).
- Highly variable load with auto-scale up + down (a B2C platform that runs analytics over weekend peaks).
- Anything where the alternative is over-provisioning a fixed cluster for the 99th-percentile load.
For these workloads, consumption pricing is net-positive. You really do pay less than the equivalent fixed cluster.
The problem is that these workloads now represent the minority of how enterprises actually use the data warehouse. The majority use case — the analyst exploring questions in an interactive session — doesn't fit the model the platforms were designed for.
The four behaviours consumption pricing punishes
Sit through one quarter of FinOps reviews and you'll see the same patterns:
- Exploration. The analyst doesn't know what the right query is yet. The first attempt scans more data than necessary. Each iteration costs money. The careful analyst, hyper-aware of cost, runs fewer queries and arrives at a worse answer.
- Documentation queries. "Let me just check how many rows are in this table" — on a 50TB table — can cost more than the entire team lunch budget for the month. The analyst learns not to ask.
- Sharing. A Slack thread says "hey can someone re-run this with last week's data?". Five people re-run it. Five times the cost for one finding.
- Looking up history. The board needs the same KPI calculated five different ways. Five queries against the same dataset. Same cost as five distinct questions.
None of these are wasteful behaviours in any reasonable theory of analytics. They are how good analysts work. The pricing model treats them as expensive because every query touches storage that the platform bills you for.
What the consumption bill actually contains
Pull a sample month from any large enterprise Snowflake account and the line items break down approximately:
- ~40% — production pipelines (ETL, the things you actually expected to pay for).
- ~25% — BI-tool refresh (Tableau / Power BI / Looker hitting the warehouse on a schedule, often more aggressively than necessary).
- ~20% — ad-hoc analyst exploration (the value-creating work).
- ~10% — failed queries, abandoned sessions, retries.
- ~5% — "what is this?" debugging that nobody can attribute.
The 20% that represents the value-creating work is the slice that consumption pricing makes structurally expensive at the per-query margin. The other 80% is either fixed-shape work that would be cheaper on a flat-rate plan, or pure waste.
What per-user pricing actually optimises
Per-user-per-month flips the incentives entirely. The analyst's marginal query is free. The marginal user is the cost.
The behaviours per-user pricing rewards:
- Curiosity. The analyst runs the question, sees the result, runs the follow-up. No internal cost calculation.
- Sharing. Five people can re-run the same query without anyone flinching.
- Exploration. The 50TB row-count query happens. Nobody cares.
The behaviours it disincentivises:
- Hoarding seats. Per-user pricing creates pressure to deactivate unused accounts.
- Treating tools as universal. A team of 200 isn't going to pay for 200 seats when only 30 actually use it — they'll find the 30 power users and concentrate access.
- Tool sprawl. Adding another per-user tool to the stack now has a visible recurring cost. People resist the third-tier overlap they might have tolerated before.
Where the math actually lands
The shortcut math we run in TCOIQ engagements for "consumption vs per-user" on a typical mid-market data team:
- Annual Snowflake-style consumption bill for a team of 40 analysts doing real interactive work: USD 180k–420k, depending on the data volume and how much exploration the team actually does.
- Per-user data-tool layer at USD 60/user/month for the same 40 analysts: USD 28.8k/year.
- The warehouse storage doesn't go away — you still need somewhere for the data to live. But the query layer either moves to a self-hosted engine running over storage you already have, or to a per-user data agent that pushes queries down to whatever storage you have, without an interpolated consumption tier in the middle.
The numbers will be different for every customer. The pattern is consistent: the interactive analytics layer becomes 60-85% cheaper on per-user pricing.
What you give up
To be honest about the trade-offs, per-user data tools cost you three things:
- Linear scalability of query compute. If your team genuinely needs to throw 200 nodes at a single query, you're back in consumption-pricing territory. Most teams don't.
- The vendor's optimiser working on your behalf. Snowflake's micro-partition pruning is genuinely good. A self-hosted alternative running DuckDB or Trino has to do that work itself.
- The single throat to choke. Per-user tools tend to be smaller vendors. If you need a 24/7 enterprise support contract, the answer set is narrower.
These trade-offs matter for a specific subset of customers. They matter less and less for the median enterprise data team in 2026.
How we priced Wekams Lens
This is why Wekams Lens is priced flat. Community edition is free, Pro is USD 60/user/month, Enterprise is a fixed annual. There is no per-query tier. The compute happens on the customer's hardware. The cost of an analyst running 10 queries or 10,000 queries is the same.
That isn't a coincidence; it's the strongest argument for the self-hosted architecture. Once the LLM and query engine are running on your hardware, the marginal cost of a query is electricity. Charging the customer for that electricity by the query would be perverse.
The point isn't that consumption pricing is wrong; it's the wrong default for the interactive-analytics use case that has come to dominate how enterprise teams actually use a data platform. Run the math against your own usage. The number is usually bigger than the platform's brochure suggests.