Self-Service BI Is a Lie (Unless You Govern the Metrics)

Self-service BI was supposed to free the data team. Give everyone a BI tool, teach them to drag and drop, and they'll answer their own questions. The data team can stop building dashboards and focus on infrastructure.

That's not what happened.

What happened: everyone builds their own dashboards with their own metric definitions. Marketing's "active users" counts monthly logins. Product's "active users" counts weekly feature usage. Finance's "active users" counts paying customers. Three dashboards, three numbers, one term. The data team now spends their time reconciling conflicting metrics instead of building.

Self-service BI without governed metrics is just self-service chaos.

What is self-service BI?

Self-service BI means non-technical users can query data, build visualizations, and generate reports without help from the data team. The tools (Metabase, Looker, Power BI, Tableau, Superset) provide drag-and-drop interfaces, visual query builders, and template libraries.

The promise: democratize data access. Anyone can answer their own questions.

The reality: it works for simple questions ("how many orders this week?") and breaks for anything requiring business logic ("what's our net revenue retention?"). Users either define metrics incorrectly or ask the data team anyway. The data team becomes a help desk for the self-service tool instead of a help desk for SQL.

Where self-service BI goes wrong

Metric sprawl

Without a central definition, every self-service user creates their own version of key metrics. A company with 50 Metabase users might have 30 different "revenue" calculations saved across collections. Which one is right? The one that matches the board report. Which one matches the board report? Nobody knows without checking each one.

The "someone who knows" bottleneck

True self-service requires understanding the data model. Which table has revenue? What does status = 3 mean? Is the amount column in cents or dollars? Pre-tax or post-tax? Including shipping or excluding?

