(TimescaleDB co-founder) 6,000,000 rows inserted per second is great! And if you need that for your workload, then you probably should choose ClickHouse over T

(TimescaleDB co-founder) 6,000,000 rows inserted per second is great! And if you need that for your workload, then you probably should choose ClickHouse over TimescaleDB (well at least, for now ;-) The reason we don't include that in the benchmark is that most developers _don't need_ 6,000,000 rows inserted per second. And also - that performance doesn't come for free, but requires giving up a lot of things that most developers may need: e.g., no transactions, immutable tables (can't easily update / delete data), SQL-like but not quite SQL query language, inefficient joins, inefficient for point queries retrieving single rows by their keys, etc. (We go into much more detail in the blog post.) So it comes down to the fundamental analogy used in the post: Do you need a car (versatility) or a bull dozer (narrow specialization)? If the answer is that you need to support 6,000,000 rows inserted per second, then by all means, choose the bull dozer. > ClickHouse shines at scales that timescale has no hope of ever supporting. I'm not sure if this was a throwaway line, or if it was the result of a detailed analysis of TimescaleDB's architecture, but if you don't mind, I'll share this: with TimescaleDB multi-node [0] we are getting close to that performance, and the product keeps getting better. [0] https://blog.timescale.com/blog/building-a-distributed-time-series-database-on-postgresql/ https://blog.timescale.com/blog/building-a-distributed-time-...