Grafana: the query and dashboard layer that sits on top of your existing data stores

What Grafana is for, and who ends up running it

Grafana does not store your telemetry. It queries stores that already do, then draws the result. The README frames the project as a way to "query, visualize, alert on and understand your metrics no matter where they are stored", and lists Prometheus, Loki, Elasticsearch, InfluxDB and Postgres among the sources it can read. That single sentence defines both the value and the boundary.

The people who end up running it are usually platform, SRE or infrastructure teams who already have Prometheus scraping something, or Loki collecting logs, or a Postgres table someone keeps asking about. The recurring problem is not collection. It is that three engineers each have their own query, their own terminal, and no shared artifact they can point at during an incident. Grafana is the shared artifact: a dashboard is a saved, versionable, permissioned query with a rendering layer on top.

It is a poor fit for a single developer who wants a hosted service with nothing to operate, and a poor fit for anyone who has not yet decided where the data lives. Grafana assumes that decision is already made.

How the query, dashboard and alerting layers fit together

The architecture visible in the repository is a Go backend plus a TypeScript front end. The Makefile builds Go with version, commit and build stamp ldflags injected at link time, and package.json drives a webpack and rspack front-end build, with NODE_OPTIONS=--max-old-space-size=8192 set on the production build script. That is a large single-page application being compiled, not a thin server-rendered page.

At runtime the flow is: the browser renders a panel, the panel issues a query to the Grafana backend, the backend routes that query to the configured data source, and the result comes back as a data frame the panel renders. The README notes that a data source can be specified per query, and that mixing sources in one graph works "for even custom datasources". That per-query routing is the mechanism that makes a single dashboard able to combine a Prometheus rate with a Postgres row count.

Alerting reuses the same query path rather than a separate agent. The README describes rules that Grafana "will continuously evaluate" and notifications sent to Slack, PagerDuty, VictorOps or OpsGenie. Because evaluation happens in the Grafana process, alerting availability is coupled to the Grafana deployment: if the instance is down, rule evaluation stops with it. That is a design trade-off worth stating plainly, and it is the reason some teams keep a separate alert evaluator in front of their metrics store.

Installing Grafana and drawing a first panel

The README does not print install commands. It points to grafana.com/get and to the installation guides under grafana.com/docs/grafana/latest/setup-grafana/installation/, and the repository ships a multi-stage Dockerfile whose base images are pinned. Because the install steps are not in the README, treat the official guides as the source of truth for your platform and use the repository only to confirm how the image is built.

What the repository does give you is the build itself. The Dockerfile's JavaScript stage installs dependencies with the flag below, and the package.json build script is the one the image runs:

yarn install --immutable

The same stage runs the front-end build through a build argument whose default is build, so the image is produced by running the package.json build script rather than a bespoke command. The final image is based on gcr.io/distroless/static-debian13, which has no shell, so debugging a running container means attaching elsewhere rather than exec-ing in.

For the application itself, the README's contribution path points developers at the Developer guide in contribute/developer-guide.md, and the Makefile is self-documenting: running make help lists the available targets. The release list shows v13.2.0, v13.1.4 and v13.0.7, all dated 2026-08-18, so pinning an explicit version rather than latest is realistic here.

Once an instance is running, a dashboard is a JSON document of panels, each with a target query. The README's own framing is that template variables appear as dropdowns at the top of a dashboard, which is the feature that turns one dashboard into many: a variable holding a job name or an instance label, referenced inside the query, replaces a dashboard per environment. Build one panel by hand, export the dashboard JSON, and keep that file in version control rather than editing in the browser.

Where Grafana stops being the right tool

The clearest limitation is the one the README states by omission: Grafana has no storage layer. If your metrics are not already in a time-series database, Grafana has nothing to query. Teams that adopt it expecting to replace Prometheus or Elasticsearch end up running both.

Alerting is the second boundary. Rules are evaluated by the Grafana process against a data source, so a Grafana outage is also an alerting outage, and a slow data source makes rule evaluation slow. The README lists Slack, PagerDuty, VictorOps and OpsGenie as notification targets; it does not document rollback behaviour for a notification that fails to deliver, and it does not describe a high-availability story for rule evaluation. If your alerting must survive the dashboard going down, that requirement is not answered here.

Upgrades are the third. The repository carries three patch releases on the same day (13.2.0, 13.1.4, 13.0.7), which tells you the project maintains parallel branches, and the go.mod pins a large dependency set with per-package ownership comments. A major version bump is a plugin compatibility event as much as an application upgrade. Anyone running community panels should treat the Grafana version as a constraint on which plugins they can install, not the other way round.

Grafana compared with Kibana, and what the difference actually is

Kibana is the closest comparison people search for, and the difference is not cosmetic. Kibana is built around Elasticsearch as its data store and its query language; its dashboards, discovery views and visualizations assume documents in an Elasticsearch index. Grafana starts from the opposite position: the data source is a configuration choice, and the same panel type can read Prometheus, Loki, Elasticsearch, InfluxDB or Postgres.

That means Grafana is the better answer when your telemetry is already spread across more than one store, because you can put a Prometheus series and a Postgres count in the same view without exporting one into the other. Kibana is the better answer when everything already lives in Elasticsearch and you want the log-exploration experience that is native to it rather than a plugin approximation.

The cost of Grafana's approach is that the query editor is per-plugin. A PromQL panel and a SQL panel share a frame, not a language. Learning Grafana means learning the query language of whichever source you are pointing at, and the documentation for that language lives with the data source, not with Grafana.

Licence, maintenance and the real cost of upgrading

Grafana is distributed under AGPL-3.0-only. The README points to a separate LICENSING.md for Apache-2.0 exceptions, which means the licence situation is not a single line and the exceptions file is the document that matters if you plan to redistribute or embed Grafana. This is a description of what the repository states, not legal advice; the AGPL's network-use clause is the part that most often surprises teams building a product on top of it, and that question belongs with a lawyer.

The repository is not archived, and the last push was on 2026-08-18. That is recent enough that the project is clearly being worked on, but the maintenance cost that matters to an operator is not commit frequency. It is the upgrade cadence: three maintained release lines at once means security fixes land on branches you may not be running, and the go.mod's per-package ownership comments show a dependency graph large enough that a major upgrade touches more than the front end. Budget for reading the changelog before each major version, and for testing every panel plugin you depend on against the new version.

The Go toolchain in the repository is pinned at 1.26.6 in both go.mod and the Makefile, and the Dockerfile's builder stages pin their own base images. That pinning helps reproducibility, but it also means a local development environment that has drifted from those versions will fail before it produces anything useful.

Editorial conclusion

Adopt Grafana when your metrics, logs or traces already sit in a queryable store and the missing piece is a shared view, alert rules and a permission model over them. Do not adopt it expecting a database, a collector or a hosted service: it ships none of those, and the AGPL-3.0 licence plus the LICENSING.md exceptions is the first thing to read if you plan to embed it in a product. Verify three things before committing: that a data source plugin exists for your store, that your Grafana version matches the plugin API your plugins were built against, and that the alerting notification path you need is one the documentation actually lists.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes