18 synthetic input rows in cache_request_events. Timestamps shift into the current query window when the fixture loads.
Results are capped at 500 rows. The included fixtures are synthetic and intentionally small.
No fixture or query is sent to Telemetry.
Published expected result
Query output and visualization
Query result
Cache miss and stampede indicators
Product lookups combine a 50% miss rate with 31 concurrent fills and the higher backend cost.
| cache_key_pattern | requests | hits | misses | miss_rate_pct | maximum_concurrent_misses | average_backend_duration_ms |
|---|---|---|---|---|---|---|
| product:{id} | 10 | 5 | 5 | 50 | 31 | 232 |
| feature-flags:{account} | 8 | 7 | 1 | 12.5 | 7 | 75 |
Synthetic example output. Run the query against your own event schema and thresholds before using it for operational decisions.
What this playground proves—and what it does not
The browser runner proves that the selected read-only query executes against its included rows and produces the displayed result. The browser downloads the versioned DuckDB runtime from jsDelivr only after you run a query; the SQL and fixture are not sent with that request. Telemetry recipes are separately planned with Apache DataFusion, the engine used by Telemetry. DuckDB and DataFusion are distinct SQL engines, so validate any edited syntax with the DataFusion SQL reference before using it in production.