ClickHouse as a data destination: the complete guide for data teams

Increasingly, data teams need to answer queries in milliseconds on data volumes that grow every day: product events, application logs, operational metrics, and dashboards queried in real time by dozens of users simultaneously. The traditional data warehouse remains essential for broad analytical modeling, but it was not designed for this specific type of workload. That's where ClickHouse enters the conversation.

In this article, we will cover:

• What is ClickHouse

• Why consider ClickHouse as a data destination

• Key use cases

• The difference between ClickHouse and a traditional data warehouse

• How data ingestion works in ClickHouse

• How to activate the ClickHouse destination in Erathos

What is ClickHouse

ClickHouse is an open-source, column-oriented (columnar) database management system designed specifically for analytical queries (OLAP) on large volumes of data. It also exists as a managed service, ClickHouse Cloud.

The structural difference compared to a transactional database (OLTP) lies in how the data is stored and read. A row-oriented database optimizes for retrieving an entire record quickly, the typical pattern for an application. A column-oriented database like ClickHouse stores and compresses each column separately, allowing it to scan and aggregate billions of rows while touching only the columns required for the query, using vectorized query execution.

This design is the reason why ClickHouse has become the benchmark for workloads where read speed over massive volumes is the core requirement, not just the stored volume itself.

Why use ClickHouse as a data destination

Historically, "data destination" was synonymous with data warehouses: BigQuery, Snowflake, Redshift, Databricks. It makes sense, as these systems are optimized to answer business questions over broad historical data, with latencies from seconds to minutes being acceptable for most analytical use cases.

But there is a class of workloads where this latency is unacceptable:

• A product dashboard queried by dozens of users at the same time, which needs to respond in milliseconds

• An observability pipeline that needs to aggregate logs and metrics in real time

• A funnel or cohort analysis on an event table with billions of rows, continuously updated

• A use case where write volume is high and constant, and the destination system needs to keep up without degrading read performance

In these cases, forcing a traditional data warehouse to serve as a direct read source usually gets expensive in two ways: latency beyond what the product tolerates, and a rapid spike in cost per query under heavy usage. ClickHouse exists precisely for this access pattern: heavy aggregation, high concurrent reads, and millisecond responses.

Use cases for ClickHouse as a destination

1. Real-time product dashboards

Teams that expose usage, engagement, or performance metrics inside their own products—either for end customers or internal use—need a destination that responds quickly even under concurrent queries. Ingesting raw data sources (product, CRM, billing) into ClickHouse allows you to serve these dashboards without the typical latency of a real-time queried warehouse.

2. Event and log analytics at scale

Event tables grow fast, and most queries about them involve aggregations (counts, sums, percentiles) over a time window. This is exactly the access pattern that ClickHouse's columnar storage was optimized for.

3. Observability and operational metrics

Monitoring data, infrastructure metrics, and application logs follow the same pattern of high-volume writes with analytical reads. Consolidating these sources into ClickHouse via Erathos avoids having to maintain a custom ingestion pipeline for each telemetry source.

4. Funnel and cohort analysis with high cardinality

Questions like "what is the conversion rate per user cohort, segmented by channel and week" require aggregation over high-cardinality dimensions. At scale, this type of query is typically where a traditional data warehouse starts to get expensive or take too long to return.

ClickHouse vs. data warehouse: when to use which

It's not a matter of replacing one with the other. In practice, they often coexist in the same data stack, each solving a different type of workload.

Mature teams usually operate both side-by-side: the warehouse for the modeling and corporate BI layer, and ClickHouse for workloads where read speed over massive volumes is the core requirement. The right question to ask is: who will query this data, how often, and with what latency expectations?

How data ingestion works in ClickHouse

There are three main paths to load data into a ClickHouse database:

1. Direct inserts via client or driver. This works for low volumes and data generated by your own application, but doesn't scale for consolidating multiple external data sources.

2. Custom scripts running on cron. Flexible at first, but quickly becomes a maintenance burden. Every new source becomes a separate engineering project, with manual handling of retry logic, failure alerts, and schema evolution.

3. Dedicated ingestion tool. You point to the source, select ClickHouse as the destination, and the platform handles the extraction, alerting, and observability of each execution sync.

For any scenario where ClickHouse needs to receive data from more than one source, path 3 is what keeps your ingestion maintenance from growing along with your number of sources.

How to activate the ClickHouse destination in Erathos

Erathos connects to any ClickHouse instance, whether in ClickHouse Cloud or a self-hosted deployment (VM, Kubernetes, Docker, or any other environment). In both cases, the connection uses the same four credentials: Host, Port, Username, and Password.

In ClickHouse Cloud, this information is available in the service console:

• Host: the service URL, usually ending in .clickhouse.cloud

• Port: typically 8443 for HTTPS

• Username: the database user (usually defaults to default)

• Password: the service password, shown only once upon creation (if lost, you must reset it in the service settings)

In a self-hosted deployment, this information comes from your own server configuration or database administrator:

• Host: the hostname or IP of your ClickHouse server

• Port: the port exposed by the server (typically 8123 for HTTP or 8443 for HTTPS, depending on setup)

• Username and Password: the user with required permissions and its password

• You must ensure that the server is accessible to Erathos by adding the platform's IP (35.212.87.86) to your firewall whitelist

Quick setup steps

1. Gather host, port, username, and password (via ClickHouse Cloud console or from your self-hosted ClickHouse administrator)

2. If using self-hosted, confirm that your firewall allows the Erathos IP

3. In Erathos, go to Settings → Destination, select ClickHouse, and fill in the four connection fields

4. Save the configuration to finish setup. When you create your first pipeline pointing a source to ClickHouse, you will also select the target schema; the platform will manage table creation and schema evolution from that point on

The official ClickHouse destination documentation has the complete step-by-step guide.

Conclusion

The question that used to be "can the warehouse handle this volume?" is increasingly becoming "does the warehouse respond fast enough for this use case?". For product dashboards, observability, and high-volume event analytics, the answer is often no, and that's where ClickHouse comes in as a complementary piece of your data stack rather than a replacement. What changes the experience of maintaining this destination day-to-day is the same thing that changes it for any other: ingestion with real observability, instead of a script that only one person on the team understands.

If you want to ingest data into ClickHouse in a controlled, observable way without having to maintain your own scripts, check out the ClickHouse destination on Erathos.

FAQ

Does ClickHouse replace a data warehouse? Yes, in many scenarios. ClickHouse is a high-performance, columnar OLAP database, and today it is even used for traditional data warehousing workloads, not just niche cases. Where it particularly shines is in architectures with massive ingestion rates and extreme speed requirements: real-time dashboards, events at scale, and observability. Teams with an already established ecosystem around another warehouse, or those prioritizing company-wide historical modeling over raw latency, usually run both side-by-side instead of migrating fully.

Can I use ClickHouse as a destination for any source that Erathos already supports? Yes, ClickHouse is available as a destination alongside all other sources on the platform, using the same setup as other destinations.

What is the minimum sync frequency? It depends on the source. Erathos supports sync schedules from every few minutes to daily, configured at the table level.

Does it work with self-hosted ClickHouse, outside of ClickHouse Cloud? Yes. Erathos connects both to ClickHouse Cloud and self-hosted deployments (VM, Kubernetes, Docker, or any other environment) using the same four connection credentials. For self-hosted instances, you just need to whitelist Erathos's IP in your server's firewall.

Do I need to create tables manually in ClickHouse? No. Erathos manages the connection automatically: you provide the access credentials and choose the target schema, and the platform handles table creation and schema evolution as the source changes.