[willtemperley]

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]

I can't confirm this, I have several instances which have statically linked extensions...

[willtemperley]

I 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 [2] https://github.com/duckdb/duckdb/pull/17464