Open Letter: Please Consider Making This Library Official

[enomado]

Please consider making this library official and issuing a recommendation against using the client maintained by Lloyd.

This letter intended to raise awareness—not to attack any individual—but to advocate for better developer experience and safer practices in the ecosystem.

The issue is that Lloyd’s library violates a number of well-established conventions and best practices commonly expected by users of database libraries. While it presents itself as an advanced solution that operates on the level of structure serialization (as opposed to combinator-based parsing), the implementation falls significantly short of expectations.

Specifically, many users reasonably interpret "advanced" as meaning a superset or improvement upon traditional parsing, grounded in type safety and clear semantics. Unfortunately, the actual serialization logic in the client disregards fundamental principles, performing unchecked low-level memory tricks rather than sound type conversion.

For example, even something as basic as a COUNT query returns an unknown type result, requiring the user to somehow "guess" that it is u64. If they guess wrong, the result can silently overwrite another field. These kinds of unsafe behaviors—akin to C-style low-level hacks—are entirely inappropriate in a modern SQL driver. (ClickHouse/clickhouse-rs#185)

By contrast, look at other mature drivers, such as the one for MySQL. I’ve had a good experience with this library, where I received clear, safe error messages like FromSql(InvalidType { src: "UInt64", dst: "u32" }), which allowed me to catch issues easily.

Here are some of the public issues highlighting these problems. They are not edge cases—they represent broken core functionality:

ClickHouse/clickhouse-rs#192
ClickHouse/clickhouse-rs#187

In this thread, I attempted to raise these concerns constructively, but my comment was deleted:

ClickHouse/clickhouse-rs#199

The author has been promising to move to RowBinaryWithNamesAndTypes since 2022:
ClickHouse/clickhouse-rs#10

Moreover, the author has acknowledged that these issues will persist—and have been persisting since 2022—until a certain change is implemented. The problem is, that change has yet to happen.
ClickHouse/clickhouse-rs#185 (comment)

And it seems like the author prioritizes performance more than type safety:
ClickHouse/clickhouse-rs#169

He even directly recommends this library here (not directly related, but anyway):
ClickHouse/clickhouse-rs#44 (comment)

because the crate is about typed struct

Ironically, it was never really about typed structures.

My hope is not to stir conflict but to encourage a shift toward a more robust and transparent approach for ClickHouse clients in the Rust ecosystem. An official client, or at least an official endorsement of a well-maintained alternative, would go a long way toward improving confidence in the tooling.

[pravic]

@enomado Sadly your comment was deleted even though it does have a strong point and raises legitimate concerns.

If you want, I can share a backup of that comment.

[enomado]

@pravic, thanks. Perhaps I know why it was deleted. I left a loophole to make it personal. Issue was written out of the emotional reaction to the culture shock. However, this could’ve been resolved with an edit or a reply.

This client isn’t a gem either — somehow, it managed to operate without bind fields(#156). But that’s easier to live with than the other client.

PS: After few weeks living with CH:

Configs in XML: you carefully comment every section, and then you need to test how it behaves without that section. And it turns out XML doesn’t support nested comments.

Starts up by throwing a dozen exceptions about "network unreachable" and S3 issues.

It somehow manages to eat up all the disk space on the server while doing absolutely nothing — yet it’s constantly merging and renaming something non-stop.

Tiered storage filled up S3 with 100k files in the first hour, and naturally, there’s no functionality to clean up the excess files.

[pravic]

It somehow manages to eat up all the disk space on the server while doing absolutely nothing — yet it’s constantly merging and renaming something non-stop.

This can be tuned, actually. Albeit it's off-topic in this issue.