Follow an account from signup to activation, model usage, background work, billing, API failures, and database operations. Every lesson runs locally against the same synthetic tables, so joins, release comparisons, and business definitions stay visible.
Reviewed by the Telemetry product team on . Synthetic data contract, join grain, read-only SQL, expected results, and interpretation boundaries. Review standards and ownership
15
connected tables
10953
deterministic synthetic rows
18
guided SQL lessons
Dataset contract
The synthetic account_id connects commercial context to product, reliability, AI, job, and billing outcomes. More specific identifiers connect deployments and declared incidents while preserving the grain inside each workflow. No customer records, prompts, payloads, or credentials are included.
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_eventsJoin only after reducing each fact table to the grain required by the question. 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_namereleaseCollapse requests, attempts, or milestones to the business grain before adding account and revenue context.
The dataset is deterministic, versioned, and large enough for trends and percentiles. It demonstrates logic rather than customer benchmarks.
Every query names the denominator, business decisions, and claims the result cannot support.
SQL dialect compatibility
The browser lab uses DuckDB so the data never leaves the page. Telemetry production queries use Apache DataFusion. The lessons intentionally stay inside their shared SQL surface; when a function differs, use the production 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?
Start with one event table, group durable product milestones into UTC days, and keep successful volume separate from all attempts.
Published 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 the analysis grain and join logic, then replace the synthetic tables with your own stable event names and privacy-approved identifiers. Validate thresholds and commercial definitions with the team that owns them before promoting a query to 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.