4 ms·
The one huge caveat for anyone that cannot use dynamic linking e.g. in an AppStore context, DuckDB isn’t a great choice. It’s very hard to statically link exten
by willtemperley 4mo ago
The one huge caveat for anyone that cannot use dynamic linking e.g. in an AppStore context, DuckDB isn’t a great choice. It’s very hard to statically link extensions.
This is where Arrow wins I think. Arrow CPP for example has very portable builds and the C interface is very usable for building bindings.
DuckDB is excellent, but it’s more a black box than a library.
Edit: after a conversation with a robot, it would seem that the DuckDB and ArrowCPP C APIs are complimentary, so it's very possible to have Arrow CPP and DuckDB to coexist in an app, each with its own strength. Arrow CPP doen't have a simple SQL story for example.
- tobilg 4mo agoI can't confirm this, I have several instances which have statically linked extensions...
- willtemperley 4mo agoI didn't say it was impossible but there are specific situations in which it's very difficult. What I was unable to resolve was getting DuckDB to statically link with httpfs and I'm not the only one [1]. So being more specific, I don't know how I could get a static build of DuckDB to work with Parquet and httpfs (i.e. query S3) working in an app store environment. It was a day's work to get Arrow CPP to call back into Swift for the transport layer. However I do now see that DuckDB recently provided an extension point for providing your own transport layer, so my point might well be moot for that reason [2]. [1] https://github.com/duckdb/duckdb/issues/16190 https://github.com/duckdb/duckdb/issues/16190 [2] https://github.com/duckdb/duckdb/pull/17464 https://github.com/duckdb/duckdb/pull/17464