前書いた記事が思ったより多くの人に読まれたようなので、現状 DuckDB と比べてどんな感じなの？、というところを軽く補足しておきます。
結論
「DuckDB から乗り換えた方がいいの？？」という人にまず結論から言うと、DuckDB を使いましょう。SedonaDB は期待の新星ですが、DuckDB spatial の機能の豊富さにはまだまだかないません。
ということを踏まえたうえで、いくつかのポイントについて比較してみます。
提供されている ST_* 関数
SedonaDB に実装予定の関数とその実装状況の一覧は以下の issue で見れます。これを見るとわかるように、まだできることはかなり少ないです。ちょっとしたタスクに使ってみると「え、この関数もないの...」という壁にすぐにぶち当たることでしょう。
また、SedonaDB は基本的に Sedona と対になるプロダクトなので、おそらく Sedona に実装されていない関数は SedonaDB にも実装されません（少なくとも、優先度は下がるはず）。たとえば、DuckDB-spatial には ST_AsMVT() が入りましたが、これを SedonaDB にも入れようと思うと、Java（Sedona）でも Rust（SedonaDB）でも実装する必要があってちょっとハードルが高そうです。
一方で、SedonaDB の良いところとしては、関数がちゃんとテストされています。私も関数をひとつ実装してみて知ったのですが、ユニットテストだけでなく、
- PostGIS と同じ結果になるか
- PostGIS、DuckDB と比べてパフォーマンスはどうか
というテストがしっかり入っています。ここは DuckDB-spatial と比べてかなりちゃんとしているポイントだと思います。
CLI
SedonaDB は、基本的に Python（もしくは R）からの利用を想定しているようです。CLI も一応あるんですけど、ドキュメントには特に記載がないので、（少なくとも現状は）あまり力を入れてなさそうです。
SedonaDB の README には
📁 Format Flexibility: Supports legacy and modern file formats including GeoParquet, Shapefile, GeoJSON
と、様々なフォーマットのデータが扱えることが謳われているのですが、現状、GeoParquet 以外のデータを読むのは Python や R に頼っているようです。つまり、
- Parquet/GeoParquet は SedonaDB で直接読む
- それ以外のフォーマットは Python（GeoPandas）や R（sf）で読んだものも変換する
という作戦でやってるようです。ということは、たぶん CLI では GeoParquet を読むこと以外は特に面白いことはできないんだと思います。CLI での利用をメインに考えている場合は、やはり DuckDB の方がいいでしょう。
（いずれは Python や R からの変換に頼らず SedonaDB が直接そうしたデータを読み書きできるようにするつもりのような気もするんですが、よくわかりません）
CRS
さて、ここまで SedonaDB が負けている点ばかりでしたが、CRS の扱いについては SedonaDB が勝っています。
DuckDB はデータソースの CRS 情報を扱うことができず、ST_Transform() みたいな関数には自分で CRS を指定する必要があります。使ったことある方は分かると思いますが、ここは DuckDB の苦しいところですよね。
一方、SedonaDB はちゃんと CRS を認識するので、そんな面倒なことはしなくても大丈夫です。
技術的なことは理解できてないんですが、DuckDB が CRS を扱えないのは、カラムのメタデータの持ち方が難しいからみたいです。この点、あくまで GIS は拡張機能のひとつに過ぎない DuckDB と違って、SedonaDB は GIS 用に設計されているので、うまく CRS を扱える内部設計になってるんだろうと思います。あるいは、単純に Apache DataFusion がすごいのか。
Wasm
DuckDB は Wasm でウェブブラウザ上でも動くことが強みの一つですが、SedonaDB は現状、Wasm ではビルドできません。issue はあるので、将来的にはできるようになるのかもです。
まとめ
今後に期待！
Discussion