Two cloud databases, two cost models, one very different bill

Comparing managed databases usually starts with a feature matrix. Features rarely decide it. What decides it, months later, is that the two products charge for fundamentally different things — and the workload you actually have suits one model and punishes the other.

Two examples make the point, because they sit at opposite ends: a document database billed on provisioned throughput, and an analytical warehouse billed on data scanned per query.

Provisioned throughput: you pay for capacity, present or not

In the throughput model you reserve a level of capacity, expressed as request units per second. Each operation consumes units according to how much work it is — item size, indexing, consistency level, whether you are reading a single document by key or running something broader.

The consequences follow directly:

• Cost is driven by peak, not average. Capacity must cover your busiest moment or requests get throttled. A workload spending most of the day idle and spiking at month-end pays for the spike all month unless autoscale is configured, and autoscale has its own floor.
• Cost is predictable. You know the bill before the month starts. For finance, that is worth a great deal.
• Small, frequent, key-based reads are cheap. This model rewards exactly the access pattern an application has: fetch this document, update that one, thousands of times a second.

Estimating it means knowing your operation mix and item sizes — not your total data volume. A terabyte sitting still costs storage and nothing else.

Per-query-scanned: you pay for the questions you ask

The analytical model inverts this. There is no capacity to reserve. You are billed for the bytes a query reads, plus storage.

• Cost is driven by query shape. SELECT * across an unpartitioned table scans everything and bills for everything. The same answer from a partitioned, column-pruned query can cost orders of magnitude less. The query, not the data, is the cost centre.
• Idle is genuinely free. No queries, no compute charge. For workloads that run a handful of large analyses a day, this is dramatically cheaper than reserving capacity to sit unused.
• Cost is unpredictable by default. One badly written dashboard on a five-minute refresh can produce a bill nobody forecast. This is the failure mode, and it is worth guarding with quotas from day one.

Estimating it means knowing your query patterns and how much each touches — not your peak requests per second.

The mistake worth avoiding

The trap is estimating both models with the same mental picture of the workload. Teams take the number they know — total data volume — and reason from it. Under provisioned throughput that number is nearly irrelevant to the bill. Under per-query pricing it matters only insofar as queries actually read it.

A more useful exercise, before choosing:

1. Write down the access pattern honestly. Many small key-based operations, or a few large scans? Application traffic or analyst questions?
2. Find the peak-to-average ratio. A flat workload suits reserved capacity. A spiky one is punished by it.
3. Model both with real numbers, using each vendor's own calculator, with your item sizes and your query shapes — not defaults.
4. Ask what happens when someone is careless. Which model fails safely: throttling under load, or a surprise invoice?

The answer is often that these products are not competitors at all. An operational store serving an application and a warehouse answering analytical questions have different jobs, and the pricing models are honest reflections of that. Choosing between them on price alone usually means one of them was never the right tool.

What we would still measure

Estimates are estimates. Both vendors' calculators are good, and both assume you can characterise a workload you may not have built yet. Where the decision is close and the spend material, the only reliable answer is a short pilot on real data with real queries — priced from the actual bill rather than a projection.