Without this context, self-service users either guess (and get wrong answers) or ask the data team (and it's not self-service). The BI tool gives access to data. It doesn't give understanding of what the data means.

Dashboard proliferation

Every self-service user creates dashboards for their use case. The dashboard count grows from 10 to 500. Most are stale. Many are duplicates. Finding the right dashboard becomes its own research project. The data team periodically "cleans up," deleting abandoned dashboards and breaking someone's workflow each time.

Open source BI tools and their limitations

Open-source BI tools make self-service accessible without enterprise licensing. The main options:

• Metabase (AGPL): Most popular. Visual query builder, drag-and-drop dashboards. No semantic layer. Multi-tenancy requires Enterprise license.
• Superset (Apache 2.0): SQL-native, powerful for technical teams. No semantic layer. Limited multi-tenancy.
• Redash (BSD): SQL editor focused. Simple, lightweight. No governance features. Maintenance mode since Databricks acquired it.
• Lightdash (MIT): dbt-native. Good for teams already using dbt. Growing community. No MCP or embedded SDK.
• Evidence (Apache 2.0): Code-first reporting. Markdown + SQL. Good for scheduled reports. Not designed for embedded or multi-tenant use cases.

They share the same fundamental limitation: no semantic layer. Users query raw tables and define metrics ad-hoc. The open-source tools democratize access. They don't democratize understanding.

What real self-service looks like

Real self-service means anyone can query data and get the right answer. Not "anyone can query data and get an answer." The difference is governance.

The data team defines metrics

cubes:
  - name: revenue
    sql_table: analytics.revenue
    measures:
      - name: total_revenue
        sql: "CASE WHEN status != 'refunded' AND type != 'trial' THEN amount ELSE 0 END"
        type: sum
        description: "Finance-approved revenue definition (excludes refunds and trials)"
      - name: net_revenue_retention
        sql: "current_period_mrr / prior_period_mrr"
        type: avg
        description: "NRR for existing customer cohorts"
    dimensions:
      - name: plan
        sql: plan_name
        type: string
      - name: region
        sql: region
        type: string
      - name: period
        sql: period_date
        type: time

These definitions live in Git. Finance approves them in a pull request. When the definition changes, every consumer gets the update. There's one "revenue." Not 30.

Everyone queries the same definitions

The product manager asks an AI agent: "What's revenue by plan this quarter?" The agent calls explore_schema, finds revenue.total_revenue, and queries it. Same definition finance approved.

The customer success team views an embedded analytics dashboard in the product. Same definition.

The CEO checks a markdown dashboard. Same definition.

Nobody re-implements the metric. Nobody guesses which table to query. The data team defined it once. Every surface serves it.

The data team builds, not debugs

With governed metrics, the data team's job shifts from "answer ad-hoc questions" and "reconcile conflicting dashboards" to "define and maintain metric definitions." They add new metrics, refine existing ones, and optimize pre-aggregation strategies. The mechanical work (querying, formatting, presenting) is handled by the semantic layer and its consumers.

Self-service BI tools compared

Tool	Self-service model	Governed metrics	AI agent support	Open source
Metabase	Visual query builder	No	No	Yes (AGPL)
Superset	SQL + visual builder	No	No	Yes (Apache 2.0)
Redash	SQL editor	No	No	Yes
Power BI	Drag-and-drop	DAX (PBI only)	Copilot	No
Tableau	Drag-and-drop	Tableau model	Limited	No
Looker	LookML + Explore	LookML	No	No
ThoughtSpot	Natural language search	Proprietary	Proprietary	No
Semantic layer (Bonnard)	AI agents + SDK + dashboards	YAML (versioned, portable)	MCP native	Yes (Apache 2.0)

The tools in the top half give users direct data access with no metric governance. The tools in the bottom half add governance but lock it to their ecosystem. A standalone semantic layer provides governance without ecosystem lock-in and serves every surface: AI agents, React SDK, REST API, markdown dashboards, and TypeScript SDK.

When traditional self-service BI is enough

Self-service BI works when:

• A small team (< 10 analysts) agrees on metric definitions informally
• One BI tool serves all consumers
• Internal use only (no customers seeing the numbers)
• The data model is simple enough that users understand it
• You have someone who maintains a "source of truth" dashboard that others copy

It breaks when:

• Multiple teams define the same metric differently
• You need metrics in dashboards AND APIs AND AI agents AND embedded analytics
• Customers see the numbers (trust and consistency matter)
• The data team spends more time reconciling than building
• New hires take weeks to find the right dashboard

Getting started with governed self-service

Replace dashboard-as-the-product with metrics-as-the-product:

Cloud:

npm install -g @bonnard/cli
bon init
bon deploy

Self-hosted:

npx @bonnard/cli init --self-hosted
docker compose up -d
bon deploy

bon init generates agent configs for Claude Code, Cursor, and Codex. Define your metrics, run bon deploy, and every consumer (AI agents via bon mcp, dashboards via bon dashboard deploy, React apps via @bonnard/react) queries the same governed definitions. Use bon diff to preview changes and bon schema to explore deployed metrics.

For background: What Is a Semantic Layer?. For AI agent integration: How to Connect an AI Agent to Your Data Warehouse.

Self-host free under Apache 2.0, or use Bonnard Cloud for managed infrastructure.

Frequently asked questions

What is self-service BI?

Self-service BI is a BI model where non-technical users can query data, build visualizations, and generate reports without help from the data team. Tools like Metabase, Power BI, and Tableau provide drag-and-drop interfaces for this. The limitation: self-service without governed metrics leads to inconsistent numbers across the organization.

What is the best open-source BI tool?

For internal dashboards: Metabase (most popular), Superset (more technical), or Redash (SQL-focused). For governed metrics served to multiple surfaces including AI agents: a semantic layer approach. Open-source BI tools give you self-service querying. A semantic layer gives you self-service with correct, governed answers.

What is the difference between self-service BI and a semantic layer?

Self-service BI gives users tools to query data. A semantic layer defines what the data means. They're complementary: a self-service BI tool with a semantic layer underneath gives users access to governed metrics. Without the semantic layer, self-service users define metrics ad-hoc and the numbers diverge.

How do I prevent metric chaos in self-service BI?

Define each metric once in a semantic layer. Version the definitions in Git. Review changes in pull requests. Serve the same definitions to every consumer. When everyone queries the same governed definitions, there's nothing to reconcile.