# Snowflake Semantic Layer with Bonnard

> Connect Bonnard to Snowflake and ship governed metrics to AI agents, dashboards, and your product. A YAML semantic layer with MCP, React SDK, and a REST API.

Bonnard gives you a Snowflake semantic layer defined in YAML, version-controlled, and queryable from AI agents, React components, and REST APIs. If your team runs dbt models, stores event data, or centralizes reporting in Snowflake, Bonnard connects directly and exposes governed metrics through MCP, React SDK, REST API, and markdown dashboards.

## How does Bonnard connect to Snowflake?

Add Snowflake as a datasource in your Bonnard project. Define the connection in your `datasources.yml`:

```yaml
# datasources.yml
datasources:
  - name: snowflake_warehouse
    type: snowflake
    account: xy12345.us-east-1
    username: BONNARD_USER
    password: ${SNOWFLAKE_PASSWORD}
    database: ANALYTICS
    warehouse: COMPUTE_WH
    schema: PUBLIC
    role: BONNARD_ROLE
```

Then run:

```bash
bon datasource add snowflake_warehouse
bon deploy
```

Bonnard validates the connection, introspects your schema, and deploys your [semantic layer](/semantic-layer). No drivers to install, no middleware. Your Snowflake data is queryable through every surface Bonnard supports within minutes.

## What do you get?

Once connected, your Snowflake data is available through four surfaces:

**[MCP](/glossary/mcp) server.** Run `bon mcp` and your AI agents (Claude, ChatGPT, Cursor) query governed Snowflake metrics with row-level security. Generate publishable keys per tenant for customer-facing [agentic analytics](/agentic-analytics).

**React SDK.** Drop `BarChart`, `LineChart`, and `BigValue` components into your product. Every chart queries your Snowflake warehouse through the semantic layer with multi-tenant access controls applied automatically.

**REST API.** Query metrics programmatically from any language or platform. Type-safe queries with the TypeScript SDK or raw HTTP from anywhere.

**Markdown dashboards.** Author dashboards in markdown, deploy with `bon deploy`, and share governed views with your team or customers.

## How does Bonnard compare to native Snowflake analytics?

| Capability | Snowflake native | Bonnard + Snowflake |
|------------|-----------------|---------------------|
| Metric definitions | SQL views, Snowsight worksheets | YAML semantic layer (version-controlled) |
| AI agent access | None | MCP server with publishable keys |
| Embedded analytics | Snowsight (internal only) | React SDK with multi-tenant auth |
| Dashboards | Snowsight | Markdown dashboards, deployed via CLI |
| Multi-tenancy | Manual role management | Publishable keys + row-level security |
| Pre-aggregation | Materialized views (manual) | Automatic pre-aggregation cache |
| dbt integration | Native dbt support | `bon datasource add --from-dbt` imports models |
| Access control | Snowflake RBAC | YAML-defined RBAC + audit logging |
| Deployment | SQL scripts | `bon deploy` (no restart, no SSH) |

## Snowflake-specific optimization

### Virtual warehouse targeting

Bonnard's pre-aggregation rebuilds and live queries can target different Snowflake virtual warehouses. Run cache rebuilds on a small, always-on XS warehouse. Route ad-hoc queries to a larger warehouse that auto-suspends. This keeps costs low for background work and performance high for interactive queries.

### Pre-aggregation and Snowflake costs

Snowflake charges by compute time. Every query spins up a warehouse (or keeps one running). [Pre-aggregation](/glossary/pre-aggregation) reduces the number of warehouse queries by serving repeated requests from cache. For dashboards and AI agents that query the same metrics frequently, pre-aggregation can cut Snowflake compute costs significantly. Define rollups for your most-queried metrics and let cold queries fall through to the warehouse.

### Snowpark and Iceberg tables

If your team uses Snowpark for Python/Java UDFs or Iceberg tables for open table formats, Bonnard queries the resulting tables like any other Snowflake table. Define cubes on top of your Snowpark output tables or Iceberg-backed views. The semantic layer doesn't need to know how the data got there.

### dbt + Snowflake workflow

A common pattern: dbt transforms raw data into clean tables in Snowflake on a schedule. Bonnard defines business metrics on those tables and serves them to dashboards, AI agents, and applications in real time. Import your dbt models with `bon datasource add --from-dbt`. The two tools complement each other without overlap.

## FAQ

**Does Bonnard support Snowflake?**

Yes. Snowflake is a first-class Bonnard datasource. All Snowflake editions (Standard, Enterprise, Business Critical) are supported. Configure your connection in YAML, run `bon datasource add`, and deploy.

**Can I use pre-aggregations with Snowflake?**

Yes. The [pre-aggregation](/glossary/pre-aggregation) cache handles this automatically. Define rollups in your cube YAML files and Bonnard builds and refreshes them on schedule. This reduces Snowflake compute costs and speeds up repeated queries without manual materialized view management.

**How does multi-tenancy work with Snowflake?**

Generate publishable keys per tenant. Bonnard maps each key to a security context with row-level filters. Every query against your Snowflake warehouse is filtered automatically. No per-tenant Snowflake roles or databases required.

**Can I import dbt models on Snowflake?**

Yes. Run `bon datasource add --from-dbt` pointed at your dbt project. Bonnard imports your models as cubes and your metrics as measures. Layer the [semantic layer](/semantic-layer) on top of your existing dbt transformations without rewriting anything.

## Related

- [BigQuery integration](/integrations/bigquery) -- if your team also uses GCP
- [What is a Semantic Layer?](/glossary/semantic-layer) -- how metric definitions work
- [Bonnard vs Looker](/vs-looker) -- comparing Looker and Bonnard on Snowflake