Live data from Hacker News

Ten years of ClickHouse in open source

clickhouse.com

51–60 of 110 posts

Re: Ten years of ClickHouse in open source

#51

Earlier quoted context omitted.

[flagged]

Given that american ignorance is a cultural thing (with many people deliberately electing the way grandpa did it) is it not kind of racist to generalize americans as unknowingly racist? You said, "ask a random stranger...and he will honestly say no" not "ask a random stanger...and he will probably honestly say no". Most of most people are racist, it's just different groups. Americans obviously have less distrust of a…

> but then I am just as certain that there are many many humans who would proudly share their "dumb american" stories as if that is not every bit as prejudicial to those of us who do not fit the description as any other "weak french" or "commie russian" or "sister fucking indian" or whatever else.

Racism is about race (i.e. phenotypical or genotypical properties), while being US-American/French/Russian/Indian/... is about nationality. So, these stories are not about racism (since they are not about race), but about prejudices against other nations/nationalities.

Re: Ten years of ClickHouse in open source

#52
It's interesting that the blog post places SQLite and Ladybird on the spectrum, but omits it's chief open source rival: DuckDB.

Agree that Level 3 is what inspires confidence. But we need to invent new business models to sustain in the era of vibe-coded databases.

Re: Ten years of ClickHouse in open source

#53
post #40
post #19

Earlier quoted context omitted.

Worked on peerdb. If you're able to batch changes on your end & push to both postgres & clickhouse, do that. Only move to peerdb when you know you need cdc

Just looked up PeerDB expecting a Db as per its name. But it’s a ETl tool. Stupid naming

I know I know. Some people have loved it as it captures what it does (peering dbs) and some haven't because of the exact reason you called out. So we get it! :)

Re: Ten years of ClickHouse in open source

#54
post #43

If your data is too big for postgres, it seems like moving straight to Clickhouse is the best option. We have been through an whole array of distributed database technologies, and Clickhouse might be first one that doesn't have too many compromises.

What do you mean? Postrgesql is a relational and row based db, ClickHouse is columnar Clickhouse doesn’t replace postgresql:

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

Re: Ten years of ClickHouse in open source

#55
post #16

ClickHouse recently has been a breath of fresh air compared to using timescaledb for a long time. Although psql is the greatest there is and I really enjoyed the fact that I could rely on a single database system to run everything, when it came to migration maintenance and deployment it's really a pain and it also feels like development on timescaledb is a bit wishy washy with all the structural changes from version…

I was using TimescaleDB some very long time ago, things have changed quite a lot since (it's now even named differently). In my current setup I was thinking on doing both: upgrading postgresql to timescaledb (to archive old data etc.), and to deploy ClickHouse in parallel. I'm still considering whether to go big on PeerDB to get ClickHouse mirror or just deploy it separately without additional fragility layer. Would…

In my (minor) experience Timescale works fine. The developer experience is good and it is very convenient to be able to JOIN against your hypertables. My only real complaints are operational (no logical replication, normal postgres update complaints), but man Clickhouse is really slick. I wrote some small reviews of the two in my submission history if you want a bit more detail.

Re: Ten years of ClickHouse in open source

#58
post #11

I discovered ClickHouse around 2017-18 and built a PoC to replace Elasticsearch: 5x better storage and qps, in a couple of weeks. Managers rejected it because it wasn't well known and was seen as "some database made by Russians." On a personal level, it's quite sad to have seen that train coming so early and not been able to get on board.

[flagged]

[flagged]

Re: Ten years of ClickHouse in open source

#59
post #29
post #14

Earlier quoted context omitted.

How do you use it for visualization? Do you use ClickStack? or something else?

Still via Grafana. I ran it side-by-side with Loki and despite trying to optimise Loki and using ClickHouse out of the box - it really was shocking how much faster ClickHouse was for every single query (e.g. in the last 12 hours give my the frequency of logs with a particular JSON event or even "find this log entry, then join back and find the number of times a different entry appears within the same correlation_id)

Interesting, so you can bind a Clickhouse table as an extension to Grafana? Would you make a little Gist / post about it to show?

Re: Ten years of ClickHouse in open source

#60
post #11

I discovered ClickHouse around 2017-18 and built a PoC to replace Elasticsearch: 5x better storage and qps, in a couple of weeks. Managers rejected it because it wasn't well known and was seen as "some database made by Russians." On a personal level, it's quite sad to have seen that train coming so early and not been able to get on board.

I had the same experience recently. Turns out ClickHouse would reduce our DB operations by 60%, remove the need for a TSDB, and reduce query times from ~300-500ms (and sometimes ~3s) to roughly ~75ms. Lastly, and most impressively we were already seeing a ridiculous level of compression and our storage cost benchmarks were reduced to the cost of S3. This took a $2-3M storage layer down to one measured in the single thousands per month.

ClickHouse is no panacea but if you understand how your data is accessed and thus how to arrange it you will get so many miles out of it.

Post reply on HN