Explain what Grafana panel transformations are, where in the query lifecycle they execute, and when you should push the same work into the query instead of doing it as a transformation.

## Where transformations sit The lifecycle of a panel render is: query options are resolved (time range, interval, max data points) → the data source returns **data frames** → **transformations** run in order → **field configuration and overrides** are applied (units, thresholds, mappings, display names) → the panel draws. Transformations therefore see raw frames and hand shaped frames to the visualisation. They cannot influence the query, and they cannot see anything the query did not return. They are stored per panel. Two panels needing the same reshaping duplicate the pipeline; there is no shared transformation library. This is a real maintenance cost on large dashboards and is a legitimate argument for fixing shape at the source instead. ## The pipeline model The list is ordered and each entry consumes the previous entry's frames. Order changes results, which is the single most common source of confusion: - *Filter by value* then *Reduce* summarises only the surviving rows; the reverse order summarises everything and then filters summaries. - *Join by field* before *Organize fields* means you rename the joined columns; after, you rename the pre-join ones (and your renames may vanish). Grafana shows the frames entering and leaving each stage in the transformation editor's debug view, and the panel inspector's Data tab shows the final result — that pair is how you actually debug a pipeline rather than guessing. ## The stages that matter - **Join by field**: an outer or inner join on a shared field, almost always `time`. This is how you put two queries in one table, or compute a ratio between two series. Beware: joins on time only align rows whose timestamps are byte-identical, so two queries at different steps produce a sparse, null-riddled table. Aligning the step (min interval, or the same interval macro) is the fix. - **Organize fields**: rename, hide, reorder. Purely cosmetic, but it is what turns a raw SQL result into a readable table. - **Reduce**: turn each series into one row of statistics (last, mean, max, count). This is how you build a "current value per instance" table from time-series data. - **Filter data by query / by name / by value**: keep one query's frames, keep matching fields, or keep rows matching a predicate. Filter-by-value is row-level and runs in the browser, so it is a display filter, never a security or cost control. - **Labels to fields / Group by / Partition by values**: reshape between the *long* form (one row per timestamp+label combination) and the *wide* form (one column per series) that most panels prefer. Many "this panel refuses my data" problems are exactly a long/wide mismatch. - **Add field from calculation**: binary maths between two fields (a ratio, a difference), a unary function, or a row-wise reduction. Useful when the backend query language cannot express the arithmetic across two separate results. - **Config from query results**: use one query's output to set another's display config — data-driven thresholds, units or display names. ## Cost and where it lands Everything here happens in the browser tab, on data already transferred. That gives three practical rules: 1. **Transformations never reduce load on the backend or on the network.** A panel that fetches 200k points and reduces them to 12 rows still fetched 200k points. 2. **Cost scales with points × series.** Heavy pipelines on wide results are a common cause of a dashboard that is slow after the requests have finished. 3. **They are per-viewer.** The same reduction is recomputed in every open browser, whereas a backend aggregation (a `GROUP BY`, a `sum by`, a recording rule) is computed once and cached. ## Push-down decision Do it in the query when the backend can express it: aggregation, label/dimension filtering, top-N, time bucketing, downsampling, arithmetic within one query. Do it as a transformation when the backend cannot: correlating **separate** queries, correlating **different data sources**, cosmetic field work, converting between long and wide, and shaping a result specifically for one panel type. One boundary worth naming explicitly in an interview: transformations are a *visualisation-time* feature and belong to the dashboard. Server-side evaluation — for example alert rules — uses its own expression pipeline rather than panel transformations, so a reduction you rely on in a panel does not exist for anything evaluated without a browser.