xarray_sql 0.3.2__tar.gz → 0.4.0__tar.gz

xarray_sql-0.4.0/.envrc

@@ -0,0 +1 @@
+use flake

{xarray_sql-0.3.2 → xarray_sql-0.4.0}/.gitignore

@@ -14,3 +14,4 @@ test_data
 CHANGELOG.md
 *.ipynb
 /site
+.direnv

{xarray_sql-0.3.2 → xarray_sql-0.4.0}/Cargo.lock

@@ -3367,7 +3367,7 @@ checksum = "ea2f10b9bb0928dfb1b42b65e1f9e36f7f54dbdf08457afefb38afcdec4fa2bb"
 
 [[package]]
 name = "xarray_sql"
-version = "0.3.2"
+version = "0.4.0"
 dependencies = [
  "arrow",
  "async-stream",
@@ -3375,6 +3375,7 @@ dependencies = [
  "datafusion",
  "datafusion-ffi",
  "futures",
+ "half",
  "pyo3",
  "pyo3-build-config",
  "tokio",

{xarray_sql-0.3.2 → xarray_sql-0.4.0}/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "xarray_sql"
-version = "0.3.2"
+version = "0.4.0"
 authors = ["Alex Merose"]
 edition = "2021"
 exclude = [
@@ -25,11 +25,12 @@ async-trait = "0.1"
 datafusion = { version = "54.0.0" }
 datafusion-ffi = { version = "54.0.0" }
 futures = { version = "0.3" }
+half = "2.7"
 # `abi3-py310` builds against CPython's stable ABI, so a single wheel per
-# platform works on all CPython >= 3.10 (matching `requires-python`). This
-# lets the release workflow ship pre-built wheels for every interpreter
-# without compiling per-version, avoiding local rebuilds on install.
-pyo3 = { version = "0.28.0", features = ["extension-module", "abi3-py310"] }
+# platform works on all CPython >= 3.10 (matching `requires-python`). Maturin
+# enables `pyo3/extension-module` through pyproject.toml for wheel builds; it
+# must stay disabled for ordinary Cargo test binaries so they link libpython.
+pyo3 = { version = "0.28.0", features = ["abi3-py310"] }
 tokio = { version = "1.46.1", features = ["rt"] }
 
 

{xarray_sql-0.3.2 → xarray_sql-0.4.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: xarray_sql
-Version: 0.3.2
+Version: 0.4.0
 Classifier: Development Status :: 4 - Beta
 Classifier: Intended Audience :: Science/Research
 Classifier: Intended Audience :: Developers
@@ -25,15 +25,22 @@ Requires-Dist: pytest ; extra == 'dev'
 Requires-Dist: watchfiles ; extra == 'dev'
 Requires-Dist: zensical ; extra == 'docs'
 Requires-Dist: mkdocstrings[python] ; extra == 'docs'
+Requires-Dist: duckdb>=1.4.0 ; extra == 'duckdb'
+Requires-Dist: pyproj ; extra == 'geo'
+Requires-Dist: polars>=1.33 ; extra == 'polars'
 Requires-Dist: cftime ; extra == 'test'
+Requires-Dist: xarray-sql[duckdb,polars,geo] ; extra == 'test'
 Requires-Dist: pytest ; extra == 'test'
 Requires-Dist: xarray[io] ; extra == 'test'
 Requires-Dist: gcsfs ; extra == 'test'
 Provides-Extra: dev
 Provides-Extra: docs
+Provides-Extra: duckdb
+Provides-Extra: geo
+Provides-Extra: polars
 Provides-Extra: test
 License-File: LICENSE
-Summary: Querry Xarray with SQL.
+Summary: Query Xarray with SQL.
 Author-email: Alexander Merose <al@merose.com>
 License: Apache-2.0
 Requires-Python: >=3.10
@@ -45,10 +52,13 @@ Project-URL: Issues, https://github.com/alxmrs/xarray-sql/issues
 
 _Query [Xarray](https://xarray.dev/) with SQL_
 
-[![ci](https://github.com/alxmrs/xarray-sql/actions/workflows/ci.yml/badge.svg)](https://github.com/alxmrs/xarray-sql/actions/workflows/ci.yml)
-[![lint](https://github.com/alxmrs/xarray-sql/actions/workflows/lint.yml/badge.svg)](https://github.com/alxmrs/xarray-sql/actions/workflows/lint.yml)
-[![ci-build](https://github.com/alxmrs/xarray-sql/actions/workflows/ci-build.yml/badge.svg)](https://github.com/alxmrs/xarray-sql/actions/workflows/ci-build.yml)
-[![ci-rust](https://github.com/alxmrs/xarray-sql/actions/workflows/ci-rust.yml/badge.svg)](https://github.com/alxmrs/xarray-sql/actions/workflows/ci-rust.yml)
+![PyPI Version](https://img.shields.io/pypi/v/xarray-sql?color=green)
+[![ci](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci.yml/badge.svg)](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci.yml)
+[![lint](https://github.com/xqlsystems/xarray-sql/actions/workflows/lint.yml/badge.svg)](https://github.com/xqlsystems/xarray-sql/actions/workflows/lint.yml)
+[![ci-build](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci-build.yml/badge.svg)](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci-build.yml)
+[![ci-rust](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci-rust.yml/badge.svg)](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci-rust.yml)
+[![PyPI Downloads](https://static.pepy.tech/personalized-badge/xarray-sql?period=total&units=INTERNATIONAL_SYSTEM&left_color=BLACK&right_color=GREEN&left_text=downloads)](https://pepy.tech/projects/xarray-sql)
+[![PyPI Downloads](https://static.pepy.tech/personalized-badge/xarray-sql?period=monthly&units=INTERNATIONAL_SYSTEM&left_color=BLACK&right_color=GREEN&left_text=downloads%2Fmonth)](https://pepy.tech/projects/xarray-sql)
 
 ```shell
 pip install xarray-sql
@@ -58,7 +68,11 @@ pip install xarray-sql
 
 This is an experiment to provide a SQL interface for array datasets.
 Succinctly, we "pivot" Xarray Datasets to treat them like tables so we can run
-SQL queries against them.
+SQL queries against them — on the query engine of your choice. xarray-sql
+translates data, not queries: it registers a lazy Dataset as a table on
+DataFusion (built in), DuckDB, or Polars, and turns any engine's Arrow result
+back into a labeled Dataset. Dialects, geometry functions, and optimizers stay
+with the engine.
 
 ## Quickstart
 
@@ -101,6 +115,24 @@ clim_ds["air"].plot()  # in a script, call matplotlib.pyplot.show() to display
 That's the round trip — Xarray in, SQL in the middle, Xarray (and a plot) back
 out.
 
+The same Dataset registers on other engines with one call — DuckDB gets a
+native lazy table with predicate pushdown, Polars scans the same object:
+
+```python
+import duckdb
+
+con = duckdb.connect()
+xql.register(con, 'air', ds, chunks=dict(time=100))
+rel = con.sql('SELECT time, AVG("air") AS air FROM air GROUP BY time ORDER BY time')
+xql.to_dataset(rel, template=ds)   # any engine's Arrow result round-trips
+```
+
+`table_names` (below) works the same way on every engine, so a query written
+against `era5.surface` is not tied to the engine it was written for.
+
+See [Engines](https://xqlsystems.github.io/xarray-sql/latest/engines/) for the support matrix, DuckDB/Polars details,
+and the lazy chunked round-trip.
+
 ## A bigger example: ARCO-ERA5
 
 The same interface scales to cloud-native datasets with hundreds of variables,
@@ -173,6 +205,8 @@ result = ctx.sql('''
 # | 775   | -2.3064649711534457  |
 # +-------+----------------------+
 
+# `latitude`/`longitude` are inferred from the registered table's surviving
+# dims; `template` is kept only to recover metadata (attrs, encoding).
 ctx.sql('''
   SELECT latitude, longitude, AVG("2m_temperature") - 273.15 AS avg_c
   FROM era5.surface
@@ -180,8 +214,6 @@ ctx.sql('''
                  AND TIMESTAMP '2020-01-01 05:00:00'
   GROUP BY latitude, longitude
   ORDER BY latitude DESC, longitude
-# `latitude`/`longitude` are inferred from the registered table's surviving
-# dims; `template` is kept only to recover metadata (attrs, encoding).
 ''').to_dataset(template=ds)
 # <xarray.Dataset> Size: 8MB
 # Dimensions:    (latitude: 721, longitude: 1440)
@@ -198,7 +230,7 @@ ctx.sql('''
 ```
 
 _(A runnable version of this example lives at
-[`perf_tests/era5_temp_profile.py`](perf_tests/era5_temp_profile.py).)_
+[`perf_tests/era5_temp_profile.py`](https://github.com/xqlsystems/xarray-sql/blob/main/perf_tests/era5_temp_profile.py).)_
 
 ## Why build this?
 
@@ -231,6 +263,9 @@ pure DataFusion and PyArrow, but works with the same principle!
 _2026 update_: Instead of `from_map()`, we create a way to translate Xarray chunks
 into Arrow RecordBatches. We pass a Python callback into a DataFusion `TableProvider`
 that lets the DB engine translate the underlying Dataset arrays into DataFusion partitions.
+The same chunks-to-batches translation is also exposed as a
+`pyarrow.dataset.Dataset` with predicate and projection pushdown, which is how
+DuckDB and Polars consume registered Datasets with no engine-specific code.
 Ultimately, the initial insight of the `pivot()` function -- that any ndarray can be
 translated into a 2D table -- underlies this performant query mechanism. 
 
@@ -253,15 +288,17 @@ against an xarray/array reference** to floating-point tolerance:
   reproduces the published result that GraphCast beats Pangu at every lead.
 * **Raster × vector zonal stats** — a range `JOIN` of the ERA5 grid against a
   table of regions.
-* **Reprojection and regridding** — a scalar PROJ UDF (validated against Earth
-  Engine's own geodesy via [Xee](https://github.com/google/Xee)) and a
+* **Reprojection and regridding** — a `reproject(x, y, src_crs, dst_crs)`
+  scalar PROJ UDF, shipped as the optional geo extension
+  (`pip install xarray-sql[geo]`, validated against Earth Engine's own
+  geodesy via [Xee](https://github.com/google/Xee)) and a
   sparse-weight-table `JOIN` (regridding real SRTM terrain).
 
 Every case matches its array reference. The headline finding: these operations
 are not really "array" operations at all — they are `GROUP BY`, `JOIN`, window
 functions, and `CASE` in disguise, and a query engine runs them at scale. See
-[`benchmarks/geospatial/`](benchmarks/geospatial/) and the write-up,
-[Geospatial operations are relational operations](docs/geospatial.md).
+[`benchmarks/geospatial/`](https://github.com/xqlsystems/xarray-sql/tree/main/benchmarks/geospatial/) and the write-up,
+[Geospatial operations are relational operations](https://xqlsystems.github.io/xarray-sql/latest/geospatial/).
 
 ## Why does this work?
 
@@ -269,15 +306,17 @@ Underneath Xarray, Dask, and Pandas, there are NumPy arrays. These are paged in
 chunks and represented contiguously in memory. It is only a matter of metadata
 that breaks them up into ndarrays. `pivot()`, which uses `to_dataframe()`,
 just changes this metadata (via a `ravel()`/`reshape()`), back into a column
-amenable to a DataFrame. We take advantage of this light weight metadata change to
-make chunked information scannable by a DB engine (DataFusion).
+amenable to a DataFrame. We take advantage of this lightweight metadata change to
+make chunked information scannable by a DB engine (DataFusion, DuckDB, Polars —
+anything that speaks Arrow).
 
 ## What are the current limitations?
 
-TBD, DataFusion provides a whole new world! Currently, we're looking for
+The sharp edges we know about — per engine and fundamental — are cataloged in
+[Known issues & limitations](https://xqlsystems.github.io/xarray-sql/latest/limitations/). Currently, we're looking for
 early users – "tire kickers", if you will. We'd love your input to shape the direction of this
-project! Please, give this a try and [file issues](https://github.com/alxmrs/xarray-sql/issues) as
-you see fit. Check out our [contributing guide](CONTRIBUTING.md), too 😉.
+project! Please, give this a try and [file issues](https://github.com/xqlsystems/xarray-sql/issues) as
+you see fit. Check out our [contributing guide](https://xqlsystems.github.io/xarray-sql/latest/contributing/), too 😉.
 
 ## What would a deeper integration look like?
 
@@ -290,7 +329,7 @@ a [virtual](https://fsspec.github.io/kerchunk/)
 filesystem for parquet that would internally map to Zarr. Raster-backed virtual
 parquet would open up integrations to numerous tools like dask, pyarrow, duckdb,
 and BigQuery. More thoughts on this
-in [#4](https://github.com/alxmrs/xarray-sql/issues/4).
+in [#4](https://github.com/xqlsystems/xarray-sql/issues/4).
 
 _2025 update_: Something like this is being built across a few projects! The ones I know about are:
 
@@ -300,18 +339,18 @@ _2025 update_: Something like this is being built across a few projects! The one
 _2026 update_: A colleague and I are experimenting with native Zarr RDBMS engines. Check out:
 
 - [Zarr-Datafusion](https://lib.rs/crates/zarr-datafusion)
-- [DuckDB-Zarr](https://github.com/alxmrs/duckdb-zarr)
+- [DuckDB-Zarr](https://github.com/xqlsystems/duckdb-zarr)
 
 ## Roadmap
 
-- [x] ~Lazy evaluation via the pyarrow Dataset interface [#93](https://github.com/alxmrs/xarray-sql/issues/93).~ _Implemented in [#100](https://github.com/alxmrs/xarray-sql/pull/100)_
-- [x] Support proper parallelism via proper partition handling on the rust/datafusion side. [#106](https://github.com/alxmrs/xarray-sql/issues/106)
-- [x] Support core datafusion optimizations to scan less data, like [104](https://github.com/alxmrs/xarray-sql/issues/104), ...
-- [x] Translate a single Zarr to a collection of tables [#85](https://github.com/alxmrs/xarray-sql/issues/85).
-- [ ] Distributed beyond a single node through the DataFusion integration with Ray Datasets [#68](https://github.com/alxmrs/xarray-sql/issues/68) or Apache Ballista [#98](https://github.com/alxmrs/xarray-sql/issues/98).
-- [ ] Demo: calculate Sea Surface Temperature from 1940 - Present in SQL [#36](https://github.com/alxmrs/xarray-sql/issues/36).
-- [ ] Provide an option to integrate DataFusion directly to Zarr via Rust [#4](https://github.com/alxmrs/xarray-sql/issues/4).
-- [ ] (To be formally announced eventually): The 100 Trillion Row Challenge [#34](https://github.com/alxmrs/xarray-sql/issues/34).
+- [x] ~Lazy evaluation via the pyarrow Dataset interface [#93](https://github.com/xqlsystems/xarray-sql/issues/93).~ _Implemented in [#100](https://github.com/xqlsystems/xarray-sql/pull/100)_
+- [x] Support proper parallelism via proper partition handling on the rust/datafusion side. [#106](https://github.com/xqlsystems/xarray-sql/issues/106)
+- [x] Support core datafusion optimizations to scan less data, like [#104](https://github.com/xqlsystems/xarray-sql/issues/104), ...
+- [x] Translate a single Zarr to a collection of tables [#85](https://github.com/xqlsystems/xarray-sql/issues/85).
+- [ ] Distributed beyond a single node through the DataFusion integration with Ray Datasets [#68](https://github.com/xqlsystems/xarray-sql/issues/68) or Apache Ballista [#98](https://github.com/xqlsystems/xarray-sql/issues/98).
+- [ ] Demo: calculate Sea Surface Temperature from 1940 - Present in SQL [#36](https://github.com/xqlsystems/xarray-sql/issues/36).
+- [ ] Provide an option to integrate DataFusion directly to Zarr via Rust [#4](https://github.com/xqlsystems/xarray-sql/issues/4).
+- [ ] (To be formally announced eventually): The 100 Trillion Row Challenge [#34](https://github.com/xqlsystems/xarray-sql/issues/34).
 
 ## Sponsors & Contributors
 
@@ -331,6 +370,9 @@ I want to give a special thanks to the following folks and institutions:
   changes.
 - Aman Kumar for spending a considerable amount of his GSoC internship 
   contributing to this project. 
+- Miguel Moncada Isla for reimagining this project to be a cross SQL engine 
+  interface to and from Xarray. He brought new life to this experiment, in my 
+  opinion.
 
 
 ## License

{xarray_sql-0.3.2 → xarray_sql-0.4.0}/README.md

@@ -2,10 +2,13 @@
 
 _Query [Xarray](https://xarray.dev/) with SQL_
 
-[![ci](https://github.com/alxmrs/xarray-sql/actions/workflows/ci.yml/badge.svg)](https://github.com/alxmrs/xarray-sql/actions/workflows/ci.yml)
-[![lint](https://github.com/alxmrs/xarray-sql/actions/workflows/lint.yml/badge.svg)](https://github.com/alxmrs/xarray-sql/actions/workflows/lint.yml)
-[![ci-build](https://github.com/alxmrs/xarray-sql/actions/workflows/ci-build.yml/badge.svg)](https://github.com/alxmrs/xarray-sql/actions/workflows/ci-build.yml)
-[![ci-rust](https://github.com/alxmrs/xarray-sql/actions/workflows/ci-rust.yml/badge.svg)](https://github.com/alxmrs/xarray-sql/actions/workflows/ci-rust.yml)
+![PyPI Version](https://img.shields.io/pypi/v/xarray-sql?color=green)
+[![ci](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci.yml/badge.svg)](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci.yml)
+[![lint](https://github.com/xqlsystems/xarray-sql/actions/workflows/lint.yml/badge.svg)](https://github.com/xqlsystems/xarray-sql/actions/workflows/lint.yml)
+[![ci-build](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci-build.yml/badge.svg)](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci-build.yml)
+[![ci-rust](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci-rust.yml/badge.svg)](https://github.com/xqlsystems/xarray-sql/actions/workflows/ci-rust.yml)
+[![PyPI Downloads](https://static.pepy.tech/personalized-badge/xarray-sql?period=total&units=INTERNATIONAL_SYSTEM&left_color=BLACK&right_color=GREEN&left_text=downloads)](https://pepy.tech/projects/xarray-sql)
+[![PyPI Downloads](https://static.pepy.tech/personalized-badge/xarray-sql?period=monthly&units=INTERNATIONAL_SYSTEM&left_color=BLACK&right_color=GREEN&left_text=downloads%2Fmonth)](https://pepy.tech/projects/xarray-sql)
 
 ```shell
 pip install xarray-sql
@@ -15,7 +18,11 @@ pip install xarray-sql
 
 This is an experiment to provide a SQL interface for array datasets.
 Succinctly, we "pivot" Xarray Datasets to treat them like tables so we can run
-SQL queries against them.
+SQL queries against them — on the query engine of your choice. xarray-sql
+translates data, not queries: it registers a lazy Dataset as a table on
+DataFusion (built in), DuckDB, or Polars, and turns any engine's Arrow result
+back into a labeled Dataset. Dialects, geometry functions, and optimizers stay
+with the engine.
 
 ## Quickstart
 
@@ -58,6 +65,24 @@ clim_ds["air"].plot()  # in a script, call matplotlib.pyplot.show() to display
 That's the round trip — Xarray in, SQL in the middle, Xarray (and a plot) back
 out.
 
+The same Dataset registers on other engines with one call — DuckDB gets a
+native lazy table with predicate pushdown, Polars scans the same object:
+
+```python
+import duckdb
+
+con = duckdb.connect()
+xql.register(con, 'air', ds, chunks=dict(time=100))
+rel = con.sql('SELECT time, AVG("air") AS air FROM air GROUP BY time ORDER BY time')
+xql.to_dataset(rel, template=ds)   # any engine's Arrow result round-trips
+```
+
+`table_names` (below) works the same way on every engine, so a query written
+against `era5.surface` is not tied to the engine it was written for.
+
+See [Engines](https://xqlsystems.github.io/xarray-sql/latest/engines/) for the support matrix, DuckDB/Polars details,
+and the lazy chunked round-trip.
+
 ## A bigger example: ARCO-ERA5
 
 The same interface scales to cloud-native datasets with hundreds of variables,
@@ -130,6 +155,8 @@ result = ctx.sql('''
 # | 775   | -2.3064649711534457  |
 # +-------+----------------------+
 
+# `latitude`/`longitude` are inferred from the registered table's surviving
+# dims; `template` is kept only to recover metadata (attrs, encoding).
 ctx.sql('''
   SELECT latitude, longitude, AVG("2m_temperature") - 273.15 AS avg_c
   FROM era5.surface
@@ -137,8 +164,6 @@ ctx.sql('''
                  AND TIMESTAMP '2020-01-01 05:00:00'
   GROUP BY latitude, longitude
   ORDER BY latitude DESC, longitude
-# `latitude`/`longitude` are inferred from the registered table's surviving
-# dims; `template` is kept only to recover metadata (attrs, encoding).
 ''').to_dataset(template=ds)
 # <xarray.Dataset> Size: 8MB
 # Dimensions:    (latitude: 721, longitude: 1440)
@@ -155,7 +180,7 @@ ctx.sql('''
 ```
 
 _(A runnable version of this example lives at
-[`perf_tests/era5_temp_profile.py`](perf_tests/era5_temp_profile.py).)_
+[`perf_tests/era5_temp_profile.py`](https://github.com/xqlsystems/xarray-sql/blob/main/perf_tests/era5_temp_profile.py).)_
 
 ## Why build this?
 
@@ -188,6 +213,9 @@ pure DataFusion and PyArrow, but works with the same principle!
 _2026 update_: Instead of `from_map()`, we create a way to translate Xarray chunks
 into Arrow RecordBatches. We pass a Python callback into a DataFusion `TableProvider`
 that lets the DB engine translate the underlying Dataset arrays into DataFusion partitions.
+The same chunks-to-batches translation is also exposed as a
+`pyarrow.dataset.Dataset` with predicate and projection pushdown, which is how
+DuckDB and Polars consume registered Datasets with no engine-specific code.
 Ultimately, the initial insight of the `pivot()` function -- that any ndarray can be
 translated into a 2D table -- underlies this performant query mechanism. 
 
@@ -210,15 +238,17 @@ against an xarray/array reference** to floating-point tolerance:
   reproduces the published result that GraphCast beats Pangu at every lead.
 * **Raster × vector zonal stats** — a range `JOIN` of the ERA5 grid against a
   table of regions.
-* **Reprojection and regridding** — a scalar PROJ UDF (validated against Earth
-  Engine's own geodesy via [Xee](https://github.com/google/Xee)) and a
+* **Reprojection and regridding** — a `reproject(x, y, src_crs, dst_crs)`
+  scalar PROJ UDF, shipped as the optional geo extension
+  (`pip install xarray-sql[geo]`, validated against Earth Engine's own
+  geodesy via [Xee](https://github.com/google/Xee)) and a
   sparse-weight-table `JOIN` (regridding real SRTM terrain).
 
 Every case matches its array reference. The headline finding: these operations
 are not really "array" operations at all — they are `GROUP BY`, `JOIN`, window
 functions, and `CASE` in disguise, and a query engine runs them at scale. See
-[`benchmarks/geospatial/`](benchmarks/geospatial/) and the write-up,
-[Geospatial operations are relational operations](docs/geospatial.md).
+[`benchmarks/geospatial/`](https://github.com/xqlsystems/xarray-sql/tree/main/benchmarks/geospatial/) and the write-up,
+[Geospatial operations are relational operations](https://xqlsystems.github.io/xarray-sql/latest/geospatial/).
 
 ## Why does this work?
 
@@ -226,15 +256,17 @@ Underneath Xarray, Dask, and Pandas, there are NumPy arrays. These are paged in
 chunks and represented contiguously in memory. It is only a matter of metadata
 that breaks them up into ndarrays. `pivot()`, which uses `to_dataframe()`,
 just changes this metadata (via a `ravel()`/`reshape()`), back into a column
-amenable to a DataFrame. We take advantage of this light weight metadata change to
-make chunked information scannable by a DB engine (DataFusion).
+amenable to a DataFrame. We take advantage of this lightweight metadata change to
+make chunked information scannable by a DB engine (DataFusion, DuckDB, Polars —
+anything that speaks Arrow).
 
 ## What are the current limitations?
 
-TBD, DataFusion provides a whole new world! Currently, we're looking for
+The sharp edges we know about — per engine and fundamental — are cataloged in
+[Known issues & limitations](https://xqlsystems.github.io/xarray-sql/latest/limitations/). Currently, we're looking for
 early users – "tire kickers", if you will. We'd love your input to shape the direction of this
-project! Please, give this a try and [file issues](https://github.com/alxmrs/xarray-sql/issues) as
-you see fit. Check out our [contributing guide](CONTRIBUTING.md), too 😉.
+project! Please, give this a try and [file issues](https://github.com/xqlsystems/xarray-sql/issues) as
+you see fit. Check out our [contributing guide](https://xqlsystems.github.io/xarray-sql/latest/contributing/), too 😉.
 
 ## What would a deeper integration look like?
 
@@ -247,7 +279,7 @@ a [virtual](https://fsspec.github.io/kerchunk/)
 filesystem for parquet that would internally map to Zarr. Raster-backed virtual
 parquet would open up integrations to numerous tools like dask, pyarrow, duckdb,
 and BigQuery. More thoughts on this
-in [#4](https://github.com/alxmrs/xarray-sql/issues/4).
+in [#4](https://github.com/xqlsystems/xarray-sql/issues/4).
 
 _2025 update_: Something like this is being built across a few projects! The ones I know about are:
 
@@ -257,18 +289,18 @@ _2025 update_: Something like this is being built across a few projects! The one
 _2026 update_: A colleague and I are experimenting with native Zarr RDBMS engines. Check out:
 
 - [Zarr-Datafusion](https://lib.rs/crates/zarr-datafusion)
-- [DuckDB-Zarr](https://github.com/alxmrs/duckdb-zarr)
+- [DuckDB-Zarr](https://github.com/xqlsystems/duckdb-zarr)
 
 ## Roadmap
 
-- [x] ~Lazy evaluation via the pyarrow Dataset interface [#93](https://github.com/alxmrs/xarray-sql/issues/93).~ _Implemented in [#100](https://github.com/alxmrs/xarray-sql/pull/100)_
-- [x] Support proper parallelism via proper partition handling on the rust/datafusion side. [#106](https://github.com/alxmrs/xarray-sql/issues/106)
-- [x] Support core datafusion optimizations to scan less data, like [104](https://github.com/alxmrs/xarray-sql/issues/104), ...
-- [x] Translate a single Zarr to a collection of tables [#85](https://github.com/alxmrs/xarray-sql/issues/85).
-- [ ] Distributed beyond a single node through the DataFusion integration with Ray Datasets [#68](https://github.com/alxmrs/xarray-sql/issues/68) or Apache Ballista [#98](https://github.com/alxmrs/xarray-sql/issues/98).
-- [ ] Demo: calculate Sea Surface Temperature from 1940 - Present in SQL [#36](https://github.com/alxmrs/xarray-sql/issues/36).
-- [ ] Provide an option to integrate DataFusion directly to Zarr via Rust [#4](https://github.com/alxmrs/xarray-sql/issues/4).
-- [ ] (To be formally announced eventually): The 100 Trillion Row Challenge [#34](https://github.com/alxmrs/xarray-sql/issues/34).
+- [x] ~Lazy evaluation via the pyarrow Dataset interface [#93](https://github.com/xqlsystems/xarray-sql/issues/93).~ _Implemented in [#100](https://github.com/xqlsystems/xarray-sql/pull/100)_
+- [x] Support proper parallelism via proper partition handling on the rust/datafusion side. [#106](https://github.com/xqlsystems/xarray-sql/issues/106)
+- [x] Support core datafusion optimizations to scan less data, like [#104](https://github.com/xqlsystems/xarray-sql/issues/104), ...
+- [x] Translate a single Zarr to a collection of tables [#85](https://github.com/xqlsystems/xarray-sql/issues/85).
+- [ ] Distributed beyond a single node through the DataFusion integration with Ray Datasets [#68](https://github.com/xqlsystems/xarray-sql/issues/68) or Apache Ballista [#98](https://github.com/xqlsystems/xarray-sql/issues/98).
+- [ ] Demo: calculate Sea Surface Temperature from 1940 - Present in SQL [#36](https://github.com/xqlsystems/xarray-sql/issues/36).
+- [ ] Provide an option to integrate DataFusion directly to Zarr via Rust [#4](https://github.com/xqlsystems/xarray-sql/issues/4).
+- [ ] (To be formally announced eventually): The 100 Trillion Row Challenge [#34](https://github.com/xqlsystems/xarray-sql/issues/34).
 
 ## Sponsors & Contributors
 
@@ -288,6 +320,9 @@ I want to give a special thanks to the following folks and institutions:
   changes.
 - Aman Kumar for spending a considerable amount of his GSoC internship 
   contributing to this project. 
+- Miguel Moncada Isla for reimagining this project to be a cross SQL engine 
+  interface to and from Xarray. He brought new life to this experiment, in my 
+  opinion.
 
 
 ## License

xarray_sql-0.4.0/benchmarks/duckdb_pushdown.py

@@ -0,0 +1,103 @@
+"""Benchmark: DuckDB re-scannable stream vs pushdown dataset vs ceiling.
+
+Times the three ways DuckDB can consume the same 10M-row synthetic
+dataset — the re-scannable stream (no pushdown), the default
+``register()`` pushdown dataset, and an in-memory ``pyarrow.dataset``
+as the ceiling — and asserts at the end that all three returned the
+same answers. Cross-engine comparisons live in
+``benchmarks/geospatial/``; this measures the adapter paths within one
+engine.
+
+Usage: python benchmarks/duckdb_pushdown.py  (needs duckdb installed)
+"""
+
+import math
+import statistics
+import time
+
+import duckdb
+import numpy as np
+import pandas as pd
+import pyarrow.dataset as pads
+import xarray as xr
+
+import xarray_sql as xql
+from xarray_sql.backends.duckdb import XarrayArrowStream
+
+np.random.seed(0)
+N_TIME, N_LAT, N_LON = 1000, 100, 100  # 10M rows
+ds = xr.Dataset(
+    {
+        "temperature": (
+            ["time", "lat", "lon"],
+            np.random.rand(N_TIME, N_LAT, N_LON),
+        ),
+        "humidity": (
+            ["time", "lat", "lon"],
+            np.random.rand(N_TIME, N_LAT, N_LON),
+        ),
+    },
+    coords={
+        "time": pd.date_range("2020-01-01", periods=N_TIME, freq="h"),
+        "lat": np.linspace(-90, 90, N_LAT),
+        "lon": np.linspace(-180, 180, N_LON),
+    },
+).chunk({"time": 50})  # 20 partitions
+
+con = duckdb.connect()
+
+QUERIES = {
+    "full AVG scan": "SELECT AVG(temperature) FROM {t}",
+    "1pct time filter": (
+        "SELECT AVG(temperature) FROM {t} WHERE time < '2020-01-01 10:00:00'"
+    ),
+    "bbox filter": (
+        "SELECT AVG(temperature) FROM {t} "
+        "WHERE lat BETWEEN 0 AND 10 AND lon BETWEEN 0 AND 20"
+    ),
+    "projection (1 of 2 vars)": "SELECT AVG(humidity) FROM {t}",
+    "count only": "SELECT COUNT(*) FROM {t}",
+}
+
+
+def bench(table, label, n=5):
+    """Times each query; returns {query: answer} for equivalence checks."""
+    print(f"\n== {label} ==")
+    answers = {}
+    for qname, q in QUERIES.items():
+        sql = q.format(t=table)
+        times = []
+        for _ in range(n):
+            t0 = time.perf_counter()
+            r = con.sql(sql).fetchall()
+            times.append(time.perf_counter() - t0)
+        answers[qname] = r[0][0]
+        med = statistics.median(times)
+        print(
+            f"  {qname:28s} {med:8.3f}s "
+            f"(min {min(times):.3f} / max {max(times):.3f})   -> {r[0][0]:.6g}"
+        )
+    return answers
+
+
+# re-scannable stream, registered via the stream wrapper explicitly:
+# DuckDB scans every row, no filter/projection pushdown
+con.register("t_stream", XarrayArrowStream(ds))
+stream = bench("t_stream", "stream (no pushdown)")
+
+# default register(): the pushdown pyarrow-dataset path
+xql.register(con, "t_pushdown", ds)
+pushdown = bench("t_pushdown", "register() [pushdown]")
+
+# ceiling: materialized pa.Table via pyarrow.dataset
+table = xql.read_xarray(ds).read_all()
+con.register("t_ceiling", pads.dataset(table))
+ceiling = bench("t_ceiling", "ceiling: in-memory pyarrow.dataset")
+
+# The timings are only meaningful if every path computed the same thing.
+for qname in QUERIES:
+    a, b, c = stream[qname], pushdown[qname], ceiling[qname]
+    assert math.isclose(a, b, rel_tol=1e-9) and math.isclose(
+        a, c, rel_tol=1e-9
+    ), f"{qname}: paths disagree — stream={a} pushdown={b} ceiling={c}"
+print("\nall paths agree")

{xarray_sql-0.3.2 → xarray_sql-0.4.0}/benchmarks/geospatial/01_ndvi.py

@@ -45,8 +45,7 @@ from __future__ import annotations
 
 import xarray as xr
 
-import xarray_sql as xql
-
+from _engines import EngineContext
 from _harness import (
     CaseSkipped,
     assert_grid_close,
@@ -111,7 +110,8 @@ def main() -> None:
         f"  scene window: {dict(scene.sizes)}  ({n:,} pixels, B04=red/B08=NIR)"
     )
 
-    ctx = xql.XarrayContext()
+    ctx = EngineContext()
+    print(f"  engine: {ctx.flavor}")
     ctx.from_dataset("scene", scene, chunks={"y": 256, "x": 256})
 
     sql = """
@@ -122,7 +122,7 @@ def main() -> None:
     show_sql(sql)
 
     for _ in measured("SQL NDVI"):
-        got = ctx.sql(sql).to_dataset(dims=["y", "x"]).ndvi
+        got = ctx.sql_to_dataset(sql, dims=["y", "x"]).ndvi
 
     # Array reference: the same formula in pure xarray. ``.compute()`` reads the
     # window and evaluates it here (the scene is lazy), so this measures the same

{xarray_sql-0.3.2 → xarray_sql-0.4.0}/benchmarks/geospatial/02_climatology.py

@@ -42,8 +42,7 @@ import datetime
 
 import xarray as xr
 
-import xarray_sql as xql
-
+from _engines import EngineContext
 from _harness import (
     CaseSkipped,
     assert_grid_close,
@@ -81,7 +80,8 @@ def main() -> None:
     except Exception as exc:  # noqa: BLE001 — any failure → skip, not crash
         raise CaseSkipped(f"ARCO-ERA5 unavailable ({exc})") from exc
 
-    ctx = xql.XarrayContext()
+    ctx = EngineContext()
+    print(f"  engine: {ctx.flavor}")
     with timed("register full ERA5 (lazy)"):
         ctx.from_dataset(
             "era5",
@@ -110,8 +110,10 @@ def main() -> None:
     # A climatology is a gridded product: round-trip the result back to an
     # xarray Dataset keyed by (latitude, longitude, hour) — how it is used.
     for _ in measured("SQL diurnal climatology (lazy read)"):
-        got = ctx.sql(sql, param_values=_PARAMS).to_dataset(
-            dims=["latitude", "longitude", "hour"]
+        got = ctx.sql_to_dataset(
+            sql,
+            dims=["latitude", "longitude", "hour"],
+            param_values=_PARAMS,
         )
 
     # Array reference: the textbook groupby-over-the-cycle reduction, in °C —