---
title: "clickhouse integration grafana — 3 Ways to Connect in 2026"
excerpt: "Connect Grafana to ClickHouse® via the native plugin, Tinybird Infinity datasource, or ClickHouse® Cloud. Pick the right clickhouse integration grafana path."
authors: "Tinybird"
categories: "AI Resources"
createdOn: "2026-04-13 00:00:00"
publishedOn: "2026-04-13 00:00:00"
status: "published"
---

These are the main options for a **clickhouse integration grafana** setup:

1. Grafana → ClickHouse® via **native ClickHouse® datasource plugin**
2. Grafana → **Tinybird** via Infinity datasource plugin (REST API)
3. Grafana → **ClickHouse® Cloud** via the official Grafana ClickHouse® Cloud plugin

**Grafana** is the most widely deployed **observability and [real-time data visualization](https://www.tinybird.co/blog/real-time-data-visualization) platform** for engineering teams. ClickHouse® is a columnar OLAP [database](https://www.oracle.com/database/what-is-database/) that handles billions of rows in sub-second queries. Connecting the two enables real-time operational dashboards, time-series metrics, and analytical panels that refresh continuously.

A **clickhouse integration grafana** pipeline lets engineers query ClickHouse® data directly from Grafana panels, build alerting rules against analytical metrics, and serve [real-time dashboards](https://www.tinybird.co/blog/real-time-dashboards-are-they-worth-it) to infrastructure and product teams.

Before you pick a connector, consider these questions:

- Do you need **live panel queries** (each refresh hits ClickHouse®) or **cached responses** for high-concurrency dashboards?
- Does your team manage ClickHouse® infrastructure, or do you use a **managed service**?
- Do you also need to expose the same metrics as **REST APIs** for applications beyond Grafana?

## **Three ways to implement clickhouse integration grafana**

This section covers the three main datasource paths, with configuration and code for each.

### **Option 1: Grafana → ClickHouse® — native datasource plugin**

The most direct approach. Grafana has a **ClickHouse® datasource plugin** maintained by Grafana Labs (and ClickHouse®). Install it from the Grafana plugin catalog and configure it with your ClickHouse® instance connection details.

**How it works:** the plugin sends SQL queries to ClickHouse® via the HTTP interface on port 8123 (or 8443 for TLS). Each Grafana panel refresh triggers a query. The plugin supports **query variables**, **time range macros**, and **table/time series display modes**.

**Grafana datasource configuration (grafana.ini or provisioning YAML):**

```yaml
# Grafana provisioning: datasources/clickhouse.yaml
apiVersion: 1
datasources:
  - name: ClickHouse
    type: grafana-clickhouse-datasource
    url: https://your-clickhouse-host:8443
    jsonData:
      defaultDatabase: default
      username: grafana_reader
      port: 8443
      tlsSkipVerify: false
    secureJsonData:
      password: your_password
```

Once configured, panels use **SQL queries** with ClickHouse® time macros. The plugin provides `$__timeFilter()`, `$__timeInterval()`, and `$__fromTime()` macros for building time-range-aware queries:

```sql
SELECT
  toStartOfMinute(event_time) AS time,
  event_type,
  count() AS total_events
FROM events
WHERE $__timeFilter(event_time)
GROUP BY time, event_type
ORDER BY time
```

**When this fits:**

- You run **self-managed ClickHouse®** or ClickHouse® Cloud and want a direct, low-latency Grafana connection
- Your engineers are comfortable with **SQL-based Grafana panels**
- You need Grafana **alerting rules** that trigger directly against ClickHouse® query results

**Trade-offs:** each Grafana panel refresh triggers a ClickHouse® query. High-concurrency dashboards shared across many users can create significant query load on ClickHouse®. Set `max_concurrent_queries` on the user profile to protect other workloads. For dashboards with many concurrent viewers, use caching (see Option 2).

**Prerequisites:** Grafana 9.0+, ClickHouse® datasource plugin installed (`grafana-cli plugins install grafana-clickhouse-datasource`), network access to ClickHouse® port 8123 or 8443.

### **Option 2: Grafana → Tinybird — Infinity datasource plugin (REST API)**

Tinybird sits between your data and Grafana. You define SQL **Pipes** in Tinybird that query ClickHouse®-backed data sources, publish them as **REST API endpoints**, and consume those endpoints in Grafana via the **Infinity datasource plugin**.

**How it works:** Tinybird Pipes return JSON or NDJSON over HTTPS. The **Grafana Infinity plugin** can consume any REST JSON endpoint. You configure the Pipe URL and auth header, then define field mappings in the panel editor.

**Grafana Infinity datasource panel configuration:**

```yaml
# Grafana panel datasource: Infinity (Tinybird endpoint)
type: infinity
url: https://api.tinybird.co/v0/pipes/grafana_metrics.json
method: GET
headers:
  - name: Authorization
    value: Bearer YOUR_TINYBIRD_TOKEN
params:
  - name: start_date
    value: ${__from:date:YYYY-MM-DD}
  - name: end_date
    value: ${__to:date:YYYY-MM-DD}
parser: json
root_selector: data
columns:
  - selector: time
    text: time
    type: time
  - selector: total_events
    text: Total Events
    type: number
```

**cURL example to validate the Tinybird endpoint before connecting in Grafana:**

```bash
curl -s \
  -H "Authorization: Bearer YOUR_TINYBIRD_TOKEN" \
  "https://api.tinybird.co/v0/pipes/grafana_metrics.json?start_date=2026-04-01&end_date=2026-04-13" \
  | jq '.data[:3]'
```

Tinybird Pipe caching (configurable TTL) means Grafana panel refreshes on busy dashboards return **cached responses in single-digit milliseconds** without querying ClickHouse® on every viewer interaction. This gives you [real-time analytics](https://www.tinybird.co/blog/real-time-analytics-a-definitive-guide) serving under high concurrency.

**When this fits:**

- You already use Tinybird for analytics and want to reuse the same Pipes in Grafana
- You need **API-first access** to metrics for both Grafana and application consumers
- Your dashboards serve **many concurrent viewers** and benefit from Tinybird's response caching

**Trade-offs:** adds an HTTP layer between Grafana and raw data. The Infinity plugin does not support Grafana **alerting rules** natively (alerting requires a direct datasource with ClickHouse® query evaluation). Use Option 1 or Option 3 if you need Grafana alerts.

**Prerequisites:** Grafana 9.0+, Infinity datasource plugin installed (`grafana-cli plugins install yesoreyeram-infinity-datasource`), Tinybird account with published Pipes, Tinybird API token.

### **Option 3: Grafana → ClickHouse® Cloud — Cloud-endpoint configuration**

The same **Grafana ClickHouse® datasource plugin** used in Option 1 also connects to ClickHouse® Cloud. The plugin is the same artifact — what differs is the connection configuration: Cloud instances use a public hostname, port 8443 (HTTPS), and credentials issued from the ClickHouse® Cloud console. Cloud-specific query optimizations and query builder features work best with this endpoint configuration.

**How it works:** the plugin connects to ClickHouse® Cloud via HTTPS, handles authentication, and provides an enhanced query builder with column type inference and time series support. Configure via Grafana provisioning or the UI.

**Grafana provisioning for ClickHouse® Cloud:**

```yaml
# Grafana provisioning: datasources/clickhouse-cloud.yaml
apiVersion: 1
datasources:
  - name: ClickHouse Cloud
    type: grafana-clickhouse-datasource
    url: https://your-instance.clickhouse.cloud:8443
    jsonData:
      defaultDatabase: default
      username: default
      port: 8443
      protocol: https
    secureJsonData:
      password: your_password
```

Once configured, use time-series queries with ClickHouse® date macros to populate Grafana time series panels:

```sql
SELECT
  toStartOfInterval(event_time, INTERVAL 5 MINUTE) AS time,
  count() AS requests,
  avg(response_ms) AS avg_latency_ms
FROM requests_log
WHERE $__timeFilter(event_time)
GROUP BY time
ORDER BY time
```

**When this fits:**

- You're on **ClickHouse® Cloud** and want the simplest, best-supported Grafana plugin for Cloud
- Your team wants an enhanced **Grafana query builder** with ClickHouse® type awareness
- You need **Grafana alerting** triggered directly from ClickHouse® query results

**Trade-offs:** the plugin is optimized for ClickHouse® Cloud. Self-managed instances should use Option 1. Like Option 1, concurrent dashboard viewers create direct ClickHouse® query load — plan capacity accordingly.

**Prerequisites:** ClickHouse® Cloud account, Grafana 9.0+, the official ClickHouse® datasource plugin (same as Option 1, configured for Cloud endpoint), port 8443 access.

### **Summary: picking the right option**

| Criterion | Native plugin | Tinybird API | Cloud plugin |
|---|---|---|---|
| **Setup complexity** | Low (plugin install) | Medium (Pipe + Infinity plugin) | Low (plugin install) |
| **Live panel queries** | Yes | Yes (cached or live) | Yes |
| **Grafana alerting** | Yes | No | Yes |
| **Response caching** | No (ClickHouse® query per refresh) | Yes (Tinybird TTL) | No |
| **API reuse** | No | Yes (same Pipe serves API + Grafana) | No |
| **Infrastructure** | Any ClickHouse® | Tinybird managed | ClickHouse® Cloud only |

## **Decision framework: what to choose for clickhouse integration grafana**

Pick based on your **deployment**, **concurrency**, and **alerting needs**:

- **Native plugin** if you run self-managed ClickHouse® and need Grafana alerting. Best for engineering dashboards with moderate viewer concurrency.
- **Tinybird API** if your dashboards serve **many concurrent viewers** and benefit from caching, or if you also serve the same metrics as application APIs. Best when you want [user-facing analytics](https://www.tinybird.co/blog/user-facing-analytics) and Grafana monitoring from the same Tinybird Pipe.
- **ClickHouse® Cloud plugin** if you're on ClickHouse® Cloud and need the best-supported plugin with query builder and alerting support.

**Bottom line:** for alerting-critical engineering dashboards, Option 1 or Option 3 is the direct path. For high-concurrency product dashboards or multi-consumer analytics, Option 2 (Tinybird) adds caching and API reuse without extra infrastructure.

## **What does clickhouse integration grafana mean (and when should you care)?**

A **clickhouse integration grafana** setup connects Grafana's visualization and alerting engine to ClickHouse®'s analytical query engine. Grafana sends SQL queries to ClickHouse® (via the datasource plugin), which returns time-series or tabular results for rendering in panels, stat cards, and alert evaluations.

You should care when your metrics or event data outgrows what **Prometheus**, **Loki**, or a traditional time-series database can query interactively. ClickHouse® handles **billions of rows** with sub-second aggregations — making it a strong backend for operational analytics, product metrics, and business intelligence dashboards in Grafana.

The integration also matters when you need [real-time data processing](https://www.tinybird.co/blog/real-time-data-processing) reflected in dashboards as it happens. ClickHouse® ingests [streaming data](https://www.ibm.com/think/topics/streaming-data) continuously and a live Grafana connection reflects new rows on each panel refresh.

If your workload is pure infrastructure monitoring with Prometheus metrics, Grafana's native Prometheus datasource may be simpler. ClickHouse® is the right fit when you need to **combine logs, events, and business metrics** in a single analytical engine with long data retention.

## **Schema and pipeline design**

### **Practical schema rules for Grafana time-series queries**

Grafana expects **time-series result sets**: a `time` column plus one or more metric columns. Designing your ClickHouse® schema to match Grafana's query patterns avoids slow panel loads.

**Rule 1: use `DateTime` or `DateTime64` for the time column.** Grafana's time range macros (`$__timeFilter()`) work with these types. Avoid storing timestamps as Unix integers if possible.

**Rule 2: pre-aggregate with materialized views.** Grafana dashboards typically display data at a fixed resolution (per minute, per hour). A materialized view at the right granularity avoids expensive real-time aggregations on raw events.

**Rule 3: partition by time.** `PARTITION BY toYYYYMM(event_time)` ensures Grafana time-range queries only scan relevant partitions.

**Rule 4: use `LowCardinality(String)` for label columns.** Grafana groups panels by label dimensions. `LowCardinality` keeps `GROUP BY` fast for columns with bounded cardinality.

### **Example: analytics-friendly schema for Grafana**

```sql
CREATE TABLE requests_log (
  request_id UInt64,
  service_name LowCardinality(String),
  endpoint LowCardinality(String),
  status_code UInt16,
  response_ms Float32,
  event_time DateTime,
  updated_at DateTime
)
ENGINE = ReplacingMergeTree(updated_at)
PARTITION BY toYYYYMM(event_time)
ORDER BY (service_name, endpoint, event_time)
```

A **pre-aggregation materialized view** for Grafana time-series panels:

```sql
CREATE MATERIALIZED VIEW requests_per_minute_mv
ENGINE = AggregatingMergeTree()
PARTITION BY toYYYYMM(minute)
ORDER BY (service_name, endpoint, minute)
AS SELECT
  toStartOfMinute(event_time) AS minute,
  service_name,
  endpoint,
  count() AS total_requests,
  avgState(response_ms) AS avg_latency_state,
  countIf(status_code >= 500) AS error_count
FROM requests_log
GROUP BY minute, service_name, endpoint
```

Query with: `SELECT minute, service_name, avgMerge(avg_latency_state) AS avg_latency_ms, sum(total_requests) AS requests FROM requests_per_minute_mv GROUP BY minute, service_name ORDER BY minute`.

Point Grafana panels at `requests_per_minute_mv` for pre-aggregated time series. This turns multi-second raw-data queries into millisecond lookups on the materialized view.

### **Failure modes**

1. **Panel query timeout under dashboard load.** When many engineers view the same Grafana dashboard simultaneously, each panel refresh triggers a ClickHouse® query. ClickHouse® can handle high concurrency, but unoptimized queries compound the load. Mitigation: set `max_execution_time` on the ClickHouse® user profile, use materialized views for pre-aggregated panels, and consider Tinybird's caching layer for the highest-traffic dashboards.

2. **Grafana time macro incompatibility.** `$__timeFilter()` and `$__timeInterval()` macros require the time column to be a `DateTime` type. If the column is `Int64` (Unix timestamp) or `String`, the macros fail silently. Mitigation: use `DateTime` or `DateTime64` for all time columns and validate macro output in the Query Inspector before deploying panels.

3. **High-cardinality label explosion in GROUP BY.** Grafana panels grouped by a high-cardinality dimension (raw URL path, UUID, IP address) produce massive result sets and slow queries. Mitigation: restrict cardinality with `LIMIT` or pre-filter in the panel SQL, and use `LowCardinality` types for all panel label columns.

4. **Schema drift breaking existing panels.** Column renames or type changes in ClickHouse® break Grafana panels that reference those columns. Mitigation: treat the ClickHouse® schema as a stable contract for Grafana; add columns additively and test panel SQL in staging before DDL changes in production.

5. **Alert evaluation lag.** Grafana alerts evaluate on the datasource query cadence. If ClickHouse® ingestion lag causes data to arrive late, alert conditions may fire or clear incorrectly. Mitigation: add a time buffer (`event_time <= now() - INTERVAL 1 MINUTE`) to alert queries to avoid evaluating partially-ingested data windows.

## **Why ClickHouse® for Grafana analytics**

ClickHouse® is a **columnar OLAP database** purpose-built for time-series and event analytics. **Vectorized execution** and **columnar compression** deliver sub-second aggregations on billions of rows — exactly the performance profile Grafana panels need for interactive dashboards.

For Grafana users, this means panels respond quickly even on datasets covering months of high-frequency events. Time-range filters, service breakdowns, and rolling averages all benefit from ClickHouse®'s [low latency](https://www.cisco.com/site/us/en/learn/topics/cloud-networking/what-is-low-latency.html) query execution.

ClickHouse®'s MergeTree engine handles **time-partitioned data**, **pre-aggregation via materialized views**, and **deduplication** — patterns that map naturally to Grafana's time-series panel model. For teams needing both operational monitoring and business analytics in the same Grafana instance, ClickHouse® is one of the [fastest database for analytics](https://www.tinybird.co/blog/fastest-database-for-analytics) backends available.

## **Security and operational monitoring**

- **Authentication:** dedicated read-only ClickHouse® user per Grafana datasource with `GRANT SELECT`. Never use the `default` admin user.
- **TLS encryption:** enforce TLS. Port 8443 for Cloud; `https_port` for self-managed.
- **Row-level security:** ClickHouse® row policies (`CREATE ROW POLICY`) if dashboards serve teams with different access.
- **Query limits:** `max_execution_time`, `max_memory_usage`, `max_concurrent_queries` on the Grafana user profile.
- **Token hygiene:** rotate Tinybird API tokens on schedule; store them in Grafana's encrypted secret store, not in provisioning YAML committed to repos.

## **Latency, caching, and freshness considerations**

**Live panel queries** via the native or Cloud plugin send SQL to ClickHouse® on every Grafana panel refresh. Latency depends on query complexity and data volume — pre-aggregated materialized view queries are typically much faster than raw event scans.

**Grafana Enterprise query caching** caches panel responses server-side. **Tinybird Pipe caching** adds a configurable TTL upstream — panels hitting a warmed Tinybird cache return faster without a ClickHouse® query. Best for high-concurrency dashboards where many viewers share the same panels.

## **Why Tinybird is a strong fit for clickhouse integration grafana**

Most engineering teams using Grafana with ClickHouse® eventually need the same metrics elsewhere — a **product dashboard**, a **customer-facing status page**, or an **API for downstream services**. Managing a separate API layer means duplicated query logic and more infrastructure to monitor.

Tinybird solves this by combining a **ClickHouse®-powered analytics platform**, **SQL-based Pipes**, and **instant REST API publishing** in one managed service. You ingest data into Tinybird, define Pipes, and serve them to Grafana (via Infinity plugin), your product (via HTTP), and any other consumer. The same query, multiple consumers — this is the [real-time data ingestion](https://www.tinybird.co/blog/real-time-data-ingestion) and serving pattern that scales without managing separate ClickHouse® infrastructure.

Tinybird's response caching is particularly valuable for Grafana dashboards shared across large teams. Instead of hundreds of concurrent Grafana users each triggering a ClickHouse® query, Tinybird serves cached responses and batches refreshes — preserving ClickHouse® capacity for ingestion and ad-hoc queries.

Next step: identify your highest-traffic Grafana dashboard, model its key panel queries as Tinybird Pipes with appropriate TTL caching, and validate panel load time and ClickHouse® query reduction in staging before switching production dashboards.

## **Frequently Asked Questions (FAQs)**

### **What plugin do I need for clickhouse integration grafana?**

The **Grafana ClickHouse® datasource plugin** — install it with `grafana-cli plugins install grafana-clickhouse-datasource`. It supports both self-managed ClickHouse® and ClickHouse® Cloud. Alternatively, use the **Infinity plugin** (`yesoreyeram-infinity-datasource`) to consume Tinybird REST API endpoints in Grafana panels.

### **Does clickhouse integration grafana support Grafana alerting?**

Yes, via the **native ClickHouse® datasource plugin** (Option 1) and the **ClickHouse® Cloud plugin** (Option 3). Both support Grafana alert rule evaluation directly against ClickHouse® queries. The Infinity plugin (Tinybird option) does not natively support Grafana alerting — use Options 1 or 3 for alerting-critical dashboards.

### **How do I use time range macros in clickhouse integration grafana?**

The ClickHouse® datasource plugin provides macros like `$__timeFilter(column)`, `$__timeInterval(column)`, `$__fromTime()`, and `$__toTime()`. Use `$__timeFilter(event_time)` in your `WHERE` clause to make panels respect the Grafana time range picker. Ensure the column is `DateTime` or `DateTime64` type.

### **How do I reduce ClickHouse® load from a busy Grafana dashboard?**

Three approaches: create **materialized views** that pre-aggregate at dashboard panel granularity; use **Grafana Enterprise query caching** to serve cached panel results to concurrent viewers; or route the dashboard through **Tinybird Pipes with TTL caching** so ClickHouse® receives one query per TTL window regardless of viewer count.

### **Can I combine ClickHouse® and Prometheus metrics in Grafana?**

Yes. Configure both as separate datasources and use them in different panels or via **Mixed datasource** queries. This lets you correlate ClickHouse® business events with Prometheus infrastructure metrics on the same Grafana dashboard.

### **What are the main limitations of clickhouse integration grafana?**

Grafana's time-series model expects a `time` column plus metric columns — ClickHouse®'s richer SQL types (arrays, `AggregateFunction`) may need simplification. The `$__timeFilter()` macro requires `DateTime` types. High-cardinality breakouts can be slow. The Infinity plugin does not support native Grafana alerting.