Grafana offers special entries in the data-source picker named -- Mixed --, -- Dashboard -- and -- Grafana --. Explain what each one does and what the limits are of combining several sources in a single panel.

## Why special sources exist Most of the data-source picker lists configured connections. Three entries are not connections at all but behaviours built into Grafana, and interviewers ask about them because each one encodes a design decision. ## -- Mixed -- Selecting Mixed changes the panel's query editor: every query row gains its own data-source picker. When the panel runs, Grafana groups the rows by data source and issues **one request per source**, then hands the panel all the returned frames together, tagged by which query produced them. What Mixed does **not** do is combine anything. There is no cross-source query engine and no server-side join. The frames arrive side by side, and any correlation is your job, in the browser, via transformations: - *Join by field* on `time` is the usual move for putting two systems' metrics in one table or computing a ratio between them. - The catch is timestamp alignment. Each data source resolves its own step and its own bucket boundaries, so a join on time matches only exactly equal timestamps and otherwise produces a sparse grid of nulls. Give both sides the same step — a shared min interval, or explicit bucketing in each query — before joining. - Because the correlation happens after both responses have been fetched in full, Mixed is not a way to reduce data movement; it is a way to display things together. Good uses: overlaying an application metric with an infrastructure metric that lives in another system; putting a business number from a relational database next to a time-series metric; comparing the same metric from two regions with separate backends. Limits worth stating: request count multiplies with the number of distinct sources; panels that assume a single source or a single frame shape behave poorly; and features evaluated outside the dashboard have their own multi-query model rather than reusing the Mixed picker — so do not assume a mixed panel translates directly into anything evaluated server-side. ## -- Dashboard -- This one is a load-reduction and consistency feature. A panel set to the Dashboard source does not query anything; it selects another panel on the same dashboard and consumes **that panel's already-fetched result**, then applies its own transformations, field config and visualisation. Two real benefits: 1. **Cost.** A graph and a table of the same data become one query instead of two, and five stat tiles derived from one result become one query instead of five. On a dashboard with a wide time range this is a large saving, and it scales with viewers. 2. **Consistency.** The panels are guaranteed to show the same numbers, because they *are* the same numbers. Two independent queries against a live system can disagree simply because they ran a second apart. Constraints: the source panel must be on the same dashboard, the dependency is invisible unless you go looking (delete or heavily edit the source panel and the dependents break), and the dependent panel inherits whatever range and resolution the source panel used — it cannot ask for something different. ## -- Grafana -- The built-in source. Its practical uses are: - **Generated test data** — random walks and similar — for building or demonstrating a panel before the real data exists, and for reproducing a rendering bug without a backend. - **Static/inline frames**, useful for legends, reference lines or a small lookup table maintained in the dashboard itself. - **Dashboard annotations** — the built-in annotation store scoped to the dashboard, which is what the default "Annotations & Alerts" entry uses. It is also the fastest way to answer "is this Grafana or is this my backend?" during a diagnosis: if a panel renders correctly on generated data, the panel and the browser are fine. ## The judgement an interviewer is testing The underlying point is that Grafana composes results, it does not federate queries. If you find yourself joining large results from two systems in the browser on every dashboard load, the dashboard is doing an ETL job in the wrong place: the durable fixes are to get both datasets into one queryable system, or to precompute the joined result on the backend, and to use Mixed for genuinely occasional cross-system overlays.