Measured, not implied

Query engine benchmark results, with the boundaries included.

A reproducible record of our local NeuronsDB versus Trino tests. It includes matched workloads, row-data parity, resource results and the limits of what these numbers establish.

Updated 29 July 2026

Headline run on 28 July 2026

247 matched workloads. Every result checked.

15.1×geometric-mean p50 speedup
91.9×lower peak memory
246/247p50 workload wins
247/247matching row results

This sequential local run compared NeuronsDB with single-node Trino against the same fixture sources. It recorded 1,727 measured executions per engine and zero execution errors.

How to read the result

Evidence for this workload set, not a universal claim.

The 15.1× value is the geometric mean of the Trino-to-NeuronsDB p50 latency ratio across all 247 comparable workloads. NeuronsDB recorded a lower p50 on 246 workloads. The only loss was workload 117, a PostgreSQL correlated subquery.

Correctness was evaluated separately from speed by comparing normalized results for every workload. All 247 comparisons matched in this run. The harness supports a row-count fallback for large Arrow results. That parity check matters. A fast response is not useful if it answers a different question.

What this does not prove

This is an internal lab result, not a third-party certification, TPC benchmark or distributed-cluster result. It should not be read as “NeuronsDB is always faster than Trino.” Performance changes with data scale, query shape, connector, concurrency, hardware and deployment topology.

Resource observation on 28 July 2026

Lower peak engine memory in the same local run.

NeuronsDB worker178.1 MB
Trino container2,208.8 MB

The observed difference is 91.9%. This comparison measures the two engine processes in that run. Source-database containers are excluded. Memory was sampled every 0.5 seconds and is directional rather than a controlled infrastructure-cost claim.

Methodology

What was held constant.

  • The same 247 workload definitions
  • The same seeded fixture sources
  • Sequential engine execution
  • Per-workload p50 and p95 latency comparison
  • Normalized result checks with a large-result row-count fallback
  • Engine-only memory from the same run

The workload set includes single-source operations, aggregations, filters, joins, windows and cross-source query shapes. Raw results preserve each workload’s timing, errors, row count and available process measurements.

Provenance boundary

The result JSON does not embed hardware, cache-mode, environment-variable or immutable build provenance. Those details should accompany the next externally reproducible run.

Raw evidence

Download the machine-readable run.

Complete latency, correctness and resource runJSON file, 233 KB, published 28 July 2026

The SHA-256 checksum should be retained with any redistributed copy so the source artifact can be verified.

28 July artifact
1cc147b94164c528d385ee6bab1e698195ec017b833ed6e7daff6621ac24b8a5

Your workload matters more

Test the query shapes your team actually runs.

Bring a representative workload to the private preview. We’ll measure correctness, latency and resource use with the boundaries visible.

Join our waitlist