Why Haevek Doesn't Use Consumption Pricing

Charging on a meter is the wrong incentive.

Most data infrastructure vendors charge by consumption. The vendor tracks each query, each compute hour, each gigabyte. At the end of the month they issue a bill for what was used. On the surface it sounds fair: you only pay for what you use.

Falcon, Haevek's distributed compute engine, doesn't work that way. Our customers pay a predictable fixed annual fee. We built the business that way on purpose, and it is worth explaining why.

We charge a fixed annual fee based on a tiered schedule of the maximum number of concurrent cores. A customer picks the capacity they need and pays the same price for the year. They could be running highly tuned workloads or less efficient pipelines they just threw together. It does not affect what they pay us. This is good!

How consumption pricing became the default

Consumption wasn't always how the industry sold software. For decades, companies bought software on subscriptions, licenses, and annual fees — fixed costs. Cloud infrastructure, starting with AWS in the early 2000s, changed that. Once AWS made pay-as-you-go the way to buy compute, similar consumption pricing models appeared for software built on top of cloud infrastructure. Data platforms adopted it especially fast, since usage is easy to meter. By the early 2020s, consumption pricing wasn't just common, it was assumed. New products launched with consumption pricing, and even companies that had built their business on subscriptions came under pressure to switch.

What consumption pricing actually rewards

Consumption pricing rewards customers for being efficient and using less. The customer is incentivized to run as efficiently as possible. But, that means the vendor is rewarded for inefficiency. A company billing by the query, the node hour, or the gigabyte makes more money when your workloads run slower, scan more data, or need more compute. Every optimization you make to your own pipeline is lost revenue for the vendor.

Clusters that sit idle between jobs still bill for the reserved time. Queries that scan an entire table instead of a filtered partition cost more, not less. The incentive isn't for the vendor to make the product faster. It's for the vendor to leave the meter running.

Every optimization you make to your own pipeline is lost revenue for the vendor.

When metering reflects real cost, and when it doesn't

Consumption pricing makes sense for some products because the underlying cost actually is a function of usage. A water utility charges by the gallon because every gallon has to be pulled from a source, treated, and pushed to your kitchen sink. Use more, and the utility genuinely spends more. The meter reflects a real cost.

That's not how most data platforms work. When a customer runs a query against a consumption-priced data platform, the vendor isn't incurring a new marginal cost that scales the way a utility's does. The underlying cloud compute does cost more at higher volumes, but that's largely a pass-through cost the vendor marks up, not one they are absorbing on the customer's behalf. The relationship between treating a gallon of water versus a hundred gallons is direct, while the increased cost of processing a gigabyte and processing a petabyte on the same platform does not rise as directly. The actual cost structure does not require consumption to be profitable. The gallon of water is close to a true variable cost. The data billing model borrows from utilities but is applied to a product where the vendor's own cost structure doesn't actually require it.

That's the part of consumption pricing that doesn't hold up under scrutiny. It borrows the language and logic of utility billing, pay for what you use, without the underlying economics that make utility billing fair in the first place. For a lot of vendors, consumption pricing isn't reflecting their costs. It's a convenient way to capture more revenue as a customer's usage grows, dressed up as fairness.

Why we priced Falcon differently

Falcon customers pay a fixed annual fee based on the maximum number of concurrent cores used, starting at 64 cores for tier 1. Another advantage to our pricing is that it easily separates our licensing from your infrastructure decisions. Falcon can be run in a variety of conditions — on premises, cloud, air gapped, or edge.

We charge a fixed annual fee by throughput tier because we wanted our incentives pointed at the thing customers actually care about: Falcon running fast and efficiently on their data. If we billed by usage, every improvement we made to query performance would shrink our own revenue. Under fixed pricing, we get paid the same either way. Our customers want it fast, so we make it fast. Our customers want it efficient, so we make it efficient. That's the incentive we'd rather build a company around.

Our customers want it efficient, so we make it efficient. That's the incentive we'd rather build a company around.

Customers like that. They also like the predictability. A consumption bill can be filled with surprises. At the speed of today's businesses, usage can skyrocket. They are hard to forecast: Data volume grows, a new team starts running queries against the same cluster, a job that used to run once a day starts running every hour. A fixed annual fee based on capacity means a customer knows the cost of running Falcon before they sign, not after a surprise invoice.

What this means for a customer

Don't get us wrong; consumption-based pricing is not bad faith or fraudulent. We just wanted to build our company on the best incentives, and the tiered model works best for us. Fixed pricing points us toward the outcomes that customers really want. A customer evaluating Falcon against a consumption-priced alternative isn't just comparing two numbers (although we do reduce our overhead costs pretty significantly). They're comparing what each vendor is incentivized to optimize for.

If you're currently on a consumption-priced platform and want to know what a fixed-price alternative would actually cost, the Falcon Test Flight runs your workloads against Falcon on your own data before any commercial conversation.