Built on open source
Metrics Book is built on other people’s open-source work, and we want everyone to know whose. Each project below does one job in the stack. Here is what it does, why we chose it, and its licence, read from its own repository on 27 October 2026. If Metrics Book is useful to you, support these projects too.
The data stack
Section titled “The data stack”dlt, by dltHub
Section titled “dlt, by dltHub”What it does: loads your sources into the warehouse, in Python.
Why: it is code first, so an agent can write and change a pipeline like any other code. Its connectors are maintained, and you can write your own source when there is none.
DuckDB, by the DuckDB Foundation and DuckDB Labs
Section titled “DuckDB, by the DuckDB Foundation and DuckDB Labs”What it does: stores and queries the data on the server’s own disk and memory. It is the default warehouse.
Why: it gives one VM the analytical speed of a warehouse, with no service margin and no bill per query. Postgres is tested as the second warehouse from day one, so moving off DuckDB is a setting, not a rewrite.
dbt Core, by dbt Labs
Section titled “dbt Core, by dbt Labs”What it does: turns raw data into the models the metrics read.
Why: it is the most used tool for the job, and agents write it well. We use dbt Core 1.x; the 2.x engine is not used, because its DuckDB support is incomplete and its default binary is not open source.
anfra, by Holistics
Section titled “anfra, by Holistics”What it does: holds the datasets and metrics as code, compiles them to SQL, and runs the reports.
Why: it is a code-first semantic layer with Data Apps on top, so every chart and every agent uses the same definition of a metric. It also serves MCP, so agents can read the models.
anfra’s compiler and query runner ship as binaries built from Holistics’ private repositories, as anfra’s own DEVELOPMENT.md says. Metrics Book reaches anfra through one module, so a replacement would change one place.
sqlglot, by Toby Mao and contributors
Section titled “sqlglot, by Toby Mao and contributors”What it does: reads the SQL behind each dbt model.
Why: it parses SQL in every dialect we support, so lineage reaches from a metric back to the source columns.
The API, sign-in and access
Section titled “The API, sign-in and access”PostgreSQL and pgvector
Section titled “PostgreSQL and pgvector”What they do: Postgres is the app database: people, access, the catalog and the audit log. pgvector adds search by meaning across metrics, terms and reports.
Why: one database holds it all, and search runs as one query, by meaning and by words, with the access filter in the same query.
postgresql.org · PostgreSQL licence · pgvector under the same licence
What it does: the web framework the API and the MCP connector run on.
Why: it is small, built on web standards, and easy to test. Better Auth mounts on it without an adapter, and Holistics’ reference host for anfra uses it too.
Better Auth
Section titled “Better Auth”What it does: sign-in, sessions, API keys, and the OAuth server agents sign in through.
Why: it was the only candidate that covers Claude’s connector sign-in and service accounts inside the API, with no extra container.
Cerbos
Section titled “Cerbos”What it does: decides every data request: which datasets each person may read, and so which metrics they see.
Why: its policies are YAML files in git that an agent can maintain, with tests of their own, and it keeps no state.
This site
Section titled “This site”Astro and Starlight, by the Astro contributors
Section titled “Astro and Starlight, by the Astro contributors”What they do: Astro builds metricsbook.io, and Starlight is these docs.
Why: Astro is built for content sites, and Starlight is the best tool we found for docs.