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 platform for engineering teams. ClickHouse® is a columnar OLAP 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 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):

# 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:

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:

# 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:

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 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:

# 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:

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

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 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 reflected in dashboards as it happens. ClickHouse® ingests 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

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:

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 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 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 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.