Data Panda lifts data from your CRM, ERP, ecommerce, product and event systems into ClickHouse on a known schedule. Once it sits in one columnar warehouse, your dashboards, automations, AI workflows and internal apps query the same tables and get answers back in milliseconds instead of minutes.
ClickHouse started inside Yandex in 2009 as an internal analytics engine for Yandex Metrica, the company's web-analytics product. It was released as open-source software under the Apache 2.0 license in 2016, and ClickHouse Inc was incorporated in San Francisco in September 2021. The company now ships the open-source database alongside ClickHouse Cloud, a managed offering on AWS, GCP and Azure.
The architectural choice that defines ClickHouse: columnar storage with vectorized execution. Tables are stored column by column on disk, queries read only the columns they touch, and the engine processes data in batches that map cleanly onto modern CPU instructions. The MergeTree family of table engines layers a sparse primary-key index on top, with granules of 8,192 rows by default, which is what lets a single server scan billions of rows in a second or two. The flip side is that the design choices made on day one (the ORDER BY key, the partition expression, the compression codec) decide how the warehouse performs six months later, when the table is at 50 billion rows and the queries that used to return instantly now scan the whole thing. We land the data, model it for the queries you run in production, and pick the engine settings so ClickHouse stays in its sub-second sweet spot instead of degrading into a slow scan engine.
BI tools query ClickHouse fact tables and return aggregations on billions of rows in milliseconds.
Operational and event data lands in ClickHouse continuously or in scheduled batches, not per dashboard.
ClickHouse stores vectors next to your fact tables, so embedding and aggregate queries hit one engine.
Internal tools and customer portals query ClickHouse directly and get answers in time for the next click.
A list of concrete reports, automations and AI features we have built on ClickHouse data. Pick the one that matches your situation.
Why does our ClickHouse query that used to take 200 ms now scan every part on disk?
Almost always because the partition key has too many values, so ClickHouse can no longer prune partitions and the merge scheduler is falling behind. A common version is partitioning by day on a table that should be partitioned by month, or by user id when the query never filters on user id. Reworking the partition expression and the ORDER BY on the heaviest tables usually puts the query back where it was.
Should we run ClickHouse Cloud or self-host on our own servers?
ClickHouse Cloud separates storage and compute, scales idle resources to zero and removes the operational work of running the cluster yourself. Self-hosted is meaningfully cheaper at steady high load, especially when you already have hardware or AWS commitments, but you carry the upgrade, replication and backup work. We size both options against the actual query and ingest profile before making the call.
We use Snowflake or BigQuery for the rest of the business. Where does ClickHouse fit?
Snowflake and BigQuery are excellent for daily and weekly reporting on warehouse-grade data. ClickHouse fits when the workload is event-shaped, the table is in the billions of rows, and the dashboard or app needs to return in under a second. Many BE/NL stacks run Snowflake or BigQuery for finance and CRM analytics and put ClickHouse next to it for product events, observability or embedded customer-facing analytics.
The CFO gets a real-time view on cost-per-event, infrastructure spend per product line and unit economics on usage data that used to be stuck in logs. ClickHouse stores the event history at warehouse compression, and reports that took an overnight job now refresh in seconds.
Sales sees product engagement, account usage and feature adoption on the same fact tables the CRM reads from. Account reviews stop relying on a sample export from last week because the warehouse can answer per-account questions in real time.
Ops and platform teams get logs, metrics and traces in one columnar store with warehouse-grade compression. Incident review reads the same data the dashboards do, and the observability bill stops being the loudest line on the cloud invoice.
You keep the reporting tool you already have. We connect it to the warehouse where your ClickHouse data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
ClickHouse Cloud (managed on AWS, GCP or Azure) separates storage and compute and scales idle resources to zero, which fits spiky or growing workloads where you do not want to run the cluster yourself. Self-hosted is meaningfully cheaper at sustained high load, but you carry replication, backup and version upgrades. We size both against the actual ingest rate, query mix and team capacity before making the call.
ClickHouse uses a sparse primary-key index with granules of 8,192 rows by default, so the ORDER BY key decides which queries get sub-second latency and which scan the table. The partition expression decides whether ClickHouse can prune entire parts at query time and whether the merge scheduler keeps up. The official docs explicitly warn against partitioning by high-cardinality fields like client identifiers; those belong in the ORDER BY, not the PARTITION BY.
ClickHouse wins on workloads where the table is in the billions of rows and the dashboard or app has to return under a second, typically product events, clickstream, observability, ad-tech and embedded customer-facing analytics. Snowflake and BigQuery remain stronger for governed enterprise reporting on smaller, slower-changing data. Plenty of stacks run both: Snowflake or BigQuery for finance and CRM, ClickHouse next to it for the high-cardinality, low-latency workloads.
We review your ClickHouse setup and the systems around it. Together we pick the first thing worth building.