Skip to content
Telemetry
Tests and benchmarks

See what we test and what the results mean

Check our SQL tests and sample datasets below. These checks do not measure production performance. Use the benchmark steps to test latency and throughput on your own workload.

Reviewed by the Telemetry product team on . Published tests, what they check, and how to run a benchmark. Who reviews this page

Published tests and datasets

Review the tests and data

84

typed SQL recipes

Planned and executed with Apache DataFusion 45.2.0.

Inspect the evidence
33

fixture-tested recipes

Run against deterministic browser fixtures with expected result checks.

Inspect the evidence
15

versioned lab tables

18 guided lessons use the same downloadable dataset.

Inspect the evidence
20

field-level event contracts

Each contract documents types, privacy guidance, examples, and validation checks.

Inspect the evidence

Claim register

What the tests tell you

ClaimStatusEvidenceBoundary
Published SQL is compatible with the documented schemasMachine checkedEvery recipe is planned and executed against typed empty tables with Apache DataFusion 45.2.0.This proves engine compatibility, not that a business definition fits your data.
Selected SQL examples return the displayed synthetic outputSample data checked33 recipes execute deterministic fixtures and compare expected values within displayed precision.Synthetic fixtures demonstrate behavior; they are not production performance or customer outcomes.
The learning dataset is reproducibleVersioned artifact15 tables and 18 lessons share downloadable SQL, JSON, and CSV data.The dataset is designed for learning and evaluation, not capacity planning.
Telemetry has universal latency, throughput, or cost advantagesNot claimedNo universal performance result is published because workload, schema, retention, concurrency, region, and cache state materially affect it.Run the protocol below against your workload before making a purchasing or architecture decision.

Reproducible protocol

How to run a repeatable benchmark

1

Freeze the workload

Publish the event schema, row count, data volume, cardinalities, time range, query set, concurrency, and expected result shape.

2

Record the environment

Document product version, region, compute tier, retention, network path, cache state, warm-up policy, and client timing method.

3

Separate correctness from speed

Reconcile every query with known fixture output before measuring latency. A fast wrong answer is not a valid result.

4

Run repeated trials

Report trial count, p50, p95, failures, timeouts, ingestion lag, and total test window rather than one favorable request.

5

Publish exclusions and caveats

Identify discarded trials, incomplete buckets, provider limits, configuration differences, and any result the test cannot support.

Published result register

Approved performance runs only

Before publishing a result, we check its correctness, document the environment and limitations, retain the raw results, and get approval to share it. This list excludes internal experiments and synthetic SQL output.

Download result templateSubmit a reviewed run

No approved performance result is currently published.

Use the steps and template to benchmark your own workload.

  • Run identifier, UTC measurement window, and product version
  • Public event schema, event count, byte volume, field cardinalities, and query set
  • Client and service regions, product tier, retention, concurrency, and network path
  • Cache state, warm-up policy, trial count, failures, timeouts, p50, and p95
  • Correctness checks, exclusions, caveats, raw result artifact, and reviewer approval