Hi. Sure, no problem.

CickHouseConnection uses HttpClient internally and hence generally follows same rules - for example, you can queue multiple requests to HttpClient from different threads, and the will be executed in parallel, but - with default settings - no more than 2 simultaneous requests to same server at the same time. All the 'extra' queries will wait in queue until there is room to execute. See MaxConnectionsPerServer documentation for further info

2 notable exceptions are:

• if sessions are enabled, a specially constructed HttpClient instance is used internally which only allows one parallel query at the time. This is to adhere to ClickHouse mechanics of session_id. However, in that case there would not be a global limit - there would be active HTTP connections up to number of ClickHouseConnection instances
• If custom HttpClient or IHttpClientFactory is passed, then the behavior will depend on the settings of passed object

Other than that, there is no transient state in the connection object - as long as settings are not changed, it can be considered thread-safe

So speaking of best practice patterns, I would say:

• Use default settings (just pass ConnectionString) for generic UI use. Number of connection objects is not limited and there is reasonable 'pooling' with 2 connections by default
• If you need to use sessions, make sure you use a limited number of Connection objects, as there is potentially large number of connections which can be opened
• For advanced use - if you need to tweak parameters heavily - create a custom implementation of IHttpClientFactory - as Connection object will call httpClientFactory.CreateClient to create short-lived HttpClient instances to handle requests
• Passing a 'static' HttpClient instance is also available, just make sure to set Timeout property to desired value as it can't be changed later