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

More and more data teams need to answer questions in milliseconds on volumes that grow every day: product events, application logs, operational metrics, and dashboards queried in real time by dozens of users concurrently. The traditional data warehouse remains essential for broad analytical modeling, but it wasn't designed for this specific type of workload. That's where ClickHouse comes into play.

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 is also available 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 of an application. A columnar database, like ClickHouse, stores and compresses each column separately, which allows it to scan and aggregate billions of rows while touching only the columns needed for the query, using vectorized execution.

This design is the reason why ClickHouse has become the benchmark for workloads where read speed on high volume is the core requirement, not just the stored volume.

Why use ClickHouse as a data destination

Historically, "data destination" was synonymous with data warehouse: BigQuery, Snowflake, Redshift, Databricks. It makes sense; these systems are optimized for answering business questions over broad historical data, with latency of seconds to minutes being acceptable for most analytical use cases.

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

• A product dashboard queried by dozens of users concurrently, 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 events table with billions of rows, updated continuously
• A use case where write volume is high and constant, and the destination system needs to keep up with that pace without degrading read performance

In these cases, forcing a traditional data warehouse to serve as a direct read source is usually expensive in two ways: latency higher than what the product tolerates, and cost per query that scales rapidly with heavy usage. ClickHouse exists precisely for this access pattern, heavy aggregation, high read concurrency, and millisecond responses.

Use cases for ClickHouse as a destination

1. Real-time product dashboards

Teams that expose usage, engagement, or performance metrics within the product itself, for the end customer or internal use, need a destination that responds fast even under concurrent queries. Ingesting source data (product, CRM, billing) into ClickHouse allows you to serve these dashboards without the typical latency of a warehouse queried in real time.

2. Event and log analytics at scale

Event tables grow fast, and most questions about them involve aggregation (count, sum, percentile) over a time window. This is exactly the access pattern for which ClickHouse's columnar storage was optimized.

3. Observability and operational metrics

Monitoring data, infrastructure metrics, and application logs follow the same pattern of high write volume 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 on high cardinality

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

ClickHouse vs. data warehouse: when to use each

It is not a matter of replacing one with the other. In practice, both typically coexist in the same stack, each solving a different type of workload.

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

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 the application itself, but does not scale for consolidating multiple external sources.
2. Custom scripts running via cron. Flexible at first, but quickly becomes a maintenance liability. Every new source is a separate engineering project with retry logic, failure alerting, and schema evolution to manage manually.
3. Dedicated ingestion tool. You point to the source, choose ClickHouse as the destination, and the platform takes care of extraction, alerting, and observability for each execution.

For any scenario where ClickHouse needs to receive data from more than one source, path 3 is what keeps ingestion maintenance from scaling up alongside the number of sources.

How to activate the ClickHouse destination in Erathos

Erathos connects to any ClickHouse instance, whether in ClickHouse Cloud or on 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 access user (the default is usually default)
• Password: the service password, shown only once at creation time (if lost, you must reset it in the service settings)

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

• Host: your ClickHouse server IP or hostname
• Port: the port exposed by the server (commonly 8123 for HTTP or 8443 for HTTPS, depending on setup)
• Username and Password: the user with the necessary permissions and their password
• You need to ensure the server is accessible by Erathos, including adding the platform IP (35.212.87.86) to your firewall's 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 Erathos's IP
3. In Erathos, go to Settings → Destination, select ClickHouse, and fill in the four connection fields
4. Save the configuration to complete the connection. When creating your first pipeline pointing a source to the ClickHouse destination, you will also choose the destination schema, and the platform will handle table creation and schema evolution from there

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 analysis, the answer is often no, and that's where ClickHouse comes in as a complementary piece of the stack, not a replacement. What changes the experience of maintaining this destination day-to-day is the same thing that changes 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 Erathos's ClickHouse destination.

FAQ

Does ClickHouse replace a data warehouse? Yes, in many scenarios. ClickHouse is a highly performant columnar OLAP database, and today it is even used for traditional data warehousing workloads, not just niche use cases. Where it particularly shines is in architectures with massive ingestion and extreme speed requirements: real-time dashboards, events at scale, and observability. Teams with an already consolidated ecosystem around another warehouse, or those prioritizing broad corporate modeling over latency, typically operate both side-by-side instead of migrating completely.

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

What is the minimum sync frequency? It depends on the data source. Erathos supports schedules from minutes to daily, 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, you 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 destination schema, and the platform handles table creation and schema evolution as the source changes.