This table schema: https://github.com/timescale/tsbs/blob/bcc00137d72d889e6059e247fcc343a5bc45991d/pkg/targets/clickhouse/creator.go#L146= https://github.com/ti

This table schema: https://github.com/timescale/tsbs/blob/bcc00137d72d889e6059e247fcc343a5bc45991d/pkg/targets/clickhouse/creator.go#L146= https://github.com/timescale/tsbs/blob/bcc00137d72d889e6059e... ...seems like a quite odd way to store time-series in ClickHouse. If I understood that code correctly (and I am really not sure), they partition their data by some tag value (the first one in a list?), and sort each partition by "tags ID", while timescaledb partitions by time afaik. Of course there will be large discrepancies if data is sorted one way in one database schema, and another way in another schema. It seems that at least their query of "ORDER BY time LIMIT 10" would greatly benefit from partitioning or sorting the table by time. Whether that makes sense depends on your usecase. But I don't think a benchmark with completely dfferent schemas, partitioning and primary keys across databases is fair. Another thing I noticed is that their version of ClickHouse is quite old, at least aroudn the time the test was written. The shown CREATE TABLE syntax is deprecated since a few versions and cannot be found in recent docs, only github: https://github.com/ClickHouse/ClickHouse/blob/v18.16/docs/en/operations/table_engines/mergetree.md https://github.com/ClickHouse/ClickHouse/blob/v18.16/docs/en...