What's the current status of this crate?

[shuoli84]

Hi all,

thanks for the great work both on "duckdb" and this crate. The rust + duckdb combination solved our data analytic problems pretty well.

I've followed this crate development and noticed there are no active commits in two months, and some pending PRs. Is there anything happened? Is this crate low priority? Any info is welcomed.

Sorry if this is not the right place to discuss this. :)

[fb64]

Any news on this topic ?
I also use DuckDB and rust, and it brings a lot of performance for data analysis, especially to do serverless stuff, and I think this crate is very beneficial!
I'm not an expert of rust but if I could help, I would ...
Thanks again for all this work 👍

[Maxxen]

Hello!

Unfortunately this crate has been pretty neglected, for mostly boring reasons. I don't necessarily want to speak for the others but I think its fair to say that those of us in the DuckDB team who have the most experience writing rust have been busy with other stuff, and the others are not as confident in rust to the point where they could help out reviewing PRs.

That said, we're still interested in supporting rust and will be investing in it more in the future. @samansmink has worked hard on making it easier to integrate duckdb and rust in the form of rust-based extensions, which is (going) to be very much tied to this crate, even if most of the work so far has been going on in the background on the CI/build tools/extension-api/duckdb-c-api side and not reflected in the user-facing side of the crate itself.

However, one of my goals for 2025 is to take more ownership of this crate and spend some regular time with it, both doing small-scale stuff like support for more types or API's, but also try to work on some larger refactor/modularization of this crate to trim down on the amount of dependencies and make maintenance easier. One thing in particular that's been on my mind for a while is to decouple the crate version from the duckdb version so that we could have proper semver-versioning for this crate, and make releases on our own pace. Eventually I'd like to take another pass at the user facing side of the API as well, potentially giving it the same treatment as the duckdb-node-neo client gave the nodejs bindings, where we design it based on what makes sense for DuckDB and not SQLite.

Not making any promises though! First step is to get this building in CI again and updating to DuckDB 1.2.0 (which im working on as we speak!)

[mbp-stripe]

Good to hear! We were writing some code to use this and had some doubt if it would be a stable foundation.

When you get a chance it would be nice to hear if you agree with the intention of #414 to make extensions not need unsafe. Ideally it would merge as is but if you want to take a larger look first I understand.

[Maxxen]

@mbp-stripe sure, I'm going to have a look at all open PR's before we cut the 1.2.0 release as soon as I fix CI!

[fb64]

@Maxxen Thanks for your responses and for sharing your vision.
Glad to read that this crate will be maintained.

[shuoli84]

Good to hear! Thanks and I'll close this~ :)