Built for AI-first engineers

Your AI features need a data layer that works out of the box. Governed metrics, agent-native APIs, and a CLI that does the rest.

Read the docsView on GitHub

How your agent talks to your data

Every integration is agent-native. MCP for AI tools, SDK for your app, REST for everything else.

View docs →

TypeScript SDK

Type-safe client for querying metrics, managing models, and orchestrating agents.

View docs →

REST API

Query any metric over HTTP. JSON in, JSON out. Works with every language and platform.

View docs →

MCP Protocol

Native Model Context Protocol support. Your AI agent gets governed metric access out of the box.

View docs →

YAML Config

Define metrics, dimensions, and access rules in version-controlled YAML. Review in PRs, deploy from CI.

100% Accurate. 100% Scalable.

Define your metrics, business rules, and access policies once. Bonnard enforces them on every query, so your agents execute on real context, not hallucinated guesses.

View docs →

Your agent gets the right answer

Define metrics once in YAML. Your agent queries definitions, not raw tables. No hallucinated aggregations.

View docs →

Your clients only see their data

Row-level security per tenant. Token exchange maps your auth to the security context. Built in, not bolted on.

View docs →

Ship it your way

React SDK for AI chat in your product. MCP server for clients using their own AI tools. REST and GraphQL for everything else.

Schema
Search...⌘K
NAMEDESCRIPTIONFIELDS
Vorders_overview
Joins orders, customers, and line_items. Pre-aggregated AOV, fulfillment rate, repeat %.15
Vrevenue_analytics
Net revenue, refunds, and MRR by region, channel, and cohort month.13
Vproduct_performance
SKU-level sell-through, return rate, and contribution margin.12
Vcustomer_360
LTV, order frequency, RFM segment, and churn probability per customer.15
Corders
Source: warehouse.public.orders. One row per transaction.14
Ccustomers
Source: warehouse.public.customers. Deduplicated on email.13
Cproducts
Source: warehouse.public.products. Includes variants and pricing tiers.8
Cline_items
Source: warehouse.public.line_items. Quantity, unit price, discount applied.9
Cstores
Source: warehouse.public.stores. Physical and online locations with region.5

Every surface, one governed schema

Agent chat, embedded dashboards, MCP, REST. You wire it up once. Your agent and your customers query the same governed definitions.

what's driving revenue this quarter?
Let me start by exploring the available data sources to understand what's available for revenue analysis.
Used Bonnard MCP integration>
Now let me pull 2025 revenue data with a monthly breakdown:
40.0M30.0M20.0M10.0M0
JanFebMarAprMayJunJulAugSepOctNovDec

Answers your customers can trust

Your agent queries governed metric definitions, not raw tables. Every response is grounded in your business logic. No hallucinated aggregations.

View docs →
API KEYS
Publishable keypk_live_a3f8k9...x2m1
Secret keysk_live_••••••••••••
Your customer's MCP config
1{
2 "mcpServers": {
3 "acme-analytics": {
4 "url": "https://mcp.bonnard.dev/acme",
5 "headers": {
6 "Authorization": "Bearer pk_live_a3f8k9...x2m1"
7 }
8 }
9 }
10}

Offer in your product or via MCP

Embedded dashboards, React SDK, MCP server. Publishable keys let your customers access their data from wherever they work. You control what they see.

View docs →
page.tsx
1"use client"
2
3import { PageHeader } from "@/components/page-header"
4import {
5 BarChart,
6 LineChart,
7 BigValue,
8 useBonnardQuery,
9} from "@bonnard/react"
10
11function ChartCard({ title, children }) {
12 return (
13 <Card className="bg-secondary/30">
14 <CardHeader>
15 <CardTitle>{title}</CardTitle>
16 </CardHeader>
17 <CardContent>{children}</CardContent>
18 </Card>
19 )
20}
21
22function PromoCountBigValue() {
23 const { data, loading } = useBonnardQuery({
24 query: {
25 measures: ["promotion_data.count"],
26 },
27 })

SDK for every surface

REST for your app. React for embedded analytics. SQL for your internal team. Same governed model, every consumer.

View docs →
Schema›sales_performance›avg_order_value
sales_performance.avg_order_value
Average revenue per transaction
DEFINITION
TYPEavg
SQLsales_amount
CHANGE HISTORY
added23 Feb 2026, 20:01
Included from salesDeploy: Initial semantic layer: sales, product, store
+ description: "Average revenue per transaction"
+ name: "avg_order_value"
+ origin_cube: "sales"
+ sql: "sales_amount"
+ type: "avg"

Browse before you ship

Explore your schema, run queries, check results. See exactly what your customers will see before it goes live.

View docs →

Ship from the terminal

No clunky UI. Every feature is accessible via CLI and taught to your agent.

View docs →

Agent-ready from init

bon init scaffolds your modeling layer plus docs, skills, and rules for your agent. Your metrics are understood from the first commit.

View docs →

Self-host in minutes

docker compose up runs the full stack. Use the CLI to init, model, deploy, and query. Your infrastructure, no limits.

View docs →

Deploy to Cloud

Same CLI, managed infrastructure. bon deploy pushes to Bonnard Cloud. Zero ops, governance included.

View docs →

Fits your stack

bon datasource add --from-dbt and your models are in.
Auto-detected from your project.

Plug into what you already run

Point Bonnard at your project. It discovers your warehouse, your dbt models, and your orchestrator. No config required.

Warehouses

Snowflake
BigQuery
PostgreSQL
Databricks
DuckDB

Data Tools

dbt
Dagster
Prefect
Airflow
SQLMesh
View all integrations

Start building

Get from zero to governed AI analytics in minutes.

Get startedGitHubDiscord