Resource costs

Shared price assumptions

One common price model for every engine. These are monthly resource equivalents, not measured cloud bills or cost per query. The first table weights CPU by measured work; the second keeps the always-on capacity reference. Each total-cost column uses its own lowest complete total as 1.00×. The separate CPU ratio uses the lowest positive observed CPU time. Neither is a query-speed ranking.

Cost weighted by measured CPU work

Default scenario: 1,000 repetitions of each engine's recorded resource-sampling window per month, with its observed peak memory and stored data held for the month. CPU is charged only for measured busy time at the rates above. This shows how compute work changes the model even when every engine uses the same size machine.

Different historical sampling windows are not equal amounts of work. Query coverage and background activity differ, so these projections cannot establish an overall engine ranking.

CPU work cost = aggregate CPU seconds ÷ 3,600 × $0.04 × selected windows.
scenario total = CPU work cost + peak GiB × memory rate × selected hours + stored-footprint multiple × (block month + object month).

Why CPU and total ratios differ: the total also includes memory and storage. At low repetition counts, a month of peak memory can outweigh the CPU charge. The CPU ratio compares observed busy seconds only; the total ratio compares the selected scenario.

Increasing stored footprint projects retention cost while holding sampled CPU and peak memory fixed. That scaling has not been measured. Lower memory hours assume the working set can be released between active periods. These controls explore assumptions; they do not establish a winner on equivalent work or prove deployment feasibility.

CPU seconds are summed across all cores by the node sampler, including background work; they are not wall-clock seconds and are not multiplied by core count again. Each run's observation is counted once, even though it is repeated on every query record. Sampling can include warmups, core and edge suites, and other work within the runner's window. Historical windows, repetition counts, supported queries and dates differ: these totals are illustrative resource equivalents, not equal-work cost-per-query rankings. A shorter or incomplete workload can look cheaper. See methodology and the query coverage and caveats before comparing.

This scenario assumes CPU can be billed or shared in exact proportion to busy time; an always-on VM still incurs the capacity cost below. By default it retains peak memory for 730 hours and storage for a month, excludes idle CPU, and does not prove this workload fits in a month or that any engine can be deployed at this price. Changing repetitions scales only CPU: 100 repetitions costs one tenth of the displayed CPU component; memory and storage stay fixed.

Always-on capacity reference

monthly equivalent = cores × 730 × $0.04 + peak GiB × 730 × $0.0045 + block GiB × $0.08 + object GiB × $0.023. The relative column is normalized within this table, not against the workload scenario above. It is not a performance or capability ranking.

Uses recorded host cores, peak node memory and stored bytes from the same run as each engine's board column. Memory is peak usage, not allocated RAM; storage is occupied bytes, not provisioned volume size. This hybrid model does not establish a deployable instance size or equivalent throughput. It excludes spare capacity, replication, object requests, network transfer, extra IOPS, catalog services and software fees. The workload scenario replaces this CPU capacity charge; the two CPU charges are never added together. Missing inputs remain unassessed. Different rounds and unsupported queries limit comparisons.