Query one account's signups, model usage, jobs, billing, API failures, and database operations. Every lesson runs locally against the same synthetic tables. Inspect the joins and compare results by release.
Reviewed by the Telemetry product team on . We checked the sample data definitions, table joins, read-only SQL, expected results, and what the results mean. Who reviews this page
15
connected tables
10953
deterministic synthetic rows
18
guided SQL lessons
Dataset structure
The synthetic account_id joins account and revenue data to product, reliability, AI, job, and billing results. Deployment and incident IDs link related events without changing what each row represents. The dataset includes no customer records, prompts, payloads, or credentials.
Context dimensions
accountsusersreleasesincidentsDatabase reliability facts
database_operationsdatabase_pool_samplesdatabase_lock_eventsreplication_samplesmigration_runsaccount_id · release · service · incident_idEvent facts
product_eventsapi_requestsllm_requestsjob_runsbilling_eventsservice_eventsBefore joining tables, group each one by the entities you want to compare. For example, aggregate service events by account and incident before adding monthly revenue.
accounts6 rowsOne synthetic SaaS account with the dimensions and recurring revenue needed for customer-impact analysis.
One row per account.
account_idproduct_events21 rowsDurable account and user milestones for activation, adoption, and journey analysis.
One completed product milestone.
account_iduser_idsession_idapi_requests10 rowsCompleted API request events with stable route, release, latency, and customer context.
One completed API request.
account_idrequest_idllm_requests11 rowsNormalized provider usage, estimated cost, retry, and reviewed product-outcome fields.
One completed model request, including provider retries as separate rows.
account_idrequest_idjob_runs7 rowsAttempt-level background-job outcomes with queue and execution timing.
One attempt of a logical background job.
account_idjob_idbilling_events5 rowsSynthetic subscription outcomes for connecting product behavior and reliability to commercial context.
One completed billing lifecycle event.
account_idevent_idusers24 rowsSynthetic users for role, lifecycle, and adoption analysis without personal data.
One row per synthetic user.
user_idaccount_idreleases12 rowsA deployment dimension for comparing service behavior before and after releases.
One row per service release.
releaseserviceincidents2 rowsDeclared incident windows for measuring affected accounts, error volume, and recovery.
One row per declared incident.
incident_idserviceservice_events10800 rowsA 30-day service-event fact table for realistic trend, percentile, release, and incident analysis.
One completed request or background job.
account_idreleaseserviceincident_iddatabase_operations16 rowsNormalized database operations with query fingerprints, releases, latency, and SQLSTATE outcomes.
One completed database operation.
account_idservicereleasedatabase_pool_samples12 rowsPoint-in-time connection-pool pressure, wait time, and acquisition timeouts.
One connection-pool sample.
servicedatabase_namereleasedatabase_lock_events6 rowsResolved lock waits and deadlocks with blocked and blocking operation families.
One observed database lock wait.
servicedatabase_namereleasereplication_samples12 rowsReplica and downstream consumer lag for operational databases, CDC, and search.
One replication-consumer sample.
consumer_namereleasemigration_runs9 rowsApplication database migration executions, including failures and rollbacks.
One migration execution.
servicedatabase_namereleaseGroup requests, attempts, or milestones by the entity you are measuring before joining account and revenue data.
The versioned dataset produces the same rows each time and includes enough data to practice trends and percentiles. Use it to check query logic. It does not measure customer results.
Each query explains what it counts, which decisions it can inform, and what the result cannot prove.
SQL dialect compatibility
DuckDB runs the lab queries in your browser. Telemetry uses Apache DataFusion for production queries. The lessons use syntax both engines support. Where a function differs, use the DataFusion form below before saving a dashboard or alert.
| Use case | Browser lab | Telemetry / DataFusion | Guidance |
|---|---|---|---|
| Time buckets | date_trunc('day', timestamp_utc) | date_trunc('day', timestamp_utc) | Shared syntax; keep buckets in UTC. |
| Conditional counts | SUM(CASE WHEN … THEN 1 ELSE 0 END) | SUM(CASE WHEN … THEN 1 ELSE 0 END) | Shared syntax and explicit denominator. |
| Approximate p95 | approx_quantile(latency_ms, 0.95) | approx_percentile_cont(latency_ms, 0.95) | Function name differs between engines. |
| Safe division | value / NULLIF(total, 0) | value / NULLIF(total, 0) | Shared syntax; cast when integer division matters. |
Which milestones are users completing on each day?
Group product milestones from one event table by UTC day. Count successes and total attempts separately.
Expected result
| activity_day | events | successful_events | active_accounts |
|---|---|---|---|
| 2026-07-01 | 2 | 2 | 1 |
| 2026-07-02 | 4 | 4 | 2 |
| 2026-07-03 | 3 | 2 | 2 |
| 2026-07-04 | 4 | 4 | 1 |
| 2026-07-05 | 3 | 3 | 2 |
| 2026-07-06 | 2 | 2 | 1 |
| 2026-07-08 | 1 | 1 | 1 |
| 2026-07-09 | 1 | 1 | 1 |
| 2026-07-12 | 1 | 1 | 1 |
Keep what each query counts and how it joins tables. Replace the sample tables with your own event names and approved identifiers. Ask the team responsible to check thresholds and revenue definitions before using the query in a dashboard or alert.
Telemetry created this deterministic synthetic dataset for learning, testing, internal evaluation, and examples. You may copy and adapt the rows, schema, and lesson SQL for those purposes. Attribution is appreciated but not required. The dataset contains no customer records and is provided without a performance or business-outcome warranty.