Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

OP made accusations, response was leveled and asked for positivity.


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.

ClickHouse has such features, to automatically handle the flushing to the real table: https://clickhouse.com/docs/en/engines/table-engines/special...

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.


"When people talk about doing a millions of tiny inserts" from CH update it sounds that support for this use case has landed or is about to land


it already does with buffered tables


21.11 has asynchronous inserts (no need for buffered tables or kafka)




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: