Telemetry
Evidence before claims

Inspect what is tested—and what is not claimed

This register separates reproducible product evidence from synthetic examples, customer feedback, and workload-dependent performance. Use it to verify the public material or design a benchmark that can support your own decision.

Reviewed by the Telemetry product team on . Public test inventory, claim boundaries, and benchmark protocol. Review standards and ownership

Inspectable inventory

Evidence you can open today

81

typed SQL recipes

Planned and executed with Apache DataFusion 45.2.0.

Inspect the evidence
30

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 each public proof can support

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 outputFixture checked30 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 produce a defensible performance result

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

A result appears here only after correctness reconciliation, complete environment disclosure, raw-result retention, caveat review, and approval for public use. Internal experiments and synthetic SQL outputs are excluded.

Download result templateSubmit a reviewed run

No approved performance result is currently published.

This is an explicit evidence boundary, not a zero result. Use the protocol and template to produce a workload-specific run.

  • 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