dbt Semantic Layer vs Bonnard: Which Metrics Layer Should You Use?

dbt and Bonnard are complementary tools that solve different problems. dbt transforms raw data in the warehouse. It builds the tables. Bonnard defines business metrics on top of those tables and serves them to AI agents, apps, and dashboards.

dbt's MetricFlow defines metrics as code within the dbt workflow. That's useful for documentation and consistency. But MetricFlow doesn't serve those metrics. It doesn't cache them. It doesn't handle multi-tenancy, embedded analytics, or AI agent connections. For that, you need something on top.

Bonnard defines, serves, caches, and governs metrics. It connects directly to your warehouse (including your dbt-built tables) and ships governed analytics to every surface your team and customers need. It's the semantic layer built for agentic analytics.

Bonnard vs dbt Metrics at a Glance

Feature	dbt MetricFlow	Bonnard
Metric definition	YAML (MetricFlow syntax)	YAML (cubes + views)
Serving layer / API	No (needs partner integration)	REST, SQL, TypeScript SDK
Caching / pre-aggregation	No	Built-in cache
Multi-tenancy	No	Built-in (publishable keys + row-level security)
AI agent support (MCP)	No	Native (publishable keys per tenant)
Embedded analytics	No	React SDK (BarChart, LineChart, BigValue)
Dashboards	No	Markdown dashboards, deployed via CLI
Access control	No (warehouse-level only)	RBAC, row-level security, audit logging
dbt integration	Native	bon datasource add --from-dbt
License	Apache 2.0	Apache 2.0 (server), MIT (CLI)

Where does dbt Metrics fall short?

MetricFlow Defines but Doesn't Serve

MetricFlow lets you define metrics in YAML within your dbt project. But those definitions don't come with an API. To actually query those metrics from an application, you need dbt Cloud's Semantic Layer API (paid) or a partner integration like Looker, Hex, or Mode.

Bonnard serves metrics directly. REST API, SQL API, TypeScript SDK, React components, MCP for AI agents. Define the metric, deploy it, query it. No third-party integration required.

No MCP Support

dbt has no MCP integration. Your AI agents can't query MetricFlow definitions. There's no protocol for Claude, Cursor, or ChatGPT to access your governed metrics.

Bonnard deploys as an MCP server. bon mcp generates connection configs. For customer-facing scenarios, publishable keys per tenant let your customers connect their own AI tools to their own slice of the data.

No Multi-Tenancy

dbt operates at the warehouse level. There's no concept of tenant isolation, row-level security per customer, or publishable keys. If you're building analytics into a B2B product, you need to build all of that yourself.

Bonnard handles multi-tenancy at the semantic layer. Token exchange maps your existing auth into the security context. Every query is filtered automatically based on tenant context.

No Embedded Analytics

MetricFlow doesn't ship UI components. If you want charts in your product, you're building them from scratch or integrating with a separate BI tool.

The @bonnard/react SDK gives you BarChart, LineChart, BigValue, and useBonnardQuery. Governed, multi-tenant charts that query the semantic layer directly.

No Dashboards

dbt builds tables, not dashboards. You need a separate tool (Looker, Metabase, Hex) to visualize your metrics.

Bonnard includes markdown dashboards that deploy alongside your schema with bon deploy. Each tenant gets their own view, access-controlled automatically.

How do they work together?

dbt and Bonnard aren't competitors. They're adjacent layers in the stack.

Warehouse → dbt (transforms) → Bonnard (semantic layer + serving) → AI agents, apps, dashboards

bon datasource add --from-dbt imports your dbt models into Bonnard. Your dbt-built tables become the foundation of your semantic layer. Layer Bonnard cubes and views on top to define business metrics, then ship them to every surface.

dbt handles the T in ELT. Bonnard handles everything after: metric definition, governance, caching, serving, multi-tenancy, and distribution to AI agents and your product.

What This Looks Like in Practice

1. dbt builds your fct_orders, dim_customers, dim_products tables
2. Bonnard defines cubes on top: total_revenue, order_count, avg_order_value
3. bon deploy pushes the schema to your running Bonnard server
4. AI agents query via MCP. Your product renders charts via React SDK. Dashboards update automatically.

Same metrics, same governance, every surface.

Who should use dbt Metrics alone?

dbt MetricFlow is sufficient if:

• You're already using dbt Cloud with Looker, Hex, or Mode and those integrations handle your serving needs
• Your metrics are for documentation and consistency within your dbt project, not for serving to applications
• You don't need AI agent integration, embedded analytics, or multi-tenancy
• Your existing BI tool handles all visualization and access control requirements

FAQ

Does Bonnard replace dbt?

No. dbt transforms data in the warehouse. Bonnard defines and serves metrics on top of those transformed tables. They work together: bon datasource add --from-dbt imports your dbt models.

Can I use both MetricFlow and Bonnard?

Yes, though it's redundant. If you're already defining metrics in MetricFlow, you'd redefine them in YAML format to get serving, caching, MCP, and embedded analytics. Most teams pick one place to define metrics.

Do I need dbt Cloud for the integration?

No. bon datasource add --from-dbt reads your dbt project locally. It doesn't require dbt Cloud. Your dbt models just need to be materialized in the warehouse that Bonnard connects to.

How does caching work?

The pre-aggregation cache stores frequently queried metrics in pre-aggregated tables, reducing warehouse costs and improving query latency. dbt has no equivalent caching layer.

Is the Bonnard server free to self-host?

Yes. Apache 2.0. The self-hosted version includes every feature: MCP server, React SDK, markdown dashboards, multi-tenancy, pre-aggregation, RBAC, admin UI, CLI.