Who ClickHouse Competes With (and Who It Doesn't)

One of the things I'm quick to point out about ClickHouse is its versatility. When it started, its natural place was in append-only logging workloads. However, when I began working with it around five years ago, I could see that it was also close to becoming a viable platform for much broader use cases such as data warehousing, search, time series and observability.

Today, as those capabilities have been rounded out, ClickHouse can play credibly in all of those areas and fulfill multiple use cases in any given business. This puts it in the unusual position of being compared and evaluated against pretty much everything in the market at the same time.

With this in mind, I wanted to write about the databases I'm seeing ClickHouse come up against, and talk about how I see ClickHouse competing with them. This isn't intended to be critical of any other project as every database does have its strengths and sweet spots. It's more an experience report of the conversations I am having and how I personally think ClickHouse competes in each category.

MySQL and Postgres

MySQL and Postgres are common topics in my ClickHouse projects.

Often, the situation is that an application has grown in amount of data and the number and complexity of analytical queries. The application experience begins to slow down and dashboards are slow to load. The challenge is that MySQL and Postgres are great transactional databases, but they naturally begin to struggle with analytics over big data as you reach the tens and hundreds of millions of rows.

ClickHouse doesn't ever intend to replace a transactional OLTP system, so it has instead taken the route of collaboration in both the open source and cloud space. ClickHouse Inc have even created their own managed Postgres service and have invested in integration routes such as ClickPipes and WAL Shadow so that the two can be run side by side.

Both the narrative and the reality is that OLTP workloads should stay in MySQL or Postgres, and then be integrated into ClickHouse for OLAP analytics. The emphasis there is on reducing the friction between the two rather than any form of competition.

MongoDB

MongoDB is a similar situation to MySQL and Postgres. People want to run more types of analytics over their data, but find that Mongo isn't performant or flexible for aggregations, particularly as the data volumes and the complexity of the queries grow.

This conversation also tends to be about integration. Moving an application off MongoDB would be a large rewrite for most companies, and it would be hard to justify when it works well as the operational store. So the pattern I see is to let Mongo continue to do the OLTP side, and offload the analytics to ClickHouse.

Elastic

Elastic and OpenSearch are the most frequent competitive situations for me in 2026. Elastic was initially built around its search capabilities, but people have extended it for various observability, security and analytics use cases.

The challenge people seem to come up against is a lack of flexibility. They can't achieve everything they want with it, and performance on analytical queries and aggregations over large volumes isn't where they need it to be.

Cost has also increased over time to the point where it's becoming an issue but not to the extent of some of the other platforms I'm going to discuss.

Datadog

Datadog has very much been a theme in my conversations this year, as ClickHouse have built out their observability capabilities.

As with Postgres, there has been some collaboration. ClickHouse can be used as a backing store for Datadog, and there are out-of-the-box integrations with both ClickHouse Cloud and open source. ClickHouse are also full of praise for how Datadog has built their platform and executed their business.

People generally love Datadog, but cost comes up an awful lot. This means that companies have to limit the data they retain, sample data and have to be selective about the modules they use.

At the same time, ClickHouse is a really good and natural fit for this observability workload. Data can be pushed in with high concurrency, it compresses well and it can be queried interactively from all angles.

The way I see this market going is that people will put their OTel metrics, logs and traces into ClickHouse and then ask questions about them using agents. ClickStack then sits on top and covers the GUI, alerting and management side. The two are head-to-head here, and I think the ClickHouse case is very compelling.

Microsoft SQL Server

I've had a lot of conversations and carried out a lot of work around migrating from Microsoft SQL Server to ClickHouse.

SQL Server is an OLTP database, but it is also widely used for OLAP-type workloads. That might be through features such as clustered column store indexes, or it may simply be that applications have grown into more analytical workloads over time. At a certain scale, query latency starts to creep up, and it can become expensive if you're running it in Azure as you need to keep adding more compute.

MySQL and Postgres are squarely OLTP databases used for that purpose, whereas SQL Server does get used for more analytical use cases. So with SQL Server, it's more often a migration conversation.

I've been involved in a few of these migrations and we've seen 50%+ cost savings in reality, as well as big performance speedups so I expect to see growth in this migration route.

KDB

Partly because of the circles I move in, I have a lot of conversations about how ClickHouse can replace KDB.

KDB is a niche database which many readers probably won't have heard of. It's used extensively in capital markets and investment banking, often for front office use cases such as risk and trading, but also for a number of middle and back office use cases.

The challenge with KDB is that the technology is very proprietary and niche. It uses a language called q, which is famously terse and hard to work with. KDB is very expensive and getting more so, with private equity backers turning the screws on their customers. It's also hard to operate, to scale, and to put a software development lifecycle around. The licencing challenge bites you everywhere as you can't work how you wish due to licensing restrictions.

There's a lot of pain in the market, and capital markets firms are looking for an alternative. ClickHouse is a good fit and the natural successor, with the low-latency capability to meet the majority of KDB use cases. KDB is more in-memory than ClickHouse, so for real-time market making or algo trading it's probably still the right choice, but for anything with latency requirements in the low milliseconds and up, ClickHouse can compete.

Replacing a KDB workload with ClickHouse gives you a much more open technology. It's SQL-based, it's easier to find skills for, and the licencing situation is much better. There's a cloud offering or on premise deployment options for co-location, so it's a really strong and compelling offer. I've written more on this in ClickHouse In Capital Markets.

Splunk

I've had a number of conversations and delivered competitive projects against Splunk in the security analytics and SIEM space. Splunk is famously expensive. They do now have pricing models that aren't purely based on cost per GB ingested, so they've responded to that, but it's still expensive.

ClickHouse is a very natural fit for this workload, both on cost and on query performance, and they've recently acquired a company called RunReveal to build out the UI and workflows on top of it.

Snowflake

A lot of companies have just spent years implementing Snowflake. It's often the newest thing in their stack, so it's a harder conversation than replacing a legacy database on both technical and political grounds. The conversation therefore gravitates to where ClickHouse is strong - the real-time, high-concurrency and latency-sensitive use cases.

Snowflake is great for internal BI and batch reporting, but it isn't really designed for real time analytics or situations where lots of users are issuing queries at the same time and expecting sub-second latency over real time data.

With both supporting Iceberg, there's an emerging story for the two sitting side by side on the same data. Snowflake can write to Iceberg and ClickHouse could be used for serving interactive analytics. I'm not sure if this will play out but it's a conversation I have had this year.

ClickHouse have published some real-time analytics benchmarks against Snowflake which are worth a look if you're having this conversation. I've also compared the two on cost in ClickHouse vs Snowflake Pricing.

BigQuery and Redshift

Given they're OLAP stores, I hear about BigQuery and Redshift less often than I'd expect.

The point I would make about both of these is that they are inherently tied to their cloud vendors, whereas ClickHouse can be run anywhere including on premise.

ClickHouse also competes strongly with both with regards to latency and concurrency. Like Snowflake, you probably wouldn't use them as an application backend with hundreds of users in the way that you would ClickHouse.

Databricks

Databricks is a very strong platform. Fully featured, collaborative, open standards and cloud based. It also has similar open source roots to ClickHouse, so there's a lot to be said for it.

However, it isn't good for real-time analytics or anything highly interactive. It's built on Spark, and creating the Spark context and issuing your query can take some time before you even begin processing your data. It's designed for very large big data workloads, where the overhead of Spark is outweighed by the sheer volume of data being processed.

ClickHouse scales down to smaller workloads, so it can be used with a couple of million rows, or for backing applications in a way I don't think Databricks is appropriate for.

Data Lakes

Databricks takes me to data lakes more generally. Data lakes have been popular for the last 10 or so years, with people storing their data on object stores such as S3. More recently, we've had a lot of innovation in relation to Iceberg and Delta.

I used to recommend this architecture a lot personally, but I've been burnt. I often find you end up reinventing a database, so companies spend a lot on data engineers rather than innovating with their data. And again, the query latency and performance just isn't there for the areas where ClickHouse plays. Data lake architectures can be quite slow. I've written about this in Data Lakehouse Architecture Skepticism.

That said, there's been collaboration here too. ClickHouse supports Parquet, Delta and Iceberg, and can read from and write to S3 and Azure. So it's very much a collaborative relationship with scope for integration.

Niche Databases

We also come across a number of niche databases such as Timescale, Pinot, Redis and Cockroach. These are good within their niche and are probably the right choice for highly specific workloads, but they don't have the fully featured platform story, ecosystem or capitalisation of ClickHouse.

What AI Changes

AI is starting to reshape all of these conversations, and I think it plays into ClickHouse's hands in three ways.

Agents don't query data like a human analyst does. A single question can turn into dozens of queries, and you might have many agents running at once. That's a low level and high-concurrency workload which plays squarely into ClickHouse's hands.

I have mentioned cost quite a few times in my analysis above. What will happen is that because these technologies aren't as scalable as ClickHouse, you will have to keep scaling up and scaling out. Even if the unit cost is low, you will need so many units that cost grows and grows to meet your AI ambitions.

This is an area I'm spending a lot of my time on at the moment. You can read more about how we're helping companies with it on our agentic AI page.

Benchmarks

If you want to dig into the numbers, ClickHouse have published a lot of benchmarking work. CostBench is the newest, comparing cost-performance across the full path of ingesting, preparing and querying data in ClickHouse Cloud, Snowflake, Databricks, BigQuery and Redshift. There's also a TPC-H comparison against the same four warehouses, and the full set of benchmarks, including ClickBench, is on the ClickHouse benchmarks page.