Describe what a data source is in Grafana, and trace what happens from the moment a dashboard panel runs its query until the result is rendered — including where the credentials live and what actually comes back over the wire.
answer
- config record + plugin (editor & translation)
- browser → Grafana server → backing system, never direct
- credentials decrypted server-side, never sent to the browser
- everything returns as typed data frames
- dashboards reference data sources by UID
basics
~20 sA data source is a saved connection (type, URL, auth, options) plus the plugin that knows how to query that system. The browser asks the Grafana server, which attaches the stored credentials, calls the backing system, and returns typed data frames the panel renders.
solid answer
~60 sA **data source** is two things: a stored configuration — type, URL, authentication, per-type options, a name and a stable **UID** — and the **plugin** that supplies its query editor and knows how to talk to that system. When a panel runs, the browser does *not* call Prometheus or your database. It posts to the Grafana server's query API with the data source UID, the queries, the time range, the interval and max data points. The server resolves the data source, decrypts and attaches the stored credentials, calls the backing system (via the plugin's backend, or via Grafana's data-source proxy for frontend-only plugins), and converts the response into **data frames** — tables with typed columns and labels. Those frames come back to the browser, where transformations, field config and the panel renderer turn them into pixels. Two consequences: secrets never reach the browser, and dashboards reference data sources by UID rather than by name, which is what makes them portable — or breaks them when the UID differs between environments.
go deeper
Say what a data source is, that queries go through the Grafana server, and that credentials are stored server-side rather than in the browser.
Add data frames as the uniform response shape, UID-based references, and the Query inspector as the first diagnostic tool.
Draw the authorisation consequence — access is per data source, not per dashboard — and the reachability consequence for network placement of the Grafana server.
Frame the data source as the trust and blast-radius boundary of a Grafana deployment: who may query what, from where, with whose identity.
## The two halves of a data source Asking "what is a data source" in Grafana has a precise answer with two parts. 1. **A configuration record** stored in Grafana's own database (or supplied by server-side provisioning): the plugin type (`prometheus`, `loki`, `postgres`, …), a URL or connection details, authentication settings, type-specific options (scrape interval, default index, TLS material), a human name, a `default` flag, and a **UID** — a short stable identifier. 2. **A plugin**: the code that renders the query editor in the UI, validates the config form, translates a panel query into a request against that system, and converts the response into Grafana's internal shape. A data source is therefore neither "the database" nor "the query" — it is the *named, credentialed connection* plus the translation layer. ## The query path, step by step 1. **A panel becomes visible.** Grafana lazily queries panels as they enter the viewport, so panels below the fold or inside collapsed rows have not fired yet. 2. **The frontend assembles a query request**: the list of query targets for that panel, the data source UID, the resolved time range (`from`/`to` in epoch milliseconds), the computed interval, max data points, and the panel/dashboard identity used for tracing and caching. 3. **It POSTs to the Grafana server's query endpoint.** This is the key architectural fact: the browser talks only to Grafana. It never holds the backing system's credentials and normally never needs network reachability to it. 4. **The server resolves the data source by UID**, checks that the requesting user is allowed to use it, and loads the configuration, decrypting the secure fields. 5. **The server executes.** For a plugin with a backend component, Grafana calls that backend, which issues the request itself. For a frontend-only plugin, Grafana's **data-source proxy** forwards the HTTP request, injecting the configured authentication (basic auth header, bearer token, custom headers, client certificate) on the way through. 6. **The response is converted into data frames.** A data frame is a table: named, typed fields (time, number, string, boolean), each with optional labels and display metadata, grouped into frames with a refId identifying which query produced them. This uniform shape is why one panel type can render results from a time-series database, a log store and a relational database. 7. **Frames return to the browser**, where the panel applies transformations, then field configuration and overrides, then renders. ## Why this matters practically **Secrets.** Because step 4 happens server-side, credentials stay on the server. Grafana stores sensitive fields encrypted and the configuration API never returns them — you can overwrite a password, but you cannot read it back. Anyone claiming the browser holds the database password has the architecture backwards. **Reachability.** Only the Grafana server needs a route to the backing system. That is what lets Grafana sit in front of systems that are not exposed to users' browsers at all. **Authorisation.** Because every query is addressed by data source UID, permissions attach to *data sources*, not to dashboards. A user who can reach a data source can run queries against it, whatever the dashboards show. **Portability.** Dashboards store the UID (plus type) of the data source each panel uses. Two Grafana instances with "the same" Prometheus but different UIDs will fail to resolve an imported dashboard's panels, which is the single most common import failure. **Observability of the path itself.** The panel's **Query inspector** exposes the request Grafana sent, the raw response, response size and timing — the first tool for any "my panel shows no data" question, because it tells you whether the emptiness came from the backing system or from something Grafana did to the query. ## The common failure modes this model explains - *Panel says "Data source not found"* → the UID referenced by the panel does not exist on this instance. - *"Save & test" passes but panels are empty* → the health check proves reachability and credentials, not that your query matches any data or that the time range covers it. - *A query works in the backing system's own UI but not in Grafana* → compare the request in the Query inspector; Grafana substituted a time range, an interval and possibly macros. - *A user sees data they should not* → data-source-level access, not dashboard-level access, is what governs that.
- A panel shows 'Data source not found' after importing a dashboard from another environment. What happened?The dashboard's panels reference a data source by UID, and no data source with that UID exists on this instance — even if an equivalent one is configured under the same name. The fixes are to give the equivalent data source the same UID in every environment, to use a data-source variable so the dashboard is source-agnostic, or to remap the reference during import.
- Where do you look first when a panel returns no data but the backing system clearly has the data?The panel's Query inspector: it shows the exact request Grafana sent, including the substituted time range, interval and any expanded macros, plus the raw response and its size. That immediately separates 'Grafana asked a different question than you think' from 'the backing system genuinely returned nothing', which are the two possibilities.
A data source is like a saved connection profile in a database client: the profile holds the address and the credentials, the client knows the dialect, and you write queries against the profile — not against a raw socket.
saying these in an interview costs you the question
- Believing the browser connects directly to Prometheus or the database
- Thinking the data source's password is delivered to the frontend and could be read from the page
- Assuming dashboard permissions restrict what data a user can query
- Saying 'Save & test' proves the queries will work
- Describing data sources as being referenced by name rather than by UID