Prove what it costs

Infrastructure costs money every hour it runs, so how efficiently a data platform uses its hardware matters as much as what it can do. A claim about that efficiency is worth something only if it comes with measured numbers and arithmetic anyone can check. This post shows ours.

We built a TCO calculator. You give it a workload: operations per second for each engine, the data you keep, and a price basis. It returns the cores, nodes and dollars a month that workload needs on Loams. Every input can be edited, and every default links to its source. Below are the arithmetic, the measured numbers, and where they stop being true.

What we measuredCopy Anchor Link

On 2026-10-29 we ran every Loams engine at once on one machine. Each engine used its own native API, and each was pinned to its own cores together with its load generator (report, raw results, engine commit c4760980c).

The machine is a laptop with an Intel Core Ultra 5 225H: 14 cores without SMT, 15 GB of memory, local NVMe and loopback networking. Each depth ran for 60 seconds, and the whole run was done twice. The two runs agree within 2 % on the totals.

The engine repository's cost-per-operation report computes the per-core throughput from those raw results, and the calculator uses its figures as they are.

Depth is the number of operations in flight per connection. At depth 1 a client waits for each answer; at depth 16 it pipelines or batches 16. "Busy cores" is measured CPU time, including the engine's share of its load generator. "Server only" leaves the load generator's share out. The report could measure that only for engines whose server ran on cores of its own.

The methodCopy Anchor Link

The calculator works in four steps and shows each one.

1. Cores. For each engine, divide your operations per second by its measured operations per busy core. Then divide by the CPU utilisation you are willing to run at. The default is 50 %, which leaves room for peaks. Finally, multiply by the number of copies you keep for availability. The default is one copy, as measured.
2. Nodes. Add up the cores and round up to whole machines. The cloud node is an AWS c7i.4xlarge with 16 vCPUs. An Intel vCPU is one hardware thread, and the benchmark's cores had no SMT, so by default a node counts as 8 cores. You can count every vCPU as a core instead; the page labels that choice as optimistic.
3. Dollars per million operations. This is the engine repository's formula: $/1M ops = $/core-hour ÷ (ops per busy core per second × 3,600) × 1,000,000. The core-hour price is the node's hourly price divided by its cores.
4. Dollars a month. Multiply nodes by the hourly price and by 730 hours, then add the bucket. The bucket holds your live data plus stream retention (message size × messages per second × seconds of retention), priced at S3 Standard's or R2's list price.

The rangeCopy Anchor Link

One figure would hide most of what we do not know, so the calculator always shows three, all of them measured:

• Central: the pipelined depth-16 figure. The House failed at depth 16, so it uses depth 1.
• Low throughput, so more cores: the worse of the two depths, as if your clients cannot pipeline.
• High throughput, so fewer cores: the server-only figure where the report has one, otherwise the better of the two depths. A production fleet does not pay for its clients' cores.

For streams the range is wide: from 12,937 to 324,775 messages per core. Most of the depth-16 figure comes from batching. The honest reading is that a producer sending one message at a time costs about 16 times more per message.

What it comes toCopy Anchor Link

The calculator offers three price bases, the same three the cost report uses:

• On demand: AWS c7i in us-east-1. A c7i.4xlarge costs $0.714 an hour, which is 8 × the c7i.large price of $0.08925.
• A 3-year plan: the EC2 Instance Savings Plan for c7i, with no upfront payment, at $0.31435 an hour for a c7i.4xlarge. The AWS prices were read from AWS's public price lists, published 2026-10-28.
• Owned hardware: a mini PC with the benchmark's own CPU, so the measured figures apply without converting between processors.
  • A $612.93 barebone (list price), plus $250 of memory and SSD (our assumption).
  • Three years of straight-line life (also our assumption).
  • 100 W, the power supply's rating, at the EIA's August 2026 US commercial price of 14.47 cents per kWh.
  • A PUE of 1.54, the global average in the Uptime Institute's 2025 survey. We read that figure in summaries of the survey and have not checked it in the report itself.

The table shows central dollars per million operations at the calculator's defaults. The calculator shows the ranges.

