Live data from Hacker News

ChDB: Embedded OLAP SQL Engine Powered by ClickHouse

github.com

11–20 of 35 posts

Re: ChDB: Embedded OLAP SQL Engine Powered by ClickHouse

#11
post #2

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

Re: ChDB: Embedded OLAP SQL Engine Powered by ClickHouse

#12
post #8

I absolutely love this trend of "pip install x" as a distribution mechanism for this kind of thing. People badmouth Python packaging a lot, but once you've learned how to use a virtual environment (admittedly a steeper learning curve than I'd like it to be) having binary wheels for so much of this kind of stuff is a huge win. See also Playwright, DuckDB, ziglang... I wrote a bit about those here https://simonwillison…

I'm tempted to say that the very same reason why you need different environments is precisely because the package system is not healthy.

And the fact that it's not easy to use doesn't really make things better.

Re: ChDB: Embedded OLAP SQL Engine Powered by ClickHouse

#13
post #2

why would you use this over duckdb?

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.

Re: ChDB: Embedded OLAP SQL Engine Powered by ClickHouse

#14
post #2

why would you use this over 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"

Re: ChDB: Embedded OLAP SQL Engine Powered by ClickHouse

#15
post #8

I absolutely love this trend of "pip install x" as a distribution mechanism for this kind of thing. People badmouth Python packaging a lot, but once you've learned how to use a virtual environment (admittedly a steeper learning curve than I'd like it to be) having binary wheels for so much of this kind of stuff is a huge win. See also Playwright, DuckDB, ziglang... I wrote a bit about those here https://simonwillison…

Yes, agree. Specially with pipx.

Re: ChDB: Embedded OLAP SQL Engine Powered by ClickHouse

#17
post #8

I absolutely love this trend of "pip install x" as a distribution mechanism for this kind of thing. People badmouth Python packaging a lot, but once you've learned how to use a virtual environment (admittedly a steeper learning curve than I'd like it to be) having binary wheels for so much of this kind of stuff is a huge win. See also Playwright, DuckDB, ziglang... I wrote a bit about those here https://simonwillison…

[deleted]

Re: ChDB: Embedded OLAP SQL Engine Powered by ClickHouse

#18
post #12
post #8

I absolutely love this trend of "pip install x" as a distribution mechanism for this kind of thing. People badmouth Python packaging a lot, but once you've learned how to use a virtual environment (admittedly a steeper learning curve than I'd like it to be) having binary wheels for so much of this kind of stuff is a huge win. See also Playwright, DuckDB, ziglang... I wrote a bit about those here https://simonwillison…

I'm tempted to say that the very same reason why you need different environments is precisely because the package system is not healthy. And the fact that it's not easy to use doesn't really make things better.

What packaging systems are there that don't encourage different environments for different projects?

I think Python's biggest weakness on this front is mainly that virtual environments came along too late - if they'd been designed into how pip etc worked from the beginning we would be in much better shape.

Post reply on HN