Grafana isn’t a replacement for Looker Studio: it’s a tool built for a different problem entirely. Looker Studio excels with business reports to present to stakeholders — management, funders, marketing teams. Grafana is the visualization layer for real-time technical data: IoT metrics, sensor time series, application and infrastructure monitoring. The difference isn’t aesthetic — it’s structural. And understanding it is the first step to using both well. Fifth installment of the Digital Stack 2026 series.
Imagine having 50 weather stations transmitting temperature, humidity, and air quality every five minutes. In one day you produce 720 measurements per station — 36,000 data points total. In one month, over a million. Looker Studio can technically display them. But it’s not designed for this: every refresh recalculates everything, aggregate queries across millions of rows slow to a crawl, and the alerting system — notify me when temperature exceeds 40°C — simply doesn’t exist.
Grafana is designed precisely for this scenario. And not just IoT — but any system that produces continuous data over time: application metrics, system logs, tick-by-tick financial data, data pipeline monitoring. The Smart City use case from the Politecnico Advanced Data Modeling course — ARPA Piedmont environmental data, Kafka as the ingestion layer, InfluxDB as storage — has Grafana as the final visualization layer for a specific reason.
How Grafana Works: The Datasource + Panel Model
Grafana’s architecture rests on two concepts. Datasources are connections to data sources — Grafana stores nothing itself, it always queries the source database at refresh time. Panels are the individual visual widgets that make up a dashboard: line charts, numeric stat panels, maps, tables, gauges, heatmaps. Each panel has its own independent query against the configured datasource.
This design is fundamental to understanding the tool’s real value. The data stays where it is — in InfluxDB, PostgreSQL, Elasticsearch, Prometheus. Grafana is the read-and-present layer. You can have the same metric displayed in three different panels with three different time scales, three different chart types, for three different audiences — without duplicating a single byte of storage.
Grafana Cloud Free: Live in Two Minutes
Grafana has two deployment modes: self-hosted (open source, local installation) and Grafana Cloud. To get started, the Free Cloud plan is sufficient: it includes 10,000 Prometheus metrics, 50 GB of logs, 50 GB of traces, full alerting, and access to preinstalled demo dashboards. No credit card, no installation required. Register at grafana.com with Google, your instance is live in two minutes with sample data ready to explore.
Connections: It Plugs Into Your Entire Modern Data Stack
This is where Grafana shows its real flexibility. The screen below is the Connections → Add new connection page of the Cloud interface. The most popular datasources listed at the top speak for themselves: Linux Server, Prometheus, InfluxDB, MySQL, Elasticsearch, Synthetic Monitoring. Further down: Kubernetes Monitoring, OpenTelemetry, AWS CloudWatch, Docker.
The “Infinity for JSON” entry deserves a special mention: it lets you connect any REST API or JSON endpoint as a datasource, without writing code. If you have an API that returns JSON data — a CRM, an ERP, an external data feed — you can visualize it in Grafana directly. The AI Ask Assistant banner at the top helps you pick the right connector based on a plain-language description of your use case.
Building a Panel: From Datasource to Chart in 4 Steps
The image below shows Grafana’s panel editor open on the “Temperature” panel of the Weather Demo dashboard. This is the interface you use every time you create or edit a panel — and understanding its layout before you use it makes the first session much smoother.
At the top: a live chart preview — every change to the query is reflected immediately without saving. Below that: three tabs — Queries (the queries against your datasource), Transformations (operations on the data before rendering: joins, filters, column renaming), Alert (alerting thresholds for this specific panel). On the right: the options panel — visualization type (Time series, with a Change button to switch to bar chart, gauge, stat, table), title, and visual style presets.
The PromQL Query Visible in the Editor
The configured datasource is Prometheus (${DS_PROMETHEUS}), and the query in row A is:
avg(weather_temp_c{job="weather-service", location=~"$location"}) by (location). This PromQL query: selects the weather_temp_c metric from the weather-service job, filters by location using the dashboard variable $location (the “London” filter visible at the top), and calculates the average per distinct location. The result is exactly the yellow line in the chart — London’s average temperature over the past 7 days at 15-minute granularity.
You don’t need to know PromQL to use Grafana — the Builder tab next to Code builds the query visually, with dropdown menus for metric, label filters, and operations. PromQL becomes relevant when you need queries more specific than what the visual builder covers.
Alerting: the Feature Looker Studio Doesn’t Have
This is the most important operational difference between Grafana and any classical business intelligence tool. Grafana has a native, complete, configurable alerting system — not an add-on, not an external integration. You define the conditions, Grafana monitors in the background and notifies you via email, Slack, webhook, PagerDuty, Telegram, or any other channel when a threshold is crossed.
The screenshot below shows the new alert rule creation page: step 1 for the name, step 2 for the query and alert condition. The builder is identical to the panel editor — you select a datasource, build the query, then define the condition: WHEN QUERY IS ABOVE [value]. The “Preview alert rule condition” button runs the query against historical data and shows whether the condition would have triggered in the previous hours — invaluable for calibrating thresholds before activating the alert.
Practical Alerting Use Cases
In the Politecnico Smart City project: notify the operations team when PM10 exceeds 50 µg/m³ (WHO air quality threshold) on at least three consecutive stations. In application monitoring: alert when average API response time rises above 500ms for more than 5 consecutive minutes. In the IoT Smart Agriculture project: automatic notification when soil moisture drops below the irrigation threshold in a specific zone.
None of these scenarios is manageable with Looker Studio — which is a passive visualization tool, not an active monitoring system. It’s the same difference between looking at a chart when you feel like it and receiving a notification when something goes wrong.
Grafana vs Looker Studio: a Compass for Choosing
The question isn’t which is better — it’s which fits your use case. Looker Studio is the right choice when your primary dataset comes from Google Sheets, Google Analytics, or Google Ads; when the audience is non-technical (stakeholders, funders, management) and the format is a static report to present; when you need zero configuration and zero cost without custom authentication or datasource complexity.
Grafana is the right choice when data arrives in real time from sensors, APIs, or application systems; when you need proactive alerting on thresholds; when the datasource is InfluxDB, Prometheus, Elasticsearch, or any non-Google database; when the team consuming the dashboard has a technical background and needs drill-down and interactive queries.
In many real-world architectures the two tools coexist: Grafana for operational and technical monitoring, Looker Studio for funder and executive reports. The next article in the series introduces a third layer: the RAG technique, which brings conversational AI on top of this data — allowing you to query documents and databases in natural language, without writing SQL or PromQL. Monitoring becomes dialogue.
