---
title: "clickhouse integration preset — 3 ways in 2026"
excerpt: "A clickhouse integration preset setup connects Preset Cloud or Superset-based workspaces to ClickHouse®. Compare Tinybird-fed Postgres first, then managed Preset and self-hosted Superset."
authors: "Tinybird"
categories: "AI Resources"
createdOn: "2026-04-22 00:00:00"
publishedOn: "2026-04-22 00:00:00"
updatedOn: "2026-04-22 00:00:00"
status: "published"
---

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

1. **Tinybird Pipes** as a **JSON/HTTP metric layer** feeding **datasets** Preset reads through a **supported database** (hybrid) when you need **APIs + charts** — **preferred default** when metrics have multiple consumers
2. **Preset Cloud** → ClickHouse® via **SQLAlchemy** (**ClickHouse Connect**) in the Preset **database connection** UI
3. **Self-hosted Apache Superset** (the open-source core Preset builds on) → ClickHouse® using the same **driver** stack your team operates

**Preset** provides a managed experience around **Apache Superset**, the open-source BI project your engineers may already know from self-hosted deployments.

ClickHouse® is a columnar OLAP [database](https://www.oracle.com/database/what-is-database/) for interactive analytics.

A **clickhouse integration preset** project is usually “connect my workspace to ClickHouse® so analysts can build datasets and dashboards” — with [real-time data visualization](https://www.tinybird.co/blog/real-time-data-visualization) when charts query live connections.

Decide early:

- Are you on **Preset Cloud** (SaaS) or **self-hosting** Superset?
- Is ClickHouse® **publicly reachable** or **private** (VPN / allowlist / tunnel)?
- Do you need the **same metrics** as **HTTP APIs** outside Preset?

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

**Option 1 (Tinybird → Postgres)** is the **default recommendation** when Preset is one of several consumers of the same metrics (APIs, apps, embedded charts). Use **Options 2–3** when every Preset user must run **native SQL** against ClickHouse®.

### **Option 1: Tinybird Pipes + a Preset-supported warehouse (hybrid)**

Sometimes the best **clickhouse integration preset** outcome is not “Preset queries every raw ClickHouse® table,” but “Preset queries **Postgres** tables that are **refreshed** from **Tinybird Pipes**,” while deep engineering dives use **Option 2** or **Option 3** for a smaller group.

**How it works:** publish a Pipe (`kpi_daily.json`), load results into **[PostgreSQL](https://www.ibm.com/think/topics/postgresql)** on a schedule, connect Preset to Postgres for **executive dashboards**, and keep ClickHouse® access narrow for specialists.

**When this fits:**

- You already treat **Tinybird** as the **canonical metric API** layer ([user-facing analytics](https://www.tinybird.co/blog/user-facing-analytics) + internal reporting)
- You want **tighter governance** for broad Preset user populations
- **Minutes** of staleness are acceptable for the Postgres-backed datasets

**Trade-offs:** you maintain **sync jobs** and **schema contracts** — operational work, not licensing magic.

**Prerequisites:** Tinybird Pipes, Postgres, scheduler, Preset Postgres connector.

### **Option 2: Preset Cloud → ClickHouse® — managed database connection**

Preset Cloud connects to ClickHouse® like Superset does: add a database, install/ensure **`clickhouse-connect`**, and configure a **SQLAlchemy URI** with TLS parameters appropriate to your ClickHouse® endpoint.

**How it works:** in Preset, open **Data → Databases → + Database**, choose the ClickHouse® dialect, paste the URI, test connectivity, then expose schemas to SQL Lab and datasets.

**Example URI pattern (host, db, TLS vary):**

```text
clickhousedb://reader:YOUR_PASSWORD@your-host.example.com:8443/default?secure=1
```

**Optional engine parameters JSON (illustrative):**

```json
{
  "connect_args": {
    "secure": true,
    "verify": true,
    "compress": true,
    "send_receive_timeout": 300
  }
}
```

**When this fits:**

- You want **managed Superset** operations (Preset) with **native ClickHouse®** SQL access
- Your ClickHouse® endpoint meets Preset’s **networking** requirements (public hostname, allowlisting, or supported tunnel patterns)
- Analysts need **SQL Lab** and dataset modeling on ClickHouse® tables

**Trade-offs:** SaaS-to-warehouse networking can be fiddly. You still must enforce **least privilege** and **query limits** on the ClickHouse® side — Preset does not remove that responsibility.

**Prerequisites:** Preset workspace admin access, ClickHouse® user with **SELECT** grants, TLS trust chain, documented **IP allowlist** updates if your ClickHouse® provider requires them.

**Operational monitoring:** track **HTTP 4xx/5xx** from Preset to ClickHouse®, **p95 query duration**, and **concurrent queries** on the ClickHouse® side. Preset can be healthy while ClickHouse® is saturated — separate dashboards help.

**Dataset design:** prefer **certified datasets** for broad user populations and keep experimental SQL Lab access narrower. Certification is a process, not a checkbox — it forces **review** of joins and time filters before charts proliferate.

### **Option 3: Self-hosted Superset → ClickHouse® — you own the stack**

If you run **Superset** yourself (often the same integration steps Preset automates), you install **`clickhouse-connect`**, configure the URI in Superset’s **Database** settings, and operate upgrades, backups, and ingress yourself.

**How it works:** identical driver concept to **Option 2** — difference is **who patches** the servers and **where** secrets live.

**Docker-oriented install note (illustrative):**

```dockerfile
# Example pattern only — pin versions to match your org standards
RUN pip install --no-cache-dir "clickhouse-connect==0.8.5"
```

**When this fits:**

- You already run **Kubernetes** or **VM** fleets for Superset and want **full control**
- Compliance requires **data plane** inside your VPC with no SaaS BI
- You have staffing for **on-call** on the BI layer

**Trade-offs:** higher **ops** burden than Preset Cloud — you own dependency upgrades and incident response.

**Prerequisites:** Superset deployment skills, image build pipeline, secrets manager, monitoring.

**Upgrade discipline:** Superset security patches arrive frequently. If your team cannot keep pace, Preset Cloud’s managed lifecycle may be cheaper than risk — even if self-hosting feels “free” on paper.

**Image hygiene:** pin **`clickhouse-connect`** in the same change management process as Superset version bumps; treat driver bumps as **release artifacts** with notes and rollback plans.

### **Summary table**

| Criterion | Hybrid (Tinybird → Postgres) (Option 1) | Preset Cloud (Option 2) | Self-hosted Superset (Option 3) |
| --- | --- | --- | --- |
| **Ops burden** | Highest | Lower (vendor) | Higher |
| **Native CH SQL** | Limited | Yes | Yes |
| **API reuse** | Yes | No | No |
| **Blast radius** | Lower for broad users | Medium | Medium |

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

- Choose **Option 1** when **Tinybird** already defines metrics you must not duplicate in ad hoc SQL — the **default** when multiple systems consume the same definitions.
- Choose **Option 2** when Preset Cloud fits your **security review** and you want **fastest** time-to-dashboards on ClickHouse®.
- Choose **Option 3** when **data residency** or **custom networking** mandates self-hosting.

**Bottom line:** prefer **Tinybird hybrid (Option 1)** when **APIs + governed charts** matter together. Use **Preset Cloud (Option 2)** or **self-hosted (Option 3)** when **native ClickHouse® SQL** for a wide analyst population is the overriding goal — Preset is still **Superset + operations** at the core, and integration quality depends on **driver**, **network**, and **governed SQL**.

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

**clickhouse integration preset** means connecting **Preset** (managed Superset) or a **Superset-compatible** deployment to **ClickHouse®** so charts, datasets, and SQL Lab run against ClickHouse® data.

Care when **dashboard concurrency** or **data volume** breaks slower warehouses. ClickHouse® handles large fact tables and continuous **[streaming data](https://www.ibm.com/think/topics/streaming-data)** ingestion patterns common in analytics stacks.

If your Preset usage is small-team and Postgres is fast enough, you may not need ClickHouse® yet — revisit when **p95 chart latency** becomes a recurring complaint.

Many “BI is slow” issues are actually **[OLTP vs OLAP](https://www.tinybird.co/blog/oltp-vs-olap)** problems: the operational database is optimized for transactional writes, not for wide aggregations Preset generates when users explore freely.

## **Preset Cloud vs self-hosted: what changes for clickhouse integration preset**

**Preset Cloud** centralizes upgrades, authentication integrations, and some operational policies. Your team still owns **ClickHouse® credentials**, **network paths**, and **query governance**.

**Self-hosted Superset** shifts patching, backups, and incident response to your platform team — but you gain **VPC-local** placement next to ClickHouse® without negotiating SaaS egress patterns.

Neither option removes the need for **[cloud computing](https://www.ibm.com/think/topics/cloud-computing)** hygiene: secrets rotation, least privilege, and monitoring are still yours.

## **Rollout playbook (practical)**

**Stage A — connectivity smoke test:** create a read-only user, grant **one small view**, connect Preset, and run `SELECT 1` plus a bounded aggregate.

**Stage B — representative datasets:** migrate **three** high-traffic datasets first; compare **row counts** and **latency** against the legacy warehouse.

**Stage C — guardrails:** enable **limits** on the ClickHouse® user; add **query_log** sampling to your observability stack.

**Stage D — training:** publish examples of **good** time filters and **bad** high-cardinality breakouts.

**Stage E — review cadence:** monthly review of top expensive queries and whether they should move to **MVs**.

This staged approach keeps **clickhouse integration preset** from becoming a big-bang outage story for your analysts and customers.

Document owners for each stage so accountability stays clear across data, security, and platform teams.

## **Schema and pipeline design**

### **Rules for Preset-on-ClickHouse®**

**Rule 1:** partition facts by **time** for pruning.

**Rule 2:** use **`LowCardinality(String)`** for categorical dimensions.

**Rule 3:** build **datasets** on **views** or **MV-backed tables** for popular charts.

### **Example MV (AggregatingMergeTree + *State)**

```sql
CREATE TABLE preset_events (
  event_id UInt64,
  user_id UInt64,
  event_type LowCardinality(String),
  event_time DateTime,
  amount Float64,
  updated_at DateTime
)
ENGINE = ReplacingMergeTree(updated_at)
PARTITION BY toYYYYMM(event_time)
ORDER BY (event_type, event_time, event_id)
```

```sql
CREATE MATERIALIZED VIEW preset_events_daily_mv
ENGINE = AggregatingMergeTree()
PARTITION BY toYYYYMM(day)
ORDER BY (event_type, day)
AS SELECT
  toDate(event_time) AS day,
  event_type,
  countState() AS events_state,
  sumState(amount) AS revenue_state,
  uniqState(user_id) AS users_state
FROM preset_events
GROUP BY day, event_type
```

**Read query:**

```sql
SELECT
  day,
  event_type,
  countMerge(events_state) AS events,
  sumMerge(revenue_state) AS revenue,
  uniqMerge(users_state) AS users
FROM preset_events_daily_mv
WHERE day >= today() - 90
ORDER BY day DESC
```

### **Failure modes**

1. **Allowlist / TLS mismatch for Preset Cloud egress.** Connections fail after infra changes. **Mitigation:** treat allowlists as code; test from Preset after every ClickHouse® network change.

2. **Driver upgrade drift.** Superset/Preset upgrades can change supported driver pins. **Mitigation:** pin versions in your build; validate in staging.

3. **SQL Lab “SELECT *” accidents.** Wide scans hurt ClickHouse® and Preset UX. **Mitigation:** views, training, and **query limits** on the DB user.

4. **Hybrid sync failures (Option 1).** KPI tables go stale silently. **Mitigation:** freshness columns, job alerts, reconciliation queries.

5. **Credential sharing.** One shared reader becomes impossible to rotate. **Mitigation:** per-environment users and a **secrets manager**.

## **Security, networking, and governance**

Preset Cloud introduces a **SaaS BI** trust boundary. Document **who approves** database credentials, how **rotation** works, and which **schemas** are exposed to which Preset roles.

ClickHouse® should use **read-only** users, **TLS**, and ideally **row policies** for multi-tenant datasets.

If you must connect Preset to **private** ClickHouse®, follow Preset’s documented connectivity patterns (allowlists, tunnels, peering) — do not “temporarily” expose plaintext HTTP to the public internet.

## **Latency and cost discipline**

Preset charts can refresh frequently. ClickHouse® costs track **bytes read** and **CPU** — not “number of charts.”

Design for **[low latency](https://www.cisco.com/site/us/en/learn/topics/cloud-networking/what-is-low-latency.html)** with **MVs** and **tight time filters**, and measure before promising fixed numbers.

For [real-time dashboards](https://www.tinybird.co/blog/real-time-dashboards-are-they-worth-it), validate concurrency in staging: open the same dashboard in **N tabs** and watch ClickHouse® `system.query_log`.

## **Why ClickHouse® for Preset workloads**

Preset issues the same style of **aggregations** and **time filters** as Superset. ClickHouse® executes those patterns on **columnar** storage — the profile teams associate with [fastest database for analytics](https://www.tinybird.co/blog/fastest-database-for-analytics) workloads.

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

Tinybird helps when Preset is only one consumer and you also need **HTTP JSON endpoints** with **parameter contracts**.

Use Pipes for **canonical metrics**, then either:

- let specialists query ClickHouse® directly in Preset (**Option 2** / **Option 3**), and/or
- sync **bounded** Pipe outputs into Postgres for broad Preset datasets (**Option 1**).

This aligns with [real-time data ingestion](https://www.tinybird.co/blog/real-time-data-ingestion), [real-time data processing](https://www.tinybird.co/blog/real-time-data-processing), and [real-time analytics](https://www.tinybird.co/blog/real-time-analytics-a-definitive-guide) patterns: one transformation layer, multiple consumers.

If your product team already treats Tinybird as a **[downstream system](https://medium.com/@ogunodabas/downstream-upstream-system-c1dc6cf4b59e)** for metrics, Preset should consume the **same** definitions where possible — fewer reconciliation meetings.

When stakeholders ask for the [best database for real-time analytics](https://www.tinybird.co/blog/best-database-for-real-time-analytics) **stack**, the answer is rarely “only Preset” or “only ClickHouse®” — it is the pairing of **OLAP storage**, **governed datasets**, and **serving APIs** appropriate to each audience.

Next step: pick your **top Preset dataset**, inspect generated SQL, and decide whether it should query a **raw table**, a **view**, or an **MV-backed** table — then re-test **p95** load time.

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

### **Is clickhouse integration preset different from Superset + ClickHouse®?**

Operationally, Preset Cloud is **managed Superset** plus vendor operations. The **database connection** mechanics are in the same family as **Superset + `clickhouse-connect`**, but **networking**, **upgrades**, and **support** differ because Preset runs the control plane.

### **Which SQLAlchemy URI should I use for clickhouse integration preset?**

Use the **`clickhousedb://...`** form recommended by Preset/Superset docs for **ClickHouse Connect**, with `secure=1` when using TLS. Always validate against your ClickHouse® provider’s hostname and port (**8443** common for TLS).

### **Can clickhouse integration preset work with private ClickHouse®?**

Yes, with the right **network path** (allowlists, VPN, peering, tunnels) between **Preset Cloud egress** and your ClickHouse® endpoint. Treat this as a **joint infra** project — not a one-line config change.

### **Does Tinybird replace ClickHouse® for clickhouse integration preset?**

No. Tinybird is a **managed serving and ingestion** layer on top of ClickHouse®-class storage. It **complements** Preset when you need **APIs** and **governed metrics**, not when you only need BI charts on raw tables.

### **How do I reduce costs after clickhouse integration preset goes live?**

Add **MVs**, tighten **default time ranges**, enable **caching** where appropriate, and teach authors to avoid high-cardinality breakouts. Monitor **`query_log`** weekly for outliers.

### **What is the biggest mistake teams make with clickhouse integration preset?**

Connecting Preset with a **superuser** account and unlimited resources — it works until the first expensive SQL Lab query. **Least privilege** and **limits** are day-one requirements.

### **How do I test clickhouse integration preset without impacting production?**

Create a **staging** ClickHouse® database (or a dedicated service user) with a **subset** of data, connect a **non-production** Preset workspace, and replay the top charts there. Compare **query plans** and **bytes read** before switching production connections.

### **Can clickhouse integration preset embed charts in my product?**

Preset/Superset supports embedding patterns, but embedding is a **separate security topic** from warehouse connectivity. Treat embed tokens like production secrets and avoid exposing **long-lived** warehouse credentials in the browser — use server-side proxies where required.