Perspective from sentry.io (we use it in production as wikibob pointed out below): Besides all the performance considerations discussed in this thread, which a

Perspective from sentry.io (we use it in production as wikibob pointed out below): Besides all the performance considerations discussed in this thread, which are 100% correct, a few other features we really like are: - the multiple table engines that are heavily optimized for specific data access patterns: ReplacingMergeTrees which essentially make records mutable, SummingMergeTrees that allow us to progressively build pre-aggregated data, AggregateMergeTrees that allow storing the intermediate aggregation state of most aggregation function and compose them at query time over multiple groups (example, store a p95 aggregation state hourly and query the daily p95 by composing them), and more. - column data types is extensive and includes nested columns - the architecture is relatively simple making it easy for developers and on prem users to deploy a single node local clickhouse very easily - it is very efficient in inserting big batches of data which works really well for our use case were we ingest massive amount of errors. - data skipping indexes, bloom filter indexes (yes, as vlad@sentry.io mentioned below we are hiring for the team that manages storage and thus clickhouse)