I have no doubt that, as usual, akulkarni will make a good PR job / community outreach to explain why, numbers and experience be damned, TimescaleDB is better!
I don't like responding to bullies and people who enter dialogues without good intentions.
But since this is a public forum, I'll answer your comment:
In general: ClickHouse is better than TimescaleDB for OLAP. TimescaleDB is better for time-series. If you don't believe me, that's fine! Each workload is different and you should test it yourself.
p.s. Let's keep HackerNews a more positive place. Negative comments are unnecessary, not productive, and honestly just make the author look immature.
I'm totally in favor for more positivity. It is very easy to criticize something when you don't know what is happening on the other side. HN is a place for Hackers to discuss facts and not to imply what they think others think. If two comparisons differ, there might be several reasons as lack of trials on both sides or lack of a common ground for comparison but a lot here are doing their best to make lives of developers easier.
Sometimes, after trying to engage positively and giving the benefit of doubt, I start to notice some disturbing things. When that happens, I speak my mind, and escalate progressively depending on how trustworthy I believe the person I'm talking to is.
Here, I provided a link to the previous discussion, because personally, I do not appreciate being mislead. I encourage you to check the technical details there if you don't believe me.
But maybe not being 100% positive and supportive is no longer acceptable in 2021? Or maybe it's the complexity of the issues discussed?
So let's give a simpler message: as rkwasni said it best just yesterday: "It's really quite easy, if you don't need DELETE ClickHouse wins every benchmark" https://news.ycombinator.com/threads?id=rkwasny
It's simple as that: if you need deletion, consider TimescaleDB.
For every other conceivable scenario, ClickHouse is likely to come ahead, unless you are doing something very very wrong with it: a virtualization example would be splitting cores across VM with no respect of their shared cache.
When people talk about doing a millions of tiny inserts, it's a bit like that: a misconfiguration. And that's not how it work in the real world: even with plain Postgres, you often use a middle layer to avoid resource issues (increasing max_connections has a cost, that's why pgpool exist!), either directly in your app, or by putting some kind of buffer in front of the real table.
I have spend some serious time with both, think of me what you may, but the CEO of TimescaleDB saying TimescaleDB performance can withstand the comparison with ClickHouse is like Intel marketing department saying Intel CPUs can withstand the comparison with AMD: unless you cook the tests with some highly specific workloads (say with lots of simd/AVX512 stuff, monocore...) to be non representative of the most common scenarios, you're not being honest.
I believe such thinly veiled dishonesty is a much larger problem than a perceived positivity.
This outcome should also be entirely unsurprising and should pass people's basic sniff tests as Timescale works within the existing, mature architecture of PostgreSQL, where-as ClickHouse is a greenfield single-purpose system. Software makes trade-offs.
But since this is a public forum, I'll answer your comment:
In general: ClickHouse is better than TimescaleDB for OLAP. TimescaleDB is better for time-series. If you don't believe me, that's fine! Each workload is different and you should test it yourself.
p.s. Let's keep HackerNews a more positive place. Negative comments are unnecessary, not productive, and honestly just make the author look immature.