Hacker News Reader

Comment by adulion | Hacker News Reader

why would you use this over duckdb?

Here is an example, DB Pilot recently switched from duckdb to ChDB, mostly for faster queries and broader data formats support: https://dbpilot.io/changelog#embedded-clickhouse-and-standal...

Disclaimer: I work at ClickHouse

I don't have an opinion, but this article gives a fairly unbiased comparison of DuckDB vs Clickhouse-local, which I imagine exhibits similar performance characteristics as ChDB, just without the embedded part: https://www.vantage.sh/blog/clickhouse-local-vs-duckdb

Disclaimer: I am a chdb maintainer! duckdb is currently thinner and has lots of active contributors and mature integrations, while chdb is still in its early stages BUT if you already love ClickHouse (like we do) chdb is a great choice as it inherits all the ClickHouse stability, performance and more importantly, all the 70+ supported formats for the embedded use case without any of the server/client requirements, making it perfect for fast in-process and serverless OLAP executions.

Note chdb is based on ClickHouse codebase but completely community powered so there's no feud with DuckDB (I'm a quackhead, too!) which actually offers lots of great inspiration and many integration opportunities with ClickHouse/chdb for combined compute and processing of datasets. I personally love both and use them together all the time in my colab "OLAPps"

does chdb have support for recursive CTES?

It and the ability to do `from 'https://example.com/.csv` is why i love duckdb

ClickHouse 10 years before DuckDB existed:

SELECT * FROM url('https://example.com/*.csv')

not as simple as from 'a.csv' and 10 years without recursive CTES?

Where can I find an SVG version of this logo? https://github.com/chdb-io/chdb/raw/main/docs/_static/snake-...

Here you go: https://github.com/chdb-io/chdb/blob/92024bde839a8e9a42f68ae...

One reason would be if you're already fluent in ClickHouse's SQL dialect. Although they maintain great standard SQL compatibility, they also have a great deal of special functions/aggregates/etc that are ClickHouse specific.

Other reasons include their wide range of input formats, special table functions (e.g. query a URL).

I think it makes sense if you are just considering whether or not to use ClickHouse, it's a very easy place to start. If you then outgrow embedded you won't have to move to another database afterwards, you can probably just attach the tables to a "real" ClickHouse instance and continue using it without having to do lengthy data migration.

I suppose if you had data in a format that DuckDb doesn't work with, like Protobuf, Avro, ORC, Arrow, etc. ClickHouse reads and writes data in over 70 formats

One reason is that it supports a wide range of formats.

Reply on news.ycombinator.com