Counting *open* issues as community engagement is nonsense. The total number of issues, open and closed, is 7000 for polars and 5000 duckdb and the difference here can be explained from duckdb offering the GitHub "Discussions" to separate feature requests, questions, and discussions from actual bug reports. (By the way, this agrees with polars' open to closed issue ratio being 5x worse than duckdb's: a lot of their issues aren't really issues and as such can't be addressed/solved easily.)
I think the biggest feature of Polars is that you can switch between lazy frames and eager frames and that we can connect directly to storage on cloud providers. I like DuckDB, but Polars is faster quering files from Data Lakes, may be Polars could add DuckDB integration using SQL on lazyFrames without needing to collect.
Counting *open* issues as community engagement is nonsense. The total number of issues, open and closed, is 7000 for polars and 5000 duckdb and the difference here can be explained from duckdb offering the GitHub "Discussions" to separate feature requests, questions, and discussions from actual bug reports. (By the way, this agrees with polars' open to closed issue ratio being 5x worse than duckdb's: a lot of their issues aren't really issues and as such can't be addressed/solved easily.)
Do you have any thoughts on using ibis+duckdb? That would fix the "tool to simplify" the use?
duckdb literally can zero-cost convert its result set to a polars frame, as its all Arrow memory.
So I think interop is as good as it can get.
I think the biggest feature of Polars is that you can switch between lazy frames and eager frames and that we can connect directly to storage on cloud providers. I like DuckDB, but Polars is faster quering files from Data Lakes, may be Polars could add DuckDB integration using SQL on lazyFrames without needing to collect.