ClickHouse’s experimental .NET TCP client promises faster reads and far less memory use

ClickHouse has released an experimental native TCP client for .NET, offering a faster route to analytical reads and bulk inserts than its existing HTTP client. Its headline benchmark is striking: reading one million rows allocated 6 MB with the new columnar client, compared with 1.6 GB over HTTP.

ClickHouse Watch analysis

What happened

The client is available in the regular ClickHouse.Driver NuGet package. ClickHouse says it uses the native protocol and column-oriented data format, avoiding conversions between column blocks and rows. Its benchmarks report column-based reads taking less than half the time of HTTP on two tested datasets, with POCO reads taking about two-thirds as long. Inserts were faster in the tested cases too.

There are useful operator features beyond speed: sessions keep temporary tables and settings on one connection, cancellation can reach the server, and callbacks can expose query progress, profile events and server logs. ClickHouse’s announcement and technical guide includes a quick start, examples and migration details.

Why it matters

The memory result could matter as much as the benchmark timings. For one million rows of the tested hits dataset, ClickHouse reports 6 MB of allocations using column reads, against 1.6 GB with HTTP. That may make the new client attractive for memory-sensitive .NET analytics workloads, as well as jobs that move large volumes of data.

This is not a universal upgrade. The client is experimental, requires .NET 8 or later, and does not support ADO.NET, Dapper or Entity Framework Core. Heavy JSON workloads are a poor fit, and the object[] approach loses much of the columnar performance advantage. ClickHouse recommends keeping HTTP for those cases and trying TCP for analytical reads and bulk inserts.

Our read

This looks like a meaningful addition for teams whose .NET applications spend their days shifting analytical data. The best reason to try it is not a tidy “up to” speed claim, but the combination of lower reported allocation and a clear choice: use TCP where its columnar model fits, and keep HTTP where compatibility matters. Experimental means test it on your own workload before rearranging anything important; the migration table and examples should make that first test less of a spelunking expedition.

What to watch

• Whether the client’s API stabilises after its experimental period.
• How the reported memory and speed gains compare on real applications and different data types.
• When binary JSON support arrives, and whether framework and ORM support expands.

Discussion spark: For a .NET analytics workload, would you trial an experimental client for the reported memory savings, or wait for a stable release and broader framework support?

not affiliated with or endorsed by ClickHouse