Build the capacity you need. Prove what it costs.
Enter the operations per second each engine has to serve, the data you keep and a price basis. The calculator turns them into cores, nodes and dollars a month, using the throughput per core that Loams measured and prices you can check. Every assumption is on this page, and each default links to its source. These are estimates from single-node preview benchmarks: they show how efficiently the engines use a core today, not what a production cluster will cost you.
The throughput and the three price bases are those of the engine repository's cost-per-operation report (#1584). That report counts one vCPU as one core and leaves out PUE; this calculator defaults to two Intel vCPUs per core and a PUE of 1.54, so the report's figures are the optimistic case here. Tick "Count each vCPU as a benchmark core" and set PUE to 1 to reproduce them.
Your workload
Estimates from single-node preview benchmarks
Estimate from single-node preview benchmarks (2026-10-29). Not a quote, not a measured cluster.
| Engine | Your ops/s | Ops per busy core/slow · central · high | Corescentral (range) | $ per 1M opscentral (range) |
|---|---|---|---|---|
| KVkv-tikv slot | 20,000 | 5,816 · 5,816 · 7,336 | 6.885.45 to 6.88 | $0.00426$0.00338 to $0.00426 |
| Postgrespg slot | 10,000 | 30,402 · 47,197 · 93,545 | 0.420.21 to 0.66 | $0.000525$0.000265 to $0.000815 |
| SQL (TiDB)sql slot | 5,000 | 5,802 · 32,000 · 32,000 | 0.310.31 to 1.72 | $0.000775$0.000775 to $0.00427 |
| Househouse slot | 10 | 23 · 23 · 23 | 0.860.86 to 0.86 | $1.07$1.07 to $1.07 |
| Streamsiggy slot | 20,000 | 12,937 · 211,900 · 324,775 | 0.190.12 to 3.09 | $0.000117$0.0000763 to $0.00192 |
| Durabledurable slot | 200 | 636 · 684 · 1,830 | 0.580.22 to 0.63 | $0.0362$0.0135 to $0.039 |
- Cores = ops/s ÷ ops per busy core ÷ target utilisation (50 %) × copies (1). Nodes round the sum up to whole 8-core nodes; real engines also need memory and may not share a node.
- $ per 1M ops = $0.0892 per core-hour ÷ (ops per busy core × 3,600) × 1,000,000, at 100 % busy: the engine repository's cost-per-operation formula.
- Low ops per core: the worse of depth 1 and depth 16, as if your clients cannot pipeline. High: the server-only figure where the cost report measured one (Postgres, streams, durable: the load generator's share removed), otherwise the better of the two depths. All three are measured.
- Not counted: bucket requests, egress, disks, load balancers, support and your time. Loams itself is Apache-2.0 and free.
- The engine repository's cost report uses the same throughput and prices but counts one vCPU as one core and leaves out PUE, so its dollar figures match this calculator with "Count each vCPU as a benchmark core" ticked and PUE set to 1: its numbers are the optimistic case here.
An estimate, not a quote. The throughput comes from one benchmark on one laptop, with every engine running at once; nothing here was measured on a cluster, on server hardware, or over a real network. Prices are list prices for one region, without taxes, support, credits or negotiated discounts. The method and its limits are in Prove what it costs. For the cloud bill of a small self-hosted stack, see What your ground costs.
Ops per busy core, from one combined run.
The BQ1 combined run of 2026-10-29 (engine commit c4760980c) ran every engine at once on one laptop: Intel Core Ultra 5 225H, 14 cores without SMT, 15 GB RAM, local NVMe, loopback networking. Each engine and its load generator were pinned to their own cores, each depth ran for 60 seconds, and every figure is the mean of two runs that agree within 2 % on the totals. "Busy cores" is measured CPU time, including the engine's share of its load generator.
| Engine (slot) | API and operation | QPS, depth 1 / 16 | Per busy core, depth 1 / 16 | Server only, depth 16 | Caveat |
|---|---|---|---|---|---|
| KV (kv-tikv) | loams-kv Store on TiKV (one store, API v2 keyspace): get and put | 8,436 / 6,282 | 7,336 / 5,816 | – | One TiKV on one core, shared with the SQL slot, which took it at depth 16: throughput fell from depth 1 to 16 and p99 reached 1.5 s. |
| Postgres (pg) | PG wire to stock Postgres 17.10 compute: point-select | 55,940 / 93,451 | 30,402 / 47,197 | 93,545 | Stock Postgres 17.10 compute only. The Loams Postgres pageserver and safekeeper were not on the machine. Reads only; one writer per database. |
| SQL (TiDB) (sql) | MySQL wire to keyspace-mode TiDB on TiKV: point-select (depth 16: IN list of 16 ids) | 7,630 / 33,920 | 5,802 / 32,000 | – | Depth 16 batches 16 ids into one IN list. One TiKV core, shared with the KV slot, and PD’s timestamp oracle are the first limits. |
| House (house) | ClickHouse native TCP to the House (chDB worker): point query | 20 / failed | 23 / n/a | – | Provisional. One query at a time per chDB worker; at depth 16 one query failed and the run recorded 0. A point query is not an analytical scan, so this says little about real House workloads. |
| Streams (iggy) | Iggy native TCP: produce (depth 16: 16 messages per batch) | 15,784 / 216,138 | 12,937 / 211,900 | 324,775 | Produce only; consume was not measured in this run. Batching is most of the depth-16 figure: unbatched produce is about 16× more expensive per message. |
| Durable (durable) | Resonate HTTP on SQLite: promise.create | 506 / 534 | 636 / 684 | 1,830 | Bound by I/O, not CPU: every create is its own SQLite commit, with no group commit yet. p99 grows to seconds at depth 16. |
| KV (kv) | loams-kv Store, in-process, in-memory redb: get and put (about 93 % gets) | 27,109 / 52,984 | 54,218 / 105,969 | – | In-process: no network and no wire protocol. Puts serialise on one embedded committer (p50 21 ms at depth 16). |
- Report: docs/benchmarks/2026-10-28-1b-qps/combined.md. Raw results, per run, with p50, p99 and p99.9: bench/results/bq1/all. Harness and core budget: bench/all.
- Every per-core figure is the one in the cost-per-operation report, which computes it from the same raw results. "Server only" removes the load generator's share; the report measured it for engines whose server ran on cores of its own.
- Not in the calculator: the gateway (67,616 HTTP/2 requests per busy core), the meter gate, graph and git slots. RisingWave did not fit the run's memory budget.
Each default, and where it came from.
The three price bases of the cost-per-operation report: AWS c7i on demand, a 3-year EC2 Instance Savings Plan for c7i with no upfront, and an owned mini PC. AWS prices were read from AWS's public price lists, published 2026-10-28. The bucket prices are shared with the /cost calculator. The owned-hardware default is a mini PC with the benchmark laptop's own CPU, so the measured throughput per core applies without converting between processors; a rack server will differ. Defaults no one publishes are labelled as assumptions.
| Item | Value | Per | Read on | Source |
|---|---|---|---|---|
| c7i.4xlarge on-demand | $0.714 | hour, Linux on-demand, us-east-1 (8 × c7i.large at $0.08925). from the price feed the on-demand page renders from, published 2026-10-28 | 2026-10-29 | aws.amazon.com |
| c7i.4xlarge 3-year Savings Plan | $0.31435 | hour, EC2 Instance Savings Plan, c7i, 3 years, no upfront, us-east-1 (c7i.large: $0.03929). AWSComputeSavingsPlan offer file, published 2026-10-28, rate code D2YVZHPR4MTDUCJY.MDCEERAZ4UHT28VS | 2026-10-29 | aws.amazon.com |
| S3 Standard storage | $0.023 | GB-month, first 50 TB | 2026-10-23 | aws.amazon.com |
| Cloudflare R2 storage | $0.015 | GB-month | 2026-10-23 | developers.cloudflare.com |
| Owned server | $612.93 | Gigabyte BRIX GB-BRU5-225H barebone (Core Ultra 5 225H, 14 cores), no RAM or SSD. AVADirect list price | 2026-10-29 | www.avadirect.com |
| Owned server draw | 100 W | watts, the barebone’s power-supply rating (20 V, 5 A), used as an upper bound on its draw | 2026-10-29 | www.avadirect.com |
| Electricity | $0.1447 | kWh, US average commercial retail price, August 2026. EIA Electric Power Monthly, table 5.6.A | 2026-10-29 | www.eia.gov |
| PUE | 1.54 (verify) | power usage effectiveness, global average. Uptime Institute Global Data Center Survey 2025, as reported in its summaries | 2026-10-29 | intelligence.uptimeinstitute.com |
| Owned server parts and life | $250 | Memory and SSD for the barebone, and a 3-year straight-line life. Assumptions, not quotes: replace them with yours. | – | assumption |
Raw feeds: on-demand and Savings Plans (look for BoxUsage:c7i.4xlarge), and the cost report's prices.toml. A vCPU on an Intel instance is one hardware thread, so by default 16 vCPUs count as 8 benchmark cores. Found a price that changed? Open an issue.
Efficiency per core, not a cluster bill.
Read the range, not the central figure, and read the caveats before either.
- Linear scaling is assumed: 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).
- The benchmark machine is a laptop with loopback networking. Server cores are usually faster; a real network adds cost that loopback hides. Neither is in the range.
- Memory, disk and network limits are not modelled, only CPU. The run capped memory at about 8 GB for every engine together.
- The House figure is a point-query number from a chDB worker that runs one query at a time. It is shown because the House is part of the platform, not because it predicts analytical cost.
- Durable execution is bound by commits to disk, not by CPU: every promise is its own SQLite commit, with no group commit yet. That is why its figure is low, and the report names group commit as the first fix.
- Prices change. Each has a date; re-check the source before you rely on it.