What is energy per query?
Energy per query is a cost metric for search: how much electrical energy — typically reported in joules per completed request, or as queries per watt — the system consumes to answer one vector query at a stated recall and load.
Why report energy instead of only latency and QPS?
Latency and throughput tell you whether users wait and how many they can serve. They do not say how expensive that service is in power draw, thermal budget, or cloud electricity. Two configurations can hit the same p99 and QPS while one burns far more CPU cycles — for example a high-ef walk on full-precision vectors versus a quantized walk that does cheaper distance math. At fleet scale, joules per query translate into rack power, cooling, and carbon accounting. For research comparisons, energy also resists some forms of cherry-picking: a machine that looks “fast” only because it uses many hot cores may lose on joules per successful recall@k. Serious ANN methodology lists energy alongside recall, latency, QPS, distance computations, and memory when the instrumentation is available.
Most of that energy is spent where the algorithm spends CPU time.
What dominates energy for an HNSW query?
Profiling commonly attributes on the order of half of HNSW query CPU to distance and similarity kernels. Each comparison moves bytes through caches and ALUs; more dimensions, higher ef, denser graphs, and filter strategies that visit more nodes all raise the energy bill roughly with arithmetic work. Memory traffic matters too: cold cache fills and disk-backed vector fetches cost joules beyond pure FLOPs. Object hydration and network serialization add end-to-end energy that pure in-process ANN benches omit. Idle baseline power of the host should be separated from incremental query power when possible — otherwise a lightly loaded box attributes rack overhead to every sparse request. Concurrent QPS/watt measurements under saturation often better reflect production efficiency than single-query joules on an otherwise idle machine.
Algorithm and systems choices move energy the same way they move distance-computation counts.
How do index settings and compression change energy per query?
Raising search depth buys recall with more comparisons — and more energy — per request. Lowering depth saves joules but may miss neighbors, which can force product-side retries that waste energy elsewhere. Quantization and binary-friendly metrics shrink bytes per comparison so the same wall-time budget examines more candidates, often improving the joules-versus-recall curve. SIMD-optimized distance kernels finish the same arithmetic with fewer cycles, cutting energy at fixed recall. Indexes that keep working sets in RAM avoid repeated DRAM/disk energy on hot paths; undersized caches thrash and inflate joules. Batching queries can improve hardware utilization (better QPS/watt) even when per-query latency rises slightly. Build-time energy is a separate ledger: a costly high-quality graph may reduce query energy for months of serving.
Weaviate workloads illustrate the same levers even when joules are not a published column.
How does Weaviate relate to energy-aware tuning in practice?
Weaviate’s performance story centers on CPU-bound vector search, distance kernels that dominate profiles, and compression modes that cut memory movement and arithmetic width — all direct inputs to energy per query. Resource limits (GOMAXPROCS, memory caps) bound how much hardware a process may burn. Choosing lower query ef when recall allows, enabling quantization after validating quality, and right-sizing hot caches are the operational paths to fewer joules per answer. Hybrid and filtered plans that double work (keyword plus vector, or expensive allow-list walks) raise energy unless they replace a worse multi-query application pattern. When comparing hardware generations or instruction sets, prefer QPS at fixed recall per watt over raw QPS alone so faster chips are not mistaken for free energy.
Measure carefully so the metric stays honest.
How should you measure energy per query in a benchmark?
Use platform power interfaces or a metered PDU; sample during a warm, steady load at fixed recall, concurrency, and k. Compute joules as integrated watts over the interval divided by completed queries, or report sustained QPS/watt. Subtract or separately report idle baseline. Hold dataset, metric, dtype, and HNSW parameters constant when comparing code paths. Pair energy with distance computations per query — they should move together if the bottleneck is arithmetic. Document CPU model, memory config, and whether timings include network and object fetch. Treat energy as one axis of the Pareto surface next to recall and latency, not a single headline number.
Energy per query turns “how fast?” into “how costly to run at this quality?” — essential once search fleets are large enough that power is a first-class constraint. Next, read “What is the difference between a cold cache and a warm cache?” because cache state swings both latency and joules, then “What is the difference between a singleton query and a batch query?” to see how batching changes energy efficiency under load.