They are both lightweight, and can be run both embedded and via a CLI (as well as MCP and other ways ;) ), no server to run if you don't want to, no warehouse to provision.
DuckDB can read a file straight off a URL over httpfs; SLayer can auto-ingest a schema during datasource setup, and then turns its simple yet powerful query syntax into the correct SQL.
Put them together and a semantic layer over a remote dataset is a handful of lines.
To show just how simple and powerful that pattern is, example notebooks have been put together, one for CLI, one for Python.
Each notebook shows, from scratch, how to define a view over a remote file in DuckDB, then to connect SLayer to that view, and to execute a deceptively simple query, containing:
A dimension computed from an aggregate, group each month warm or cool by its average high temperature, a CASE WHEN temp_max:avg(partition_by=date) … band used as a grouping dimension
A ranking transform in a measure, rank(precipitation:sum) to order the months by rainfall, one of SLayer's query-time transforms.
Both of these are defined at query time, showing how SLayer removes the need to pre-configure every little thing you want to query.
Why use SLayer at all, instead of direct SQL? The final cell of each notebook shows the SQL corresponding to that "simple" query json. Judge for yourself which one is easier to read, and which one an agent is more likely to generate correctly, time after time.
Top comments (0)