How this reconciles with the cost report. The cost-per-operation report uses the same throughput and the same three prices, but it counts one vCPU as one core and leaves out PUE. Its figures are therefore the optimistic case here: half our cloud figures, and about 14 % below our owned figures. To reproduce them in the calculator, tick "Count each vCPU as a benchmark core" and set PUE to 1. For example, Postgres at $0.000263 on demand and $0.0000199 owned.

The owned column leaves out what it costs to run a machine: rack space, network, spare parts and people. The calculator has a field for those, and it counts nothing until you fill it in. The owned column is the cost of the hardware and power. The cloud columns include everything the provider bundles into its hourly price.

The calculator's default workload, per second:

• 20,000 KV operations
• 10,000 Postgres and 5,000 SQL queries
• 10 House queries
• 20,000 stream messages of 1 KiB
• 200 durable promises

It also keeps 500 GB of data and seven days of stream retention. On c7i on demand at 50 % utilisation, that needs about 9.3 cores (range 7.2 to 13.8). That is 2 nodes and about $1,339 a month. The 12.9 TB in S3 accounts for $296 of that, almost all of it stream retention. On the owned basis it is one machine and about $337 a month, $296 of it still the bucket.

What the numbers sayCopy Anchor Link

The useful part of the exercise is that it puts a price on each inefficiency. The benchmark report lists the fixes in order.

• KV on TiKV dominates the default bill. It needs 3.4 of the 4.6 busy cores. In this run one TiKV core served both the KV and SQL slots, and SQL's batched reads took most of it. The first fixes the report lists are giving TiKV more than one core and batching timestamp requests.
• Durable execution costs about 70 times more per operation than a Postgres point select. That is because every promise is its own SQLite commit. Group commit is the report's first item.
• The House figure is not an analytical number. A chDB worker answers one query at a time, and at depth 16 the run failed and recorded 0. We show the figure because the House is part of the platform, and we label it provisional.
• Pipelining is a cost lever you control. Per busy core, SQL serves 5.5 times more queries with an IN list of 16 than with one id per round trip. Iggy produces 16 times more messages in batches of 16 than one at a time.

You can only eliminate waste you can measure. Each row above is a measurement you can rerun after a fix.

What it does not showCopy Anchor Link

• It shows efficiency, not product-market fit. A low cost per operation says the engines use a core well on this machine. It says nothing about whether anyone needs those operations, or what they would pay for them.
• It is one node. The calculator assumes n nodes do n times the work. The run did not measure scaling, and each engine has a first shared limit:
  • one Postgres writer;
  • PD's timestamp oracle for TiDB and TiKV;
  • one SQLite commit per durable promise.
• It is a laptop on loopback. Server cores are usually faster, and a real network adds costs that loopback hides. Neither effect is in the range. The laptop's cores are not all one type either: some engines ran on performance cores, some on efficiency cores.
• It models CPU only. Memory, disk and network bandwidth are not modelled. The run capped memory at about 8 GB for all engines together.
• Some engines are partial. Postgres is the stock 17.10 compute, without the Loams pageserver and safekeeper. Streams measured produce only, not consume. RisingWave did not fit the run's memory budget and is absent.
• Bucket requests, egress, disks, load balancers and support are not counted. The cost page estimates those for a small self-hosted stack.

Why there is no comparison columnCopy Anchor Link

The calculator compares Loams only with published list prices, cited and dated. Our Confluent Cloud benchmark measured 62.8 MB/s of produce per Dedicated CKU on all three clouds. But Confluent does not publish a CKU price.

The cost report does make that comparison. Its main case assumes $4.00 per CKU-hour, the figure our benchmark's spending guard used, and it shows $3.00 as a sensitivity case. It labels both as assumptions and lists its caveats. Because the CKU price is assumed rather than published, the calculator leaves it out. When a comparable published price exists, it will go in with its source and date.

We also make no claims about what anyone else spends on infrastructure. The calculator prices your workload, on your hardware or in your cloud account, and nothing else.

Check it yourselfCopy Anchor Link

• The calculator shows each input, each price with its source, and each engine's measured figures and caveats.
• The model is about 500 lines of TypeScript in lib/tco.ts. Its tests pin the results, including the cost report's figures as the optimistic case.
• The cost report's prices are in bench/cost/prices.toml, with each figure's source and label.
• The benchmark harness is in bench/all, and the report explains how to rerun it.

If you find a figure that is wrong or out of date, open an issue. We will fix the number and note the change here.