I cocked an eyebrow more than once reading this.

> A quick note about HTTP: ClickHouse® offers a TCP connector with a native protocol, but we don't use it. It does not offer many advantages for the type of application we build

This needs more elaboration. One of the major goals of running a ClickHouse cluster is to provide low-latency queries; a persistent TCP connection removes the need to re-establish a new connection for each query and thus reduces overall latency in line with CH goals. So I really didn't understand this.

> ClickHouse® open source faces a significant challenge: limited support for cloud storage. Modern OLAP databases and data systems should leverage cloud storage for cost efficiency and independent scaling of compute and storage resources. Snowflake established this standard over a decade ago, and ClickHouse® (open source) lags behind

ClickHouse writing to NVMEs is exactly how they provide their latency and performance advtanges. Writing and reading to object buckets is fundamentally slower with multiple network hops to reach what is, in this architectural context, a storage server for your storage server. If you really need far more storage, and are willing to sacrifice query latency to get it... why not architect for one of the OLAP databases, like Snowflake, where that was part of their architecture from day one?

> Because you are testing your analytics queries, right?

No? Half the point of an OLAP database is to let users write their own queries. If we knew the queries ahead of time, we probably wouldn't need an OLAP database, and instead use a less-flexible streaming architecture storing intermediate calculations so as not to need to pay for petabyte-scale storage. The expected value from paying for all of that storage is to support not knowing which queries will be written by users.

> Every single company handling ClickHouse® struggles with ingestion... Backpressure mechanism: Some people put Kafka before ClickHouse®. This does the job

The whole trade-off that you make with column-store databases like ClickHouse (instead of row-store databases like Postgres) is that inserts are slow for column stores (whereas they are fast for row stores). Inserts happen slowly, asynchronously, in the background. It is the price you pay for fast analytics queries. This is why OLAP databases have a latency lag and do not show real-time results. This is why stores like Kafka are usually a good fit, you let Kafka hold onto new data until batch insertions can catch up. If you do need real-time queries, you don't write to an OLAP directly; you write to a stateful frontend that answers the query itself, then streams out historical data from the OLAP that was successfully written there. And the first thing you do in a "I want to have my cake, and eat it too, and yes I'm willing to pay for the privilege" architecture like that is... to keep the persistent TCP connections, because that's really low-hanging fruit.