Cut your BI costs. Let your agent do the analysis.

Cloud BI is easy but expensive. Open source is cheap but hard to run.

No surprise bill at the end of the month

A cloud warehouse bills every question, so one stuck agent lands on next month's invoice. Your server is sized for your busiest hour, and its price is fixed. Set your own data and questions below.

See how the costs were worked out

What goes wrong when an agent runs your BI

1. It reads the wrong number

   Net sales means something different in every dashboard. The agent can't tell which is right.

   Here: each metric is one file that says what it counts, what it is not, and its caveats. The agent reads it before it asks.

   Net salesRevenueSalestotal_net_sales_excl_vat

2. It sees what you can't

   With a shared warehouse key, an agent can read every table, whoever is asking.

   Here: every request runs as the person asking. Cerbos decides it, and the audit log keeps it.

   shared key: every tableyou: your datasets

3. It changes last quarter's numbers

   An agent with write access edits a metric, and a month you closed moves.

   Here: definitions change only in git, through a pull request a person reviews. A closed month moves only when the pull request says it will.

   agent: edit in productiongit: pull request, reviewed

Your agent does the analysis, from numbers you trust

Ask in plain words and get an answer you can act on. "Net sales" means one thing in every chat.

metric total_net_sales_excl_vat {
  label: 'Total net sales excl VAT'
  description: '''
    What customers paid for the items they
    bought, after discounts and less refunds.

    Not the same as: Total gross sales excl
    VAT, which is at list price.
    Caveats: refunds keep arriving for weeks,
    so the latest weeks read high.
  '''
}

How a metric is defined

From an empty folder to 115 metrics in about a minute

Start from the e-commerce template, not a blank page. Your agent takes it from there.

$ uv tool install metrics-book

$ mb init acme_metrics
$ cd acme_metrics

$ mb templates install ecommerce

$ mb dev up

$ # the connector's URL, as mb dev up prints it
$ claude mcp add --transport http metrics_book <url>

Not released yet. These commands work from 0.1, the first release. See what works today.

The quickstart, step by step

Everything runs on one server

Follow one question through it. Every part is open source and code first, so your agent can change it and you can review it.

How it works, part by part

Every question is checked before it reaches your data

An agent asks as the person using it. A policy in git decides what each person may see, and the audit log keeps every answer and every refusal.

Access is decided per dataset. Rules per row, such as each market seeing only its own orders, are not in 0.1: put those rows in a dataset of their own. The access layer is built and tested; the MCP tools that use it are being built. See what works today.

How security works

Keep BigQuery or Snowflake if you want

The warehouse is one setting. Your pipelines, models, metrics, reports and access stay the same, so you can adopt the rest now and move your data to DuckDB later, or not at all.

# stack.yml
warehouse:
  type: duckdb

0.1 ships DuckDB and Postgres. BigQuery and Snowflake are each one module, built and tested against a real account before they are listed as supported.

How the warehouse choice works

Built on great open source

Metrics Book stands on these projects, and they deserve the credit.

Why we chose each one

Where to run it

One Docker Compose app on a Linux server with enough memory for your data. How to deploy says which servers give you the most for your money.