undefined

points

[-]

Sai from ClickHouse here. Totally with you here, ClickHouse isn't a replacement for Postgres. Most use-cases are co-existence - Postgres for OLTP and ClickHouse for OLAP, basically right tool for the right job situation. Both are purpose-built technologies with a similar OSS ethos/story. Btw on an interesting co-incidence, Postgres turned 30 this year and ClickHouse turned 10.

Above is exactly why we are embracing the Postgres + ClickHouse stack and are investing heavily to make workflows across both these DBs very easy for developers - PeerDB for native CDC, pg_clickhouse extension for querying CH from PG, pg_stat_ch for query PG observability from ClickHouse and more such are planned for future. And recently we also announced ClickHouse Managed Postgres which pacakages this entire stack as a fully managed service https://clickhouse.com/cloud/postgres

by spprashant5 hours ago|

prev|

[-]

This is a extremely common issue that happens in growing firms.

You start off with everything in Postgres, it makes the most sense. Soon you realize some tables are growing really huge - usually some sort of time-series or log data reaching 10TB+. You can no longer fit it in one node. You can try you luck with some sharding extensions, but they add complexity to upgrades.

In that case it makes total sense to move these large tables off Postgres, and I think Clickhouse is a straight up replacement here. You can still keep your relational heavy tables in Postgres.

Yes it affects you ability to cleanly join data, and guarantee 100% consistency. With some smart application code, and schema design, you can replace parts of Postgres with Clickhouse for the big data problem.

by ezekg18 minutes ago|

parent|

[-]

I did this exact thing this year. I moved about >5 TB of event and log data into Clickhouse. I went from having to increase Postgres storage capacity every few months ($$$) to never thinking about it. Migrating to Clickhouse took me from constant timeouts on analytics queries to all queries returning in well under 100ms, and automated data retention using TTLs going from nightly pruning jobs that failed constantly (Postgres hates DELETEs on large tables) to again, never thinking about it. Because of this, I was able to increase retention per-account from a mere 30 days like I had -- just to keep performance and storage costs under control -- to much, much longer. Huge fan.

by gempir5 hours ago|

prev|

[-]

You can keep "columnar" data in a row based database like postgres, it's just more expensive. But with little data that's fine and reduces infrastructural complexity. When you reach too much data it gets to a point where you then actually want to use the correct database for your usecase.

by eklavya5 hours ago|

prev|

[-]

Not to mention ACID and CAP and all that. I use clickhouse AND postgres. Clickhouse is not a replacement for postgres at all.