ClickHouse vs PostgreSQL: OLAP vs OLTP, and When to Run Both

The short answer

Use PostgreSQL to run the application and ClickHouse to analyse what it produces. PostgreSQL stores rows, gives full ACID transactions, and handles frequent inserts, updates and point lookups. ClickHouse stores columns and is built for online analytical processing: scans and aggregations over very large tables, mostly appended to and rarely changed. ClickHouse's own documentation says as much: for applications with frequent reads and writes to individual records, it recommends Postgres as the system of record, with changes replicated into ClickHouse for analytics. If your analytical queries are starting to slow PostgreSQL down, adding ClickHouse alongside it is usually the answer, not replacing one with the other.

ClickHouse vs PostgreSQL at a glance

OLTP vs OLAP: why the storage layout matters

A row store keeps each record together on disk. That suits an application that reads or changes one order, one account or one session at a time, and it is what makes PostgreSQL's transactions, constraints and row-level locking natural. A column store keeps each column together. A query that sums one column across a billion rows reads only that column, and similar values in a column compress well. That is why ClickHouse is fast at analytics and why it handles single-row changes poorly.

ClickHouse's documentation is direct about the second half. Updates and deletes run as mutations, asynchronous background jobs that rewrite every data part the change touches, and the project's best-practice guide says to avoid them where possible. ClickHouse guarantees inserts, while multi-statement transactions remain experimental. PostgreSQL, on the other hand, can run analytical queries, and for modest data sizes with good indexes and partitioning it often does so well enough. The trouble starts when large analytical scans compete with the transactional workload on the same server.

Running ClickHouse and PostgreSQL together

The common pattern is PostgreSQL as the system of record and ClickHouse as the analytics store, with data flowing one way. The documented ways to connect them:

• Query PostgreSQL from ClickHouse. The postgresql table function runs SELECT and INSERT against a remote PostgreSQL server. Useful for joining a small dimension table or a one-off load, not for continuous replication.
• Change data capture. PeerDB, an open source CDC tool under AGPLv3 whose actively maintained targets are ClickHouse and Postgres, replicates Postgres changes into ClickHouse. ClickHouse Cloud offers the same through ClickPipes. ClickHouse also has a MaterializedPostgreSQL database engine, but it is marked experimental and needs a setting to enable.
• Through Kafka. If you already publish database changes or events to Kafka, ClickHouse's Kafka table engine can consume them directly into tables.

Whichever route you take, plan for the differences: ClickHouse tables are usually designed around their query patterns, sort key and partitioning, not copied one-to-one from the PostgreSQL schema, and updates arriving through CDC need a table engine and query pattern that handle changed rows.

When to choose which

• Choose PostgreSQL for application data, anything that needs transactions or frequent updates, and analytics small enough to run on a replica without hurting users.
• Choose ClickHouse for event, log, metric and clickstream data that is appended and queried in aggregate, especially when dashboards or reports scan large ranges.
• Run both when the application needs PostgreSQL and the analytics have outgrown it. This is the pattern ClickHouse's own documentation describes.
• Do not use ClickHouse as your application database. Its own documentation points transactional workloads elsewhere.

Release cadence and support

The two projects support releases very differently, and it matters for planning. PostgreSQL supports each major version for five years, then publishes a final minor release. ClickHouse ships a stable release roughly every month and supports only the latest three, plus two LTS releases for one year each. Its SECURITY.md, as of 7 October 2026, lists 26.9, 26.8, 26.7 and the 26.3 LTS as supported, and every 25.x release and older as unsupported. Analytics clusters are rarely upgraded that often, so many run releases that left support months ago.

Where OSSeva fits

OSSeva supports both under one contract. OSSeva for PostgreSQL backports security and data-corruption fixes to 11, 12 and 13, and to 14 after its community end of life on 12 November 2026, with Patroni and repmgr support. OSSeva for ClickHouse ships patched, signed builds for releases outside the community window, patches the ZooKeeper ensemble under replicated tables, and moves coordination to ClickHouse Keeper when you are ready; see ClickHouse support and ClickHouse Keeper vs ZooKeeper. Priced per cluster, not per core or per GB. Book a discovery call for a quote. For other options, see ClickHouse support providers.

Frequently asked questions

ClickHouse vs Postgres: can ClickHouse replace PostgreSQL?

Not for transactional work. ClickHouse lacks general multi-statement transactions outside an experimental feature, and updates and deletes rewrite data parts in the background. Use it next to PostgreSQL for analytics.

Can PostgreSQL be used for analytics instead of ClickHouse?

Often, up to a point. Read replicas, partitioning, good indexes and materialised views take PostgreSQL a long way for reporting. Move analytics to ClickHouse when large scans start competing with the application or when reports over event data become too slow.

ClickHouse vs TimescaleDB: which should we use?

TimescaleDB is a PostgreSQL extension for time-series and event analytics. It adds hypertables, which partition data into time-based chunks, and a columnstore, while keeping PostgreSQL's SQL, transactions and extensions in the same database. ClickHouse is a separate analytical database. Choose TimescaleDB when you want time-series analytics inside PostgreSQL without running a second system. Choose ClickHouse when analytical data is large enough, or the queries broad enough, to justify a dedicated column store. Check the licence as well: TimescaleDB's code outside its tsl directory is Apache 2.0, and code inside it is under the Timescale License.

ClickHouse vs Elasticsearch: which is better for logs?

They solve different parts of the problem. Elasticsearch is a distributed search and analytics engine, strongest at full-text search and relevance ranking. ClickHouse is strongest at aggregations over structured columns. For log analytics built on counts, percentiles and group-bys over structured fields, ClickHouse is a strong fit; for free-text search across messages, Elasticsearch or OpenSearch is. Elasticsearch is available under AGPLv3, SSPL or the Elastic License 2.0; OpenSearch is Apache 2.0.

Is ClickHouse open source?

Yes. ClickHouse is released under the Apache 2.0 licence, and it is also offered as a managed service, ClickHouse Cloud.

Is ClickHouse faster than PostgreSQL?

For large analytical scans and aggregations, ClickHouse's column storage is built for exactly that work. For point lookups, small transactions and frequent updates, PostgreSQL is the better tool. Test with your own queries and data rather than generic benchmarks.