[jascha_eng]

I'd argue we do okay, but of course it's Clickhouses own benchmark it's hard to outperform them there. It's also not apples to apples. Clickhouse has much less transactional guarantees and isn't postgres SQL compatible. The great thing about Timescale is that you only need one DB for all your analytics and transactional needs. Combined with pgvector postgres also handles search quite well.

In a way Timescale is just postgres on steroids. Sure if you really know your use-case well, are fine with giving up some postgres nicenes, are willing to learn a new query language and are fine with using and syncing multiple data stores you'll outperform timescale. But I think it is still really cool to see how close you can get with essentially just a better postgres.

[hodgesrm]

> Clickhouse has much less transactional guarantees ...

Is this relevant? The benchmark is just reads.

[jascha_eng]

Depends on your workload? If you don't care about ACID compliance in your use-case, and query speed is all that is relevant to you probably not.

You might still be better of with Timescale/TigerData if your query pattern uses a lot of joins as we do much better there than Clickhouse does. We have our own benchmark too and perform better than Clickhouse on those kind of queries: https://rtabench.com/

But also transactions often make your life as a dev easier in my experience, and being able to use a single DB and stick with 100% postgres compatible SQL without having to change your application is often worth more than squeezing out the last few bit of query performance.

I'm just saying that single-benchmark comparisons rarely tell the full story when evaluating database technologies. ClickHouse is undoubtedly impressive engineering, and it excels in many scenarios. Ultimately the optimal choice depends on your specific use case.

[hodgesrm]

I'm glad you answered as my comment was not very complete. It left out mentioning that transactions should not be expensive on reads unless you are doing something wrong. In general MVCC--which PostgreSQL uses--does not have a lot of performance overhead for this case. ClickHouse also maintains snapshots when reading, so to a certain extent they do the same work. Transactions don't seem like a very strong argument here, since you would be conceding that your implementation is inefficient.

I agree with the other points. ClickHouse is not strong on joins [yet]. It's also nice to have a single database for everything. Yet so far nobody has been able to achieve one that delivers high concurrency, fast updates, and petabyte-level scaling. Mike Stonebraker et al. called this problem out in 2007. [0] It appears they called it right and we'll continue to see 2-3 major categories of databases for the foreseeable future.

[0] https://www.vldb.org/conf/2007/papers/industrial/p1150-stone...