Skip to content

CONCEPT Cited by 3 sources

Bursty query pattern

Bursty query pattern is a workload shape where reads concentrate into short, high-intensity bursts rather than flowing at a steady rate. It's most common in incident-driven telemetry stores — dashboards, logs, traces, and especially continuous profiles — where operators open the UI during an outage and fire dozens of queries in minutes, then leave it alone for hours or days.

Why it's architecturally significant

A bursty workload breaks capacity-planning intuitions designed for steady-state traffic:

  • Steady-state p99 sizing overbuilds. Provision for peak-burst QPS and you pay for that capacity 99% of the time when it's idle.
  • Provision for average and you fall over during incidents — precisely when query performance matters most for root-cause.
  • Coupled read/write tiers amplify the problem. If the same nodes serve writes and reads (as in Cortex- era observability DBs), a read burst steals capacity from the always-on write path.

The Pyroscope 2.0 framing

The Pyroscope 2.0 launch post names bursty query patterns as one of three traits that drive profiling-DB design:

"Pyroscope 2.0 applies similar architectural principles, adapted for the unique characteristics of profiling data: large payloads, heavy symbolic information, and bursty query patterns."

(Source: sources/2026-04-22-grafana-introducing-pyroscope-2-0)

Continuous-profiling queries are bursty by nature: profiles are queried heavily during incidents, barely at all between them. A metrics-style steady-state read-path sizing wastes capacity; a direct copy of Mimir's metrics read-path design won't fit profiling well.

Architectural responses

Systems built for bursty reads tend to converge on:

  1. Decouple reads from writes at storage layer. Independent tiers scale independently; a read burst can't starve the write path.
  2. Object storage as the primary read substrate. Object stores handle bursts well — very high aggregate throughput, each request pays only for what it reads.
  3. Cache the recent hot data. Most incident queries are "the last hour" — a small hot cache in front of object storage absorbs the typical burst without touching cold storage.
  4. Scalable query workers. Stateless query nodes that can be added to handle a burst, retired after.

Seen in

  • sources/2026-05-20-databricks-marketing-campaigns-with-lakebase — Marketing-campaign customer segments as the canonical bursty-OLTP instance. Verbatim: "customer segments used for personalized campaigns are often stored in an OLTP database from which marketing tools read them. When marketing campaigns are launched, there is a spike in database requests, but otherwise, database utilization is low." Concrete production sizing: scale-to-0 → 16 CU (~32 GB RAM) on Lakebase Autoscaling for a Deichmann marketing workload. The architectural justification — "Lakebase autoscaling speed and reactivity eliminate the risk of resource underutilization" — makes generous max-cap sizing safe because sub-second scale-down bounds the underutilisation risk by reactivity rather than by min-max gap. Generalises the pattern from observability-DB read-bursts (Pyroscope) and agent-workflow combined write+read bursts (LangGuard) to a third altitude: operational-OLTP read-bursts driven by scheduled business events — campaigns, batch triggers, business-hour traffic shapes. The "modelling-freedom" payoff ("the number and diversity of customer attributes can increase significantly without requiring additional compute resources") makes this an architectural argument for storage-compute separation rather than just a cost- optimisation argument.

  • sources/2026-04-27-databricks-inside-one-of-the-first-production-deployments-of-lakebase-langguard — LangGuard's agentic-workflow trace+enforcement workload as a bursty-query instance at a new altitude (runtime governance of agent actions, not telemetry dashboarding). The LangGuard team names the shape explicitly: "Agent behavior is notoriously bursty. An agent workflow might be completely dormant for hours and then suddenly generate hundreds of trace writes and enforcement reads in a matter of seconds." This extends the concept beyond the Grafana/Pyroscope read-burst framing to a combined write-burst + read-burst shape: trace writes and enforcement reads arrive in the same burst window, both must land on hot-indexed state, and the substrate must scale to zero between bursts. The architectural response LangGuard adopts is systems/lakebase's serverless Postgres (see concepts/scale-to-zero + concepts/compute-storage-separation) — a distinct answer from the observability-DB rearchitecture Pyroscope 2 adopts, because the workload demands OLTP-shape low-latency indexed lookups rather than OLAP-shape scans.

Last updated · 542 distilled / 1,571 read