# Honeydew (full text)

> For in-depth product documentation, see the docs: https://honeydew.ai/docs
> Machine-readable docs index: https://honeydew.ai/docs/llms.txt (full text: https://honeydew.ai/docs/llms-full.txt)


## Access Control - Honeydew
URL: https://honeydew.ai/access-control/
### Access Control

Honeydew enforces governance through your warehouse - not around it.

Every query, whether from BI or AI, is compiled with your existing access rules, identities, and data policies built in.

#### Governance by Design

Domains in Honeydew are scoped layers of governance that define who sees what and how.

They combine semantic logic with access policies - applying security, filters, and overrides before any query is compiled.

Docs: [Domains](https://honeydew.ai/docs/domains)

#### Built on Your Data Cloud

Honeydew doesn’t reinvent access control - it compiles into it.

Your warehouse is the execution environment and the enforcement point for row-level security policies and access roles. Honeydew ensures every query respects those controls automatically.

Docs: [Row-level security](https://honeydew.ai/docs/security/row-level-security) · [Access control](https://honeydew.ai/docs/access-control/user-access-control)

#### User identity propagation

Honeydew connects directly to your identity provider for unified authentication and authorization.

When an authenticated user runs a query - through a dashboard, an API endpoint, or an MCP interface - Honeydew compiles it using their data warehouse identity, propagating their identity end-to-end.

Docs: [SSO](https://honeydew.ai/docs/access-control/sso)

#### Your infrastructure, your security

All processing done by Honeydew runs in your own accounts: your cloud data warehouse, your LLM provider, your Git provider and your authentication provider.

Docs: [Security](https://honeydew.ai/docs/security/security)

### Enforced below the AI

A model can reason its way around anything it's merely told. Honeydew enforces access below the model, where no prompt can reach.
Put an AI in front of your live data and every answer arrives already scoped to the person asking. The model never gets to decide who sees what.

### Honeydew's commitment to security

At Honeydew, we prioritize security from the start to ensure that your data is always protected. Honeydew is SOC 2 Type II compliant. We maintain industry-leading privacy standards, technology, and practices.


## Honeydew AI Interfaces - Honeydew
URL: https://honeydew.ai/ai/
### Where humans and agents collaborate

Governed AI in every interface.

A person asking in Slack and an agent working over MCP get answers compiled from the same definitions, with your access rules applied.

### Any interface, same AI

Honeydew connects AI analysis to where work happens.
Users and agents can ask, refine, and share results through Honeydew Studio, Slack, Microsoft Teams, embeddable APIs, or via MCP for external AI systems.

Docs: [AI overview](https://honeydew.ai/docs/integration/context-layer/overview)

### Safe automation through MCP

Through the Model Context Protocol (MCP), AI agents using Honeydew can safely act on data - trigger alerts, update systems, or recommend decisions - all within governed limits.
Each action passes through Honeydew's compiler, ensuring it follows business rules, access controls, and audit policies.

Docs: [APIs and MCP](https://honeydew.ai/apis-and-mcp/)

### Data, a chart, or a written answer

AI in Honeydew can return the right form for each question - data, chart, insight, or full report - all grounded in the same semantic logic. Agents using MCP can request the format and level of response they need.

Docs: [Deep analysis](https://honeydew.ai/docs/integration/context-layer/deep-analysis)

### Answers in Slack and Teams

Add the Honeydew app to Slack or Microsoft Teams and a business user asks in the channel they already work in. The answer compiles from the same governed definitions and access rules as every dashboard.

Docs: [Slack app](https://honeydew.ai/docs/integration/context-layer/slack-app) · [Teams app](https://honeydew.ai/docs/integration/context-layer/teams-app)


## APIs and MCP - Honeydew
URL: https://honeydew.ai/apis-and-mcp/
### APIs and MCP

The interfaces differ. The semantics do not.

Agents connect over MCP and applications call the SQL and GraphQL APIs. Every request compiles with your access rules built in.

### MCP, because analysis has state

Assistants and coding agents connect over the Model Context Protocol. It carries a stateful session, so a later step can name an earlier result and that reference goes back through the compiler.
Where a request needs no state from what came before, the SQL and GraphQL APIs give you the same answer.

Docs: [MCP](https://honeydew.ai/docs/integration/mcp)

### APIs for the software you build

Embedded dashboards and in-house front-ends call the SQL API or GraphQL. BI tools connect over JDBC and ODBC, and Excel over the XMLA endpoint it already speaks.
All of them resolve metrics, joins and filters from one set of definitions, so a number in the product you built matches the number in the dashboard next to it.

Docs: [Integrations](https://honeydew.ai/docs/integration/bi-tools/supported-tools)

### Every agent gets its own identity

An unattended agent cannot sit through a sign-in prompt, so each one gets a scoped key: a per-agent identity whose permissions and lifetime you set.
How far it reaches is set by a domain - the slice of the semantic layer that agent is allowed to see, with its filters already attached.

Docs: [API keys](https://honeydew.ai/docs/access-control/api-keys)

### Put the session record in your test suite

Every session is recorded centrally, and the record is programmatic: what the question was taken to mean, what context came back, the plan, the SQL that ran, and any feedback.
Evaluation APIs run a set of known questions on each publish, so a regression surfaces in your pipeline instead of in a meeting.

Docs: [Question history](https://honeydew.ai/docs/monitoring/question-history)

### Connect your AI assistant

Add Honeydew as an MCP server in Claude, Cursor, or Codex, point it at a governed domain, and ask it a question about your own data.


## Semantic Layer for BI - Honeydew
URL: https://honeydew.ai/bi-integration/
### Move business logic from BI to the data

Honeydew enables all BI Tools to operate directly on your data warehouse with a shared semantic model, governance and performance optimizations.

#### Automatic performance

Run BI on billions of rows, leveraging aggregate awareness and other automated performance optimizations

Docs: [Performance](https://honeydew.ai/docs/performance/overview) · [Aggregate awareness](https://honeydew.ai/docs/performance/aggregate-awareness)

#### Shared language

Centralize how your physical data structure is presented to your business users in their BI tools.

Docs: [BI tools](https://honeydew.ai/docs/integration/bi-tools/supported-tools)

#### No duplication

Define metrics and aggregations once, in the semantic layer. No need for Power BI DAX expressions or Tableau LOD calculations.

Docs: [Architecture](https://honeydew.ai/docs/architecture) · [Metrics](https://honeydew.ai/docs/calculations/metrics)

#### Modern workflow

Make sure every change is managed, versioned, approved and automatically tested.

Docs: [Version control](https://honeydew.ai/docs/governance/git-version-control) · [CI/CD](https://honeydew.ai/docs/governance/ci-cd/overview)

> Honeydew is a single source of truth both for the organization and for my team. Whether creating a new dashboard, running ad-hoc analysis or preparing board slides, with Honeydew we've gained confidence that every stakeholder speaks the same language.

— Omri Antman, Head of Data and Analytics


## Build with AI - Honeydew
URL: https://honeydew.ai/build-with-ai/
### Build with AI

A governed semantic layer, from the agent you already use.

Claude, Codex, Cursor, or Gemini build entities, metrics, and context validated against real data, landing the work as a pull request you review.

### Build fast with AI

Point the coding agent you already use at Honeydew and it builds entities, relationships, metrics, and context through validating MCP calls.

Docs: [Building with AI](https://honeydew.ai/docs/integration/context-layer/building-with-ai)

### A branch you can query before you merge

The agent works on a branch, and a Honeydew branch is a live endpoint - point a BI tool at it and query real data before anything merges.
Every object it builds is checked as it is created, against cardinality and against the data itself. The work ends as a pull request in your Git.

Docs: [Model with AI agents](https://honeydew.ai/docs/integration/mcp)

### Every session on the record

Every session, from every surface, lands in one history: the interpretation, the retrieved context, the plan, and every compiled query with its SQL.
The history is itself data you can query. Analyze it with your own tools - or point one of your agents at it to audit what the others did.

Docs: [Question history](https://honeydew.ai/docs/monitoring/question-history)

### Build it this week

Point a coding agent at your warehouse and it builds the layer on a branch you can query, review and merge like any other change.


## Case Pizza Hut - Honeydew
URL: https://honeydew.ai/cases/pizza-hut/
### Pizza Hut removes all barriers from business users who want Power BI and AI directly on Snowflake

With Snowflake and Honeydew, the semantic layer native to Snowflake, Pizza Hut makes all its transactional data available for self-service analytics and for AI.

#### Pizza Hut business users want to use Excel and Power BI on Snowflake
- Customers want Power BI and Excel for ad-hoc analysis
- Retail metrics must compute on Snowflake due to their complexity and data size
- Power BI Direct Connection is limited, slow and unreliable
Microsoft Fabric is a costly silo
Moving data to Fabric to improve Power BI led to data duplication, added storage and compute costs, duplicate data engineering efforts, inconsistency of metrics and a high latency to data.

#### Connect Power BI and Excel to Snowflake with a universal semantic layer native to Snowflake:
- Business users have granular access to any data they need. Slice and dice 10+ years of data at any level using >100 standardized metrics.
- Unified metrics in any self-service tool. Every metric from Snowflake is governed and consistent
- No data duplication. Snowflake serves as the single source of truth for all enterprise data, without copies or additional data pipelines.

### Results:

- **50%** — faster development of reports and business insights

- **30%** — reduction in costs and engineering effort by eliminating silos and duplicated pipelines

- **4** — hours, saved daily in ETL, ensuring data availability at 6am for every user

- **AI-ready** — unified metrics across every tools, enabling to reliably add Cortex on the data

### Pizza Hut democratizes BI and AI with a universal semantic layer native to Snowflake


## Data Team Collaboration - Honeydew
URL: https://honeydew.ai/collaboration/
### Collaboration

Honeydew makes your semantic layer a shared workspace.

Data engineers, analysts, and AI builders can all contribute to the same model — safely and transparently.

### One source of truth, many contributors

Every definition is versioned in YAML, so changes are readable, reviewable, and governed – just like code. Changes can be made in Honeydew Studio – or directly in code.

### Version control built for data logic

Honeydew tracks every change to your semantic model — additions, edits, and removals — across metrics, entities, and filters.
Teams can propose updates, review diffs, and merge approved changes with full history and rollback support.

Docs: [Version control](https://honeydew.ai/docs/governance/git-version-control)

### Connected to your workflow

Collaborate the same way you already do. Honeydew integrates with Git and CI/CD pipelines, making semantic changes part of your day-to-day release process.
Pull requests, approvals, and automated checks — all supported out of the box.

Docs: [CI/CD](https://honeydew.ai/docs/governance/ci-cd/overview)


## Context Layer - Honeydew
URL: https://honeydew.ai/context-layer/
### Teach AI your business

Schemas describe your data. They do not explain your business.

The context layer is where that explanation lives, owned by your data team and available to every tool that asks.

### Instructions, skills, and memory

Instructions carry the standing rules of your business. Skills are analysis playbooks - how to run a revenue-impact investigation, which canonical metric to use at each step. Memory records events for later analysis.

### Context follows the model

Every context item links to the semantic objects it describes, so retrieval is scoped by the model graph - an agent gets the context for the entities and metrics in the question.
Context lives in the same Git repository as the logic. A change goes through branch, test, review, and audit trail like any other change.

Docs: [Git version control](https://honeydew.ai/docs/governance/git-version-control)

### Same logic, different context

An agent is a domain paired with the context it needs. Finance and sales can each have their own - different definitions of what matters, different playbooks - over one shared model.
Nothing is duplicated. Change a metric once and every agent that uses it moves with it.

Docs: [Agents](https://honeydew.ai/docs/integration/context-layer/agents)

### Context shared by AI and BI

Both humans and AI agents need context in order to understand how to use the data. When users say an acronym like GMV, what do they mean? What metrics matter? What business nuances are important?
Contextual metadata in Honeydew is available to BI users as documentation and to AI as a managed business context.

Docs: [Metadata & context](https://honeydew.ai/docs/governance/metadata)


## Honeydew - Semantic Layer for AI and BI
URL: https://honeydew.ai/
### Trust AI with your enterprise data

Honeydew makes sure every AI interaction or BI query is correct, by unifying the layers of business logic and context governing your enterprise data.

- ON YOUR Snowflake, Databricks, Google BigQuery

- SUPPORTING Power BI, Tableau, More BI tools AND MORE

### Start your Semantic Layer journey

#### Build metadata quickly with AI

Use AI coding agents as Claude, Codex or Gemini to construct business logic in minutes

Building the model from a Claude prompt

#### Connect your AI and BI tools

Every BI tool, chat interface or AI agent can consume data from the shared source of truth

One model, live in Tableau, Power BI & AI agents

#### Trusted answers everywhere

The semantic engine compiles correct governed SQL for any query

Asking questions on a governed domain

#### Collaborate with your team

Integrate additional context and business logic with a data team workflow

Reviewing changes before publishing

### Shared source of truth for your data model and context

- Honeydew turns your warehouse into a living semantic layer that every tool and agent compiles from.

- Data teams gain control over definitions and lineage while freeing business users and AI agents to operate independently.

#### Semantic Compiler: How truth is enforced

Honeydew compiles every query, metric, and agent instruction from governed business logic. Deterministic execution enables 100% consistency without sacrificing flexibility.

Docs: [Semantic compiler](https://honeydew.ai/docs/semantic-compiler)

#### Unified Logic for Humans and Agents: How consistency is maintained

The same semantic layer powers BI like Tableau or Power BI - and AI like autonomous MCP agents or Slack chatbots. No semantic drift, ever.

Docs: [Consistency across BI & AI](https://honeydew.ai/docs/semantic-compiler#the-determinism-guarantee) · [Semantic objects](https://honeydew.ai/docs/architecture)

#### Agentic Semantic Memory: How to trust AI to safely operate with data

Honeydew AI runs multi-step analyses correctly by leveraging a shared semantic memory - no text-to-SQL guesswork. Every AI action has guardrails rooted in your semantic layer.

Docs: [Context layer](https://honeydew.ai/docs/integration/context-layer/overview) · [Deep analysis](https://honeydew.ai/docs/integration/context-layer/deep-analysis)

#### Enterprise Ready: How trust and control scale

Honeydew processes data inside your data warehouse, using your LLM provider. User identity propagation and native role-based access controls ensure end-to-end security. All changes are version-controlled through your Git provider and managed with full governance.

Docs: [Version control](https://honeydew.ai/docs/governance/git-version-control) · [Access control](https://honeydew.ai/docs/access-control/user-access-control) · [Security](https://honeydew.ai/docs/security/security)

### Trusted by teams that care

#### Pizza Hut

> It does not matter if they use Excel, Power BI, AI or any other BI tool. Everyone gets the same answer

— KARTIK PILLAI, Director of Data & Analytics

- The biggest win for our users is how easy it is to get data for any question in a consistent and safe way - just type it in plain English in Slack. With Honeydew, our team workflow is now streamlined around providing a shared data model, instead of ad-hoc requests.

- Honeydew has made Vermont Information Processing's complex strategic data warehouse significantly more accessible. We're now able to get to the data we need faster, eliminating repetitive SQL coding and empowering our teams. This foundation is a key enabler for our AI initiatives.

### SQL will never die

We believe that semantics should live in the data warehouse. A shared truth starts with a shared language – for people, for tools, for data transformation. We build a semantic layer with SQL at its heart.


## Migration - Honeydew
URL: https://honeydew.ai/migration/
### Replace the layer, keep the logic

Move decades of business logic without starting over.

A coding agent operates Honeydew directly, validating each object against your real data, while deterministic converters do the mechanical translation.

### A migration your team can drive

Deterministic converters do most of the mechanical work - SAP BusinessObjects universes, Strategy, AtScale, LookML, Tableau, Power BI and SSAS tabular models, dbt manifests, OSI, and Snowflake semantic views.
Your coding agent - Claude, Codex, Cursor, or Gemini - closes the rest, operating Honeydew through dozens of validating MCP tools and skills.

### Reconciliation is a pull request

Entities, relations, metrics, and domains land as YAML files in a Git repository you own. You read, diff, and approve the converted layer object by object.
A Honeydew branch is a live, connectable endpoint, so numbers reconcile against real queries before anything merges.

Docs: [Import tools](https://honeydew.ai/docs/migration/import-tools) · [Version control](https://honeydew.ai/docs/governance/git-version-control)

### The old stack retires on your schedule

Dashboards keep answering once their logic moves, so nothing freezes and no weekend gets picked as the cutover.
Power BI, Tableau, and Excel connect over the interfaces they already use, so those dashboards point at the new layer instead of being rebuilt.

### Start with your object count

Send us an object count from your universe or project and we will scope it against a converter that has seen that shape.


## Semantic Layer Modeling - Honeydew
URL: https://honeydew.ai/modeling/
### Modeling

Modeling defines what your data means. Build it in minutes with AI.

It turns your tables and tribal knowledge into business logic - the entities, metrics, and relationships that describe how your company actually works.

### Entities & Relationships

Define your core business objects - like Customer or Transaction - and how they connect.
Honeydew semantic compiler understands these relationships and uses them to generate joins, context, and filters automatically.

Docs: [Entities](https://honeydew.ai/docs/modeling/entities) · [Relations](https://honeydew.ai/docs/modeling/relations)

### Metrics: the language of the business

Metrics are how your business measures itself — Revenue, Active Users, Retention, Margin.
Define those metrics once, and reuse them everywhere. The Honeydew semantic compiler constructs on-the-fly correct SQL for any data consumer that needs them.

Docs: [Metrics](https://honeydew.ai/docs/calculations/metrics)

### One model, a domain per team

Teams don't fork the model - they extend it. A team's domain starts from the shared base and changes what differs: a regional filter added, PII columns dropped, a warehouse role pinned.
Everything else stays shared. Fix a metric in the base and every domain built on it gets the fix.

Docs: [Domains](https://honeydew.ai/docs/domains) · [Domain hierarchy](https://honeydew.ai/docs/recipes/domain-hierarchy)


## Performance and Warehouse Cost - Honeydew
URL: https://honeydew.ai/performance/
### Efficient SQL behind every query

Cubes and extracts are answers to questions you already had.

The compiler turns each question into a fast SQL statement that runs against your live tables.

### The warehouse works less

The compiler resolves only the metrics, joins, and filters a question asks for, pushes the filters down into the SQL, and prunes every join the question doesn't need.
A question against a hundred-table model scans only what that question needs.

### Aggregates accelerate any query

Your team defines a pre-aggregate and materializes it in your own warehouse, refreshed by your own ETL.
The compiler applies a pre-aggregate where it fits: to a whole question, to one subtotal branch of a pivot, or to the numerator of a ratio while the denominator comes from source.

Docs: [Aggregate awareness](https://honeydew.ai/docs/performance/aggregate-awareness) · [Performance](https://honeydew.ai/docs/performance/overview)

### Every query is on the record

Every request lands in query history with its runtime, its warehouse query ID, and the user and domain behind it, so spend traces back to a question someone asked.
A slow report gets a diagnosis. Its record shows whether a pre-aggregate was used - and when none was, where the next one should go.

Docs: [Query history](https://honeydew.ai/docs/monitoring/query-history)


## Pricing - Honeydew
URL: https://honeydew.ai/pricing/
### Get the Honeydew Semantic Layer

Whether you're a small data team or large organization, we're here to help you get started

#### Lite
Best for teams building an AI analyst or a shared data model for BI
$20 /user/month
Up to 50 users. Contact us for larger teams
Platform fee: from $500/month
For 100/250/500 active objects
Features
- One BI Integration
- Natural Language Interface
- Full Modeling Capabilities
- Snowflake Native App
- GitHub Integration
- SSO with Google
- SOC 2 Type II compliance

#### Standard
Best for organizations that seek to establish a shared source of truth
$30 /user/month
Up to 50 users. Contact us for larger teams
Platform fee: from $2000/month
For 250/750/1500 active objects
Everything in Lite plus
- Unlimited BI Integrations
- Power BI Service
- Aggregate Aware Caching
- GitLab, BitBucket Integration
- Microsoft Entra Integration
- SSO with Microsoft, Okta
- Enterprise Support

#### Enterprise
Best for organizations that require scale or specialized functionality
Custom
Tailored to your scope and requirements
Everything in Standard plus
- Reduced Cost Limited Users
- User Identity Propagation
- Other SAML SSO
- Private Deployment
- Custom SLA

### Frequently Asked Questions

#### Do you provide a free trial?

Yes! We provide a 14-day free trial. Our trials include:
Unlimited access to the system
Support over a dedicated Slack or Teams channel
Training session (typically on the second week of the trial)
Up to 4 hours of data modeling guidance

Need a larger pilot? Talk to us.

#### What is an active object?

An active object is a field within a Honeydew workspace (a source attribute, calculated attribute or a metric) that is part of an active domain, used by BI tools, AI agents, API calls or data deployments.
A domain is considered active if during a month it was used to serve a data consumption tool:
Process SQL queries
Process AI queries
Process API calls (excluding metadata)
Deploy a dynamic dataset

A domain is not considered active if it is only accessed through the Honeydew UI.
For example, if there is a domain called marketing with 250 objects (out of 3,000 objects across many domains), and only that domain received queries from Power BI during a month, then for that month there would be 250 active objects.

#### What happens if an object is used in multiple domains?

The same unique object can participate in multiple active domains. It will only be counted once, regardless of how many domains it is included in.

#### What happens if an object is used in multiple branches?

The same unique object can participate in multiple development branches. It will only be counted once, regardless of how many versions exist in development branches. It is possible that the same domain will have a different composition of objects in a development branch and in the production branch. An object is counted if it participates in an active domain in any branch.

#### What is a user?

A user is someone who is consuming Honeydew through an external tool, an API or via the Web interface. That can include:
Users that log into BI tools with user authentication or SSO (single-sign-on).
Users that ask questions through an AI interface (like a Slack bot).
Users that call the Honeydew Snowflake Native Application through a Snowflake connection.
Users that use the Honeydew Studio for modeling or data exploration.

#### Do users have query limits?

There are no query limits. Users can query as much as they want. Enterprise tier contracts may include query-limited users.

#### Can I use a single service user instead of SSO?

Yes. There are workloads where there is no authenticated user running queries. Common use cases include:
Use a single integration user to process all queries from a BI tool.
Data tools that do not support user identification or authentication.
Honeydew API calls from an embedded application.
Honeydew API calls from an automated process, like dbt.

Reach out to us for custom pricing.

#### Are there volume discounts?

Yes! We provide volume discounts upon annual commitment.

#### What happens if I consume more than my yearly package?

Overage consumption is charged based on the subscription tier without volume discounts.

#### What is a limited user?

Limited users are available in Enterprise tier. A limited user can be limited to a specific domain or a limited number of queries.

#### Do you provide support, training or help modeling?

All tiers include product support during business hours with response SLAs based on issue severity. In addition, we provide training, as well as guidance based on your particular data model and business domain. Questions we can help with include:
Best practices for data modeling and data governance.
Assistance for modeling complex metrics and other semantics.
Help to migrate semantics from existing sources, including with automatic conversion tooling.
Provide guidance on how to model data best for AI workloads.


## Semantic Compiler - Honeydew
URL: https://honeydew.ai/semantic-compiler/
### Semantic Compiler

The AI decides what to ask. It never decides how.

Compilation is deterministic, so the same question becomes the same SQL whether an agent, a dashboard, or Excel asked it.

### Compiler-backed SQL, not text-to-SQL

Honeydew's AI does not guess SQL — it compiles it.
Each analytical step is translated into a compiler plan that resolves metrics, joins, and filters from the semantic model before generating SQL.
When steps depend on one another, Honeydew re-compiles the logic, carrying forward lineage and constraints so results remain consistent.

Docs: [Semantic compiler](https://honeydew.ai/docs/semantic-compiler)

### AI and BI share the same compiler

AI and BI pull from the same semantic definitions, so they never diverge.
When an AI agent asks for Revenue by Region and a BI dashboard runs the same metric, both use the exact same joins, filters, and logic defined in Honeydew.
There is no second set of definitions, no duplicated logic, and no room for AI to invent its own interpretation.

Docs: [The determinism guarantee](https://honeydew.ai/docs/semantic-compiler#the-determinism-guarantee)

### Each step knows what the last one found

An analysis runs as a sequence of steps.
Each step is aware of the previous ones, sharing both the results and the semantic context (entities, metrics, and filters) defined in the model.
This makes complex analysis like "compare retention drivers between EU and US cohorts" precise and reproducible.

Docs: [Deep analysis](https://honeydew.ai/docs/integration/context-layer/deep-analysis)

### Every answer shows its work

Every AI session is logged and explainable — from inputs and plans to executed SQL and results.

Teams can trace how the AI reasoned, what definitions it used, and how it judged its own output.

Docs: [Question history](https://honeydew.ai/docs/monitoring/question-history)


## Excel and BI on the Warehouse - Honeydew
URL: https://honeydew.ai/solutions/excel-and-bi-on-the-warehouse/
### Excel, live on your warehouse

Excel becomes a governed BI tool.

Business users build native pivot tables on the full warehouse, and every number matches the dashboard and the AI answer - same metrics, same access rules, compiled from one governed model.

### A cube to Excel, a dynamic layer underneath

Excel connects over XMLA and sees a governed domain as a multidimensional cube: entities as dimensions, attributes as hierarchies, metrics as measures. Underneath, the semantic layer compiles each pivot against the live warehouse.
Drill-down, slicer filters, grand totals, and right-click drill-through work in the native PivotTable - no add-in. The XMLA endpoint works with Microsoft Excel.

Docs: [Excel connection](https://honeydew.ai/docs/integration/bi-tools/excel) · [XMLA interface](https://honeydew.ai/docs/integration/xmla-interface)

### Live pivots on billions of rows

A pivot refresh asks for every level, subtotal, and grand total at once. The engine is built for that shape - one compiled query per refresh, whatever the sheet asks for.
When a subtotal branch of the pivot has a pre-aggregated table behind it in your warehouse, the compiler reads from there instead.

Docs: [Aggregate awareness](https://honeydew.ai/docs/performance/aggregate-awareness)

### One compiler, every surface

A pivot refresh, a Power BI dashboard, and an AI answer compile from the same governed model on Snowflake, Databricks, or Google BigQuery - same metrics, same joins, same row-level security.
Right-click a pivot cell to open a governed AI analysis carrying that cell's metric and filter context.

### Start with one pivot table

Connect Excel to a governed domain and refresh - then open query history and read the one compiled query it produced. Every level, subtotal, and total came out of it.


## Blog: AI Can Write SQL. It Still Fails as an Analyst.
URL: https://honeydew.ai/blog/ai-can-write-sql-but-still-fails-as-an-analyst/
The first demo of any AI analyst feels magical. Show me Q4 revenue? AI nails it. Show me user growth? A breathtaking interactive infographic in 5 minutes.

AI is getting better and better in writing SQL. Anyone, anywhere can now just ask about the data.

And if I were heading a data team right now, I’d be terrified.

Two scenarios can play out three months into an “ask data” deployment:

### **The Chaos**

The agent ships with full warehouse access. Everyone’s thrilled – until someone notices the revenue numbers don’t match the board deck. The data team investigates and finds 31 different definitions of “monthly recurring revenue” across chat histories. Some count annual contracts monthly, some exclude services, some include. Nobody remembers what the board deck uses.

Excel sprawl feels like the good days.

### **The Lockdown**

Data teams fight back. The agent now only answers questions about carefully curated datasets. Root cause analysis? No dataset for that. Cross-domain questions? Can’t cross those boundaries.

The flexibility that made AI exciting — **ask anything**! — is gone. At best, you’ve got a very expensive conversational dashboard browser.

## **What went wrong?**

Both Chaos and Lockdown are the same mistake: treating AI as a replacement for the layer that keeps data trustworthy, rather than a consumer of it.

Tools like Claude Code have made it easy to generate a data model with neat tables and metadata – weeks of work now takes hours. But as enterprises find out, generating the model isn’t the hard part. Operating it is:

_How do you let **anyone** ask **any question** while keeping the answers correct, governed, and consistent?_

## **Better SQL makes this worse, not better**

AI writes better queries today than it did three months ago (don’t mind the publish date, this one is going to be a true statement for a while). Agents and LLMs improve – they understand context better, they understand the nuances of SQL better, they can read more metadata.

Counterintuitively, **the better AI gets at writing SQL, the bigger the challenge of correctness becomes**. As AI makes it easy for more people to build more queries, it makes it easy to be wrong, often.

The thing about data is that unlike so many other things we deal with in life, it has the special property of being _right_ or being _wrong_. And being wrong with data carries an outsized risk of bad decisions.

There is an infinite number of ways to calculate something wrong. There is usually only one way to be right. You have to ensure every single question gets it right.

## What the old stack got right

In the old world, dashboards were built on top of a data model – Tableau’s data sources, Power BI’s semantic models, Looker’s LookML. That model wasn’t just documentation. It was a compiler and an enforcer of constraints.

You defined “revenue” once. Every dashboard on the same data model used the same definition. Security rules applied automatically. Performance optimizations were built in.

![](/assets/blog/ai-can-write-sql-but-still-fails-as-an-analyst/ai-can-write-sql-but-still-fails-as-an-analyst-fig-1.png)

Now, with AI and direct SQL generation, we’re skipping what that layer provided.

There are three key requirements for AI on data at scale:

**Guaranteed Correctness**

When someone asks “how many active users did we have last weekend?”, calculating that is complicated: engagement sessions, platform differences, time windows, exclusions. You probably have 1500 lines of SQL defining it correctly.

With AI-generated SQL, you get probabilistic results. In one tab it says 240k, in another 260k. Which is right? You might be tempted to just build a table with number of users by day, so the AI takes the right number from it.

But then when the user asks the same question _broken down by cohort_, the answer should use the same definition of “active users” but within a very different query. You need a way to ensure that the definition of active users is deterministically reworked for the new question, not probabilistically regenerated. Once the numbers don’t add up, users lose trust.

**Context Governance**

Give people AI + database access and watch: they cache results, tweak queries, export CSVs that become inputs to other people’s questions. This is Excel sprawl at AI speed.

Meanwhile, important business logic lives in people’s heads. The VP of Sales knows “enterprise deal” changed meaning after the Q3 pricing overhaul. Finance knows revenue recognition rules changed with the new ERP. You need a system where that context gets captured, validated, versioned and enforced – not lost in chat threads.

**Operations: Performance, Security, Observability**

A sales rep asks about pipeline at 2am. They should automatically see only their region. Someone queries a three-year trend across 50M rows. It should hit pre-aggregated tables without anyone knowing those tables exist. One security leak, one unbounded query that takes down the warehouse – that’s all it takes.

And when your data changes – it always does – everything downstream must update instantly. When numbers shift, you need to trace why: which definition changed, which version was active, what’s different from last week. Without that, debugging is guesswork.

## **What actually works** now

The teams getting this right aren’t putting AI directly on the data.

![](/assets/blog/ai-can-write-sql-but-still-fails-as-an-analyst/ai-can-write-sql-but-still-fails-as-an-analyst-fig-2.png)

**They separate the layers:** Gold layer for data. Semantic layer for business logic and context. User tools go through the semantic layer to get the assurances of correctness.

**They treat semantics as infrastructure:** The model with the business logic and its context becomes the core data product built for end users; the semantic layer that delivers it becomes a critical component of the data stack.

**They build workflows:** The system only works if it can evolve. Business logic and context are versioned, tested and reviewed. Workflows are put in place for capturing new business context, reviewing changes, and deploying safely.

**They plan for expansion:** AI capabilities grow: co-working AIs, autonomous agents, file uploads, cross-domain questions, alerts, Slack/Teams integration. A shared foundation must support every use case – each one that bypasses it multiplies the chaos.

### What’s next?

AI projects fail because they’re solving the wrong problem. The problem isn’t: “_how do we make AI generate better SQL?_“. The problem is: “_how do we maintain governance, correctness, and trust while enabling flexible questions?_“

AI changes the interface, not the architecture.

To solve architecture, look at semantic layers and what they do. Or [check out](https://honeydew.ai/) Honeydew as a Semantic Layer for AI.


## Blog: OSI is Cool: Why Honeydew Joined the Open Semantic Interchange
URL: https://honeydew.ai/blog/osi-is-cool-why-honeydew-joined-open-semantic-interchange/
Over the years at Honeydew, we’ve built our foundation on one simple belief: if you want people to trust data - whether from dashboards, AI agents, or BI tools - your semantics have to be consistent, understandable, and shared. We’ve fought the typical misalignments: one tool calls something “active_users”, another calls it “users_engaged”, a third treats “active” inconsistently. It doesn’t just slow things down - it erodes trust.

That’s why today we’re announcing that Honeydew is joining the Open Semantic Interchange (OSI) feels like a long-overdue step in the right direction. OSI is a chance to define something that scales beyond individual tools or vendors. It’s about ensuring that when you ask a question - from a BI dashboard, or via an AI assistant in your Teams or Slack - you get the same meaningful answer. OSI means the definitions you rely on at Honeydew will travel well.

Over the years, I’ve had hundreds of conversations with customers and partners about the value of interoperability. It aligns with what we’ve been pushing deeply in our roadmap: expressiveness, portability, and governance. As an open, vendor-neutral standard OSI helps us focus on what we do great: help users ask anything they want, from any tool they use.

A semantic layer isn’t just about the metadata - it’s about what you can do with it. A definition of “active users” might exist in metadata, but on its own it doesn’t help a business user ask, “How many new active users joined since yesterday?” This is where we come in. With our semantic compiler, metrics and dimensions flow into any BI tool - so users can just drag and drop them for a right answer. With our semantic AI agents, free-text questions in Slack or Teams rely on the same compiler for 100% consistency. And more: aggregate awareness acceleration so queries are both correct _and_ fast; governance and security enforcement all the way from a user tool to the warehouse; and a practical workflow for data teams so it’s possible to build and maintain a semantic layer that serves an entire organization across its many domains.

At the end of the day, OSI is about giving the ecosystem a common metadata language - and that’s important. The reason our customers choose Honeydew is because we turn metadata into something tangible: governed, expressive, fast, and usable.

We're proud to join Snowflake and our fellow partners in this important initiative. To learn more about the Open Semantic Interchange, read Snowflake's announcement [here](https://www.snowflake.com/en/blog/open-semantic-interchange-ai-standard/).


## Blog: Honeydew and Snowflake Semantic Views
URL: https://honeydew.ai/blog/honeydew-and-snowflake-semantic-views/
Last week, Snowflake announced the availability of [Semantic Views](https://docs.snowflake.com/en/user-guide/views-semantic/overview).

Let’s talk about how Semantic Views and Honeydew integrate: commonalities, differences, and how to _data mesh_ Honeydew with your Semantic Views.

![Snowflake Semantic Views and Honeydew integration](/assets/blog/honeydew-and-snowflake-semantic-views/snowflake-semantic-views-and-honeydew.png)

Lets start with,

## What is a Snowflake Semantic View?

A Semantic View is a schema-level object that:

1. Stores a single _Cortex semantic model_
2. And makes it available for AI or BI tools to consume with a special query interface.

For example, the semantic model below represents retail sales data:

- There are three connected tables (`line_items` , `orders` and `customers`) representing customers and their orders.
- There are metrics on top of them (such as `order_average_value`) to allow counting customers, orders and their properties.

```sql
CREATE SEMANTIC VIEW tpch_analysis

  TABLES (
    orders AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.ORDERS
      PRIMARY KEY (o_orderkey)
      WITH SYNONYMS ('sales orders')
      COMMENT = 'All orders table for the sales domain',
    customers AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.CUSTOMER
      PRIMARY KEY (c_custkey)
      COMMENT = 'Main table for customer data',
    line_items AS SNOWFLAKE_SAMPLE_DATA.TPCH_SF1.LINEITEM
      PRIMARY KEY (l_orderkey, l_linenumber)
      COMMENT = 'Line items in orders'
  )

  RELATIONSHIPS (
    orders (o_custkey) REFERENCES customers,
    line_items (l_orderkey) REFERENCES orders
  )

  FACTS (
    line_items.line_item_id AS CONCAT(l_orderkey, '-', l_linenumber),
    orders.count_line_items AS COUNT(line_items.line_item_id),
    line_items.discounted_price AS l_extendedprice * (1 - l_discount)
      COMMENT = 'Extended price after discount'
  )

  DIMENSIONS (
    customers.customer_name AS customers.c_name
    customers.customer_market_segment AS customers.c_mkt_segment
    orders.order_date AS o_orderdate
      COMMENT = 'Date when the order was placed',
    orders.order_year AS YEAR(o_orderdate)
      COMMENT = 'Year when the order was placed'
  )

  METRICS (
    customers.customer_count AS COUNT(c_custkey)
      COMMENT = 'Count of number of customers',
    orders.order_average_value AS AVG(orders.o_totalprice)
      COMMENT = 'Average order value across all orders',
    orders.average_line_items_per_order AS AVG(orders.count_line_items)
      COMMENT = 'Average number of line items per order'
  )
;
```

In addition to storing the **metadata** (a _semantic model_), the Semantic View provides a way to consume that logic with a special [query language](https://docs.snowflake.com/en/user-guide/views-semantic/querying):

```sql
-- Get the average order value by market segment
SELECT * FROM SEMANTIC_VIEW(
    tpch_analysis
    DIMENSIONS customer.customer_market_segment
    METRICS orders.order_average_value
  );
```

When executing the query above, Snowflake will first join the customer and orders table, and then aggregate the `order_average_value` metric, grouped by `customer_market_segment` .

## Semantic View(s) and Honeydew

Honeydew is a Semantic Layer for AI+BI.

From a high level perspective, both Honeydew Semantic Layer and a Snowflake Semantic View appear to serve a similar task:

1. Create a single place for business logic on top of data in Snowflake
2. That consistently serves all AI and BI workloads

The core difference is **scope**: while a Semantic View is a singular schema-level object for a specific purpose, Honeydew is organization-wide layer for multiple data models and semantic views, serving diverse workloads and many semantic views.

But first, what happens if you wrap **one semantic view** in Honeydew?

## Step 1: One Semantic View in Honeydew

What a Semantic View is added as a source to Honeydew, Honeydew will extend the shared semantic layer with the Cortex Semantic Model stored in that view, and provide **all Honeydew functionality** on top of that view.

![Adding a Snowflake Semantic View as a source in Honeydew](/assets/blog/honeydew-and-snowflake-semantic-views/adding-semantic-view-as-source.png)

For example, if a Semantic View has defined a relationship between customers and orders, Honeydew will know those tables connect; if a Semantic View defines a summation metric, Honeydew will know that as well.

This has a number of use cases:

### Standard BI interface for a Semantic View

Honeydew supports a standard SQL interface and a metadata integration for many common BI tools such as Microsoft Power BI, Tableau, Looker, Domo, Quicksight and others.

![Honeydew BI tool integrations: Power BI, Tableau, Looker, Domo, Quicksight](/assets/blog/honeydew-and-snowflake-semantic-views/honeydew-bi-tool-integrations.png)

A Semantic View wrapped in Honeydew is immediately available to any BI tool for dynamic live queries. Honeydew also provides the BI tool with all the business-facing metadata (such as descriptions, folders or formatting) of the metrics and dimensions.

With dynamic live queries using standard SQL, there are no limits on what a user can do. They can ask on any level of detail of any metric with any filtering:

![image](/assets/blog/honeydew-and-snowflake-semantic-views/image.png)

Whether the BI user is aggregating across all data or is looking at the details of a specific transaction, Honeydew _will create on the fly_ a tailored and specific Snowflake query that answers the user question.

### Semantic Enrichment

Semantic Views are a relatively simple model with limited query functionality.

By using them as a source in Honeydew, that functionality can be extended:

1. To support more complex metrics (varying level of details, order of filtering, dynamic grouping, multi-fact relationships, time intelligence, etc.)
2. To support more flexibility with queries using the existing metrics defined in the view (for example allowing to mix levels of granularity in a query)
3. To support richer metadata (AI or BI-specific, such as a formatting)

**Note**: To support more enrichment, Honeydew query generation on a Semantic View model may seamlessly use Honeydew’s own semantic compiler as-required.

### Performance Optimization

Honeydew includes a set of performance features that include optimized query generation and caching. A common use case is _Aggregate Awareness_: using aggregated data in lieu of the original granular data when it matches a user query.

For example, if a user queries for total order value by customer segment, a simple query would join the a large `orders` table with `customers` and aggregate. If there are 100M orders, the query would process 100M rows.

However, with Aggregate Awareness, Honeydew can detect that there is a table with total order value already pre-computed by _customer id_. Honeydew compiler will then join to it `customers` to get the customer segment, and sum up the total order value. If there are 100,000 customers for those orders - then only 100,000 rows would need to be processed for the same response, 1000x faster.

### Explainability

The Honeydew Semantic Layer is built for collaboration and testing. As such, a number of Honeydew features can be helpful to understand a Semantic View: logic lineage, a relationship diagram, and a testing playground.

Queries generated by Honeydew are also explainable, transparently showing the particular joins or order of computation invoked. As the complexity of semantics grows, explainability becomes a key feature for maintaining correctness.

## Step 2: Many Semantic Views in Honeydew

As a singular object, Semantic Views can help to set the ownership boundaries for a single data product.

Honeydew connects data products together as sources with relationships, ownership, governance, versioning and testing, making Snowflake into a connected data mesh.

![Honeydew connects data products as a connected data mesh in Snowflake](/assets/blog/honeydew-and-snowflake-semantic-views/connected-data-mesh-in-snowflake.png)

### Semantic View as a Data Contract

Data owners can use Semantic Views to create a data contract for their delivery. Honeydew enforces those contracts, as data sources connect across teams and domains.

### Collaborative Workflow for Semantics

As the number of users that use shared semantic logic scales up, so are the **collaboration requirements**.

Consider a single DDL statement (like a Semantic View) as a single “_thing_”.

In a collaborative environment like a semantic layer there are many “_things_” to agree on. Some are data sources (a table, a view or a semantic view acting as a data contract). Some are metric calculations, entity definitions, or business metadata. “Things have inter-dependencies, are shared across different domains, and have ownerships and metadata.

Things managed in Honeydew (called semantic objects) have a lifecycle and an associated workflow:

### Semantic Object

A semantic object in Honeydew can be a data source, an entity, a relationship, a metric, a domain, or an aggregated dataset. Every object has an owner, and is backed by a Git file (using your Git provider - GitHub, GitLab, BitBucket or Azure DevOps).

As a managed object, it is part of a change management workflow:

- **Ownership**: objects can have owner
- **Versioning**: objects always have a version (backed by Git)
- **Reviews and Approvals:** when an object changes, it can go through an approval and review process before being added to the shared semantic layer

It is also a part of a shared world, with:

- **Logic Lineage**: objects can be based on other objects. For example, a profit margin metric might be based on a profit metric and a cost metric (each managed by different teams). Note that in a semantic layer lineage is for _logic_, not for _data_, which makes traditional data lineage tools inapplicable.
- **Logic Reuse**: objects can (and should!) be reused, following the DRY (”Do not repeat yourself”) principle. For example, a customer entity or a revenue metric may participate in multiple other objects, such as aggregated datasets or domains with the same definition.
- **Impact Radius**: When an object changes or breaks, it’s important to know what is logically affected to avoid downstream failures, and create a foundation that minimizes the blast radius of a change.
- **Business Interpretation**: an ability to control (with versioning and collaboration) how an object appears to different business users, AI agents or BI tools. For example, a sales team and a marketing team might have different preferred names for the same metric.

### Development Workflow

As people collaborate on shared objects, Honeydew enables a development process with:

- **Development environments**: an ability to build and test changes in isolated environments for local development, testing and production.
- **Development** **workflow automation**: an ability to add automated testing or AI evaluations for changes that go into the shared semantic layer.
- **Granular Object Security**: different objects (like metrics) might have different access control, based on user roles. While security and governance in Snowflake apply to data, Security within a semantic layer applies to the semantic objects - the metadata.

As both data sources and targets diversify, Honeydew provides metadata synchronization for the shared semantic objects from source (i.e. a dbt model or a semantic view) to target (i.e., a Tableau workbook).

## Available Now!

Honeydew support for Semantic Views as a semantic source is currently in private preview.

Interested to get access today? Reach out to [hello@honeydew.ai](mailto:hello@honeydew.ai) or [set up a demo](/get-started/).


## Blog: Our 2025 Roadmap: From BI to AI
URL: https://honeydew.ai/blog/our-2025-roadmap-from-bi-to-ai/
**TL;DR** Every second deployment of Honeydew today is to help an AI agent to understand a business. This is changing us and the whole industry around us - our plans, our priorities, and our pricing.

## Honeydew’s Job in 2024

Organizations use Honeydew to [create a source of truth](/blog/so-lets-talk-about-semantic-layers/) for diverse metrics and data sources: from traditional financial and product metrics like gross revenue or user conversion to highly business domain specific metrics, like drug trial success rates or image processing efficiency.

Even internally at Honeydew, we use Honeydew - to analyze our website (using Google Analytics data in our Snowflake), understand our customers (with data flowing to Snowflake from HubSpot), and improve our product (using our product analytics data).

By having a semantic layer - a source of truth for business logic - every data tool and every user can get ad-hoc access to trusted data. When they need it, in the way they need it.

Traditionally, a semantic layer powers BI: reports and dashboards. Users equipped with tools like Microsoft Power BI or Tableau use Honeydew to slice and dice metrics directly from Snowflake.

Now, AI is here and it’s updating the game.

## The Value of a Semantic Layer in the world of AI

With AI, relevant data can always be ready, with a simple Slack or Teams question.

Instead of searching in a catalog - ask AI. Instead of browsing through a BI dashboard - skip the dashboard. Ask AI. Instead of drilling down in data - ask AI to drill down. Instead of begging an analyst to export data to Excel - order your AI to do it. Or ask nicely.

And it isn’t just about efficiency or productivity. When the data is somewhere in some dashboard, many users will never access it. It’s far, or complex, or intimidating. Simpler access means more people use data, make informed decisions, feel better prepared and more confident.

Which is only possible if the AI your run to get data understands your business well enough.

Creating a source of context for AI becomes [one more job of a semantic layer](/blog/talk-to-your-data-loudly/). Our job.

## AI is BI is AI is BI

Have you ever wondered what would happen if a user asks a question and gets a different number than the one she knows from the dashboard?

Data teams we talk to often wonder about that. And their conclusion is whenever that happens to a user, she’ll think _both_ numbers are wrong. And then blame them. The [data people](https://www.getdbt.com/blog/we-the-purple-people).

When people talk about consistency with AI, they talk about consistency between subsequent questions. But a consistency that is even more important is consistency with other tools. That’s the type of consistency that builds trust.

People expect to see the same numbers in BI and AI. Sometimes to verify, sometimes when they are second guessing themselves. And sometimes because for some tasks and for some people - dashboards and reports are the best tool to dive into data, not AI.

That means that our job of **\*being a source of truth\*\*\*** \*for BI\*\*\* is as strong in 2025 as it was in 2024. We’ll make your Power BI fly with your metrics on a billion events in Snowflake.

But we’ll also make them match when you get them from AI.

## A Pricing Model to Fit AI

With AI, users in an organization are more empowered every day. Some users can just ask an AI chatbot a question once a month. Some refresh a dashboard every 5 minutes.

The value of a semantic layer is helping everyone get access to data. That one question a month might give the salesperson the data point he needed to push for a $100,000 renewal. Or a custom support rep to detect an obscure issue in an hour instead of waiting a week for an engineer.

Semantic layers are about helping people. The more people we help, the more value an organization gets. The value of a semantic layer is by having data available whenever you need it. Whether its an ad-hoc natural language question, an ad-hoc Excel Pivot Table report or an ad-hoc Pandas dataframe.

So our [pricing unit](/pricing) is now users and not queries, as it was in 2024. Anyone can use AI, use BI, use API - any time, any way, without limits.

## Our Roadmap for 2025

As we go into 2025, we see a lot of work ahead of us in enabling a semantic layer as a foundation for an AI that understand the business, and a foundation for BI teams at large.

We will,

1. Add more BI tool integrations (we have [over 20](/docs/integration/bi-tools/supported-tools) today).
2. Add even more modeling capabilities (like [time intelligence](/docs/advanced-modeling/time-metrics)).
3. Add more ways to use natural language with data - with Slack, Teams, Email or [custom tools](/docs/integration/cortex-and-llm#text-to-sql-api).
4. Add more advanced management features for access control, audit and governance.

There are core workflows where we want spend our product efforts on -

1. Create a workflow for data teams to build business context for AI. We'll help data modelers identify user questions that underperform to pro-actively improve the AI.
2. Improve validation and evaluation framework to keep AI and BI at bay as semantics change. When a modeler modifies what a metric represents, they need to see how that reflects on the user base.
3. Integrate more across the full flow of data - from sources to target tools, to help data teams understand better how their semantics and data are being used.

Last but not least, we are also exploring ways for teams to build semantic layers faster - by leveraging AI to to extract semantics from existing sources, whether they are SQL queries, wiki pages or BI reports.

An exciting year is ahead of us!

Happy New Year,

Team Honeydew


## Blog: How we teach data to an LLM
URL: https://honeydew.ai/blog/how-we-teach-data-to-an-llm/
**Introduction**

How many times did you hear thoughts like “You just connect an LLM to the data and you can ask it whatever you want!”, “AI is so smart that you just connect it to your data and it would understand and generate the queries for you!” or my favorite “Its magic, you plug the AI to the data and it does everything for you!”.

Sounds fantastic, right? But if you’re reading this, you likely know by now that the [reality isn’t so simple](/blog/talk-to-your-data-loudly/). Connecting an LLM to your data and expecting instant results isn’t a “plug-and-play” scenario.

As much as I’d love to live in a utopian world, I’m a pragmatist (aren’t we all?). The truth is that AI, no matter how sophisticated, doesn’t automatically understand your database schema, relationships, or nuances. Why? Because it lacks **context.**

“So, let’s give it context!” you might think. But here’s the catch: this often leads to constant prompt adjustments, an unstable system, and a lack of trust—both from you and your stakeholders. Sound familiar? You’ve probably poured months or even years into this dream, only to feel like it’s slipping away.

Let’s shift gears and focus on what **does** work.

How do you teach your data to your AI? Or in other words, how do you ground AI in the context of your business and your data?

The technical part of the solution is a semantic layer as the place to keep the context. However, before technicalities what important to understand is the process.

There is one major concept underpinning teach AI with a semantic layer: Treat it like an **inexperienced analyst** you’ve just hired.

As a manager you have practical toolbox to be used (or give the hire) to onboard the new hire, and an agenda that leads your approch. The same teaching tools apply to when thinking of a semantic layer such as Honeydew as a framework for context.

### **The Approach: Start Simple, Then Build**

When onboarding a new analyst, you wouldn’t hand over the entire database schema on day one, would you? Of course not. You’d start small, gradually exposing them to more information as they gain confidence and expertise. The same methodology applies to training your LLM.

### **1. Simplify the Schema**

Think of the data as one single table - at first you do not wish the analyst to understand the entire schema and relations between tables, for simplicity you can tell him “think of it as on single table with attributes and metrics”. Furthermore, avoid exposing foreign keys, complex joins, or internal attributes.

Focus only on **metrics** and **attributes** that a business user would directly reference.

- Tools like Honeydew can handle the lineage and dependencies behind the scenes, so the AI doesn’t need to worry about those complexities (or god forbid write complex SQL queries !)

### **2. Avoid Ambiguity**

Just as you wouldn’t confuse an analyst with unclear terminology, don’t confuse your LLM. If the analyst sees metrics or attributes with similar names he would necessary know which one to use and come ask you, right? Steer clear of similarly named attributes or metrics unless you clearly define their meanings.

### **3. Incremental Exposure**

Start small: Prepare 15–20 business questions, beginning with simple ones and gradually increasing complexity. Expose the AI to new metrics and attributes step by step, expanding its “domain” over time.

### **4. Handle Uncertainty**

Such as you would instruct the analyst to ask question and not jump to conclusion the same with the AI: Include an explicit instruction in the prompt for the AI to declare when it doesn’t know the answer. (No hallucinations allowed!)

### **Your Semantic Layer Toolbox for LLM to data Training**

In Honeydew, these are the tools and techniques that will help you “train” your AI:

1. **Domain Creation**

- Use [Domains](/docs/domains) to define a focused subset of metrics and attributes.
- Start with a small domain and gradually add attributes and metrics as you gain confidence the AI answers all the business questions.

2. **Metadata Descriptions**

- Leverage [metadata](/docs/governance/metadata) to provide clear descriptions of metrics and attributes.
- Include synonyms or create derived metrics with multiple names to handle varied phrasing.

3. **Time Management**

- Provide a [time spine](/docs/advanced-modeling/time-spines) to ensure consistent date handling.
- Use [time metrics](/docs/advanced-modeling/time-metrics) to establish correct relationships between time and metrics.

4. **Example Questions**

- For extremely complex queries, use dynamic [datasets](/docs/dynamic-datasets) with explicit descriptions. But don’t overload the AI with these—it could lead to confusion.

### **Wrapping Up**

Treating your AI like an inexperienced analyst doesn’t just make the process smoother—it also spares you from countless headaches (and possibly a few existential crises).

With the right tools, a clear approach, and a little patience, you’ll turn your LLM into the most efficient, non-coffee-drinking, non-vacation-taking team member you’ve ever had.

Now go forth, teach your AI, and remember: if all else fails, just blame the “new hire”! 😉


## Blog: Excel is the Best BI Tool, and It’s Not Going Anywhere – Just Ask Your CFO
URL: https://honeydew.ai/blog/excel-is-the-best-bi-tool-and-its-not-going-anywhere-just-ask-your-cfo/
Over my career as a Director of Data and BI team lead, writing blog posts has never been in my comfort zone. I thought I’d give it a try because what I’m about to share is something everyone in the data space needs to hear.

Just like I’m not fully comfortable writing blog posts, many end-users or clients in data departments aren’t thrilled about adapting to modern BI tools like Looker or Power BI. For many, their old and trusted companion — Excel — remains their go-to tool.

I’ve witnessed firsthand the struggles analysts face when delivering insights to end-users who prefer Excel over more dynamic BI tools. This got me thinking — writing this blog post isn’t all that different from how data teams approach legacy tools.

### The Struggle is Real: End-Users vs. New Tools

For me, when I write, I go to ChatGPT. Likewise, I see data end-users gravitate toward their tried-and-true too - Excel. And just like me, they run into obstacles.

Imagine a CFO and his team using Microsoft Excel. As demand for data grows, its limitations become painfully clear:

- **Disconnected Data**: Excel data exists in the Excel file. It only changes when someone updates the file, for example by copying a data extract from an external system like a CRM.
- **Opaque Sources:** Where did that number come from? No one knows. Once data is copied or entered into an Excel sheet, its source is lost.
- **No Workflow**: Collaboration and data conflict resolution between Excel files is virtually impossible. Data decisions, like how to filter for a specific customer segment, can’t be deployed easily into Excel sheets, and no source of truth is possible.

The CFO doesn’t care about these limitations. The source data is in Snowflake but training the team on a “better data system” using it, whatever that may be, is not something he seeks. All he sees is an Excel report that isn’t right.

### Meeting Demands with Power BI?

When the CFO faces this issue, he quickly sends an urgent, disappointed email to the analyst, expressing frustration about not having immediate access to the data. Sound familiar? If you ask around my office, you’d hear the same about me and my complaints about writing this blog post!

The analyst, responding swiftly, loads his data from Snowflake to a report and sends the CFO a Power BI dashboard that was already built. Problem solved, right? Well, not quite.

The CFO, after a glance, still has follow-up questions. He tries to modify the Power BI dashboard but after 15 minutes, gives up and returns to the analyst, saying, “I need more flexibility! I don’t know how to use this tool!”

Now, the frustrated analyst has to sit with the CFO for half an hour, understand his specific requirements, then head back to his desk to create a pivot table in Excel. It’s as if I, after struggling to write this post, had to return to ChatGPT for rewrites.

### Just Connect it to the Cloud?

Throwing hands in air, the analyst builds up a new solution. Connect the team’s Excel to a cloud data warehouse. Let the CFO team build Pivot Tables in the tool they love, and refresh the data when they need it.

The next day, the CFO tries to refresh his Excel report to get updated data. In theory, it should work. But the CFO, being an early bird, tries to refresh it during a data extraction process. Naturally, the refresh fails.

A call to the analyst on his way to the office results in the dreaded response: “You’ll need to wait 45 minutes for the extraction to finish.”

Disappointed, the CFO makes his second cup of coffee and expresses his frustration to the head of the data team, who patiently listens to these all-too-familiar complaints. By now, the extraction is complete, and the Excel refresh works.

However, during a board meeting later that day, the CFO presented his Excel report, only to find that the numbers didn’t align with the CMO’s data from the Power BI dashboard. Frustration all around.

### The Real Issue: It's Not the Tools, It's the Workflow

When the numbers presented in Excel don’t match those in Power BI, the head of data realizes: it’s not the tools causing the problem—it’s how they’re being used.

But can we really teach the CFO to use Power BI? And is it worth the time and effort?

This is where the analogy comes full circle. Just as I struggled to write this blog and had to turn to ChatGPT for help — only to realize I needed my personal touch to write something I would also like to read — data teams face the same challenges with legacy tools like Excel. The tools we’re familiar with may not always fit our current needs, but instead of discarding them, we need to find ways to integrate them more effectively into modern workflows.

### The Solution: Honeydew

Enter [Honeydew](/). Honeydew bridges the gap between old and new by integrating Excel seamlessly with Snowflake. Honeydew’s API allows live queries in Excel, translating them into SQL based on a semantic model that ensures consistency across all reports. Here’s what it offers:

- **No More Downtime:** The CFO doesn’t have to wait for data extraction, as live queries pull real-time data directly from Snowflake.
- **Consistency Across Tools:** Whether it’s Excel or Power BI, the numbers are always aligned, thanks to the centralized semantic model.
- **Shorter Path to Insights:** Analysts can deliver flexible, reliable reports faster, eliminating unnecessary back-and-forths.

Just like how I had to sit down and put my own thoughts into this blog post, analysts need tools like Honeydew to make data flow smoothly in Excel — without reinventing the wheel.


## Blog: Where to build business logic on Snowflake: a PowerBI case study
URL: https://honeydew.ai/blog/where-to-build-business-logic-on-snowflake-a-powerbi-case-study/
In his article "Where to Build Business Logic on Snowflake: A PowerBI Case Study," David Krakov explores the trade-offs between different BI architectures using Snowflake: affecting cost, performance, modeling, and governance. This article explores these trade-offs using PowerBI as a case study.

To learn more, you can read the full article in the following [link](https://medium.com/snowflake/where-to-build-business-logic-on-snowflake-a-powerbi-case-study-6c45079ab86f)


## Blog: Talk to Your Data (Loudly)
URL: https://honeydew.ai/blog/talk-to-your-data-loudly/
_How do you talk to your data?_

A question that not too long ago, when said out loud, would make people look at you funny and move to the opposite side of the subway car. It’s real now.

Why would you talk to your data? Because, in an enterprise, data holds useful answers to get better with sales, marketing, supply management, or hiring practices. The average Joe manager can use a useful answer! But Joe will not write a SQL query. Joe can ask an analyst - but if possible, Joe would prefer to just talk with the data.

So, how do you talk to your data?

LLMs (generative AI, but I’ll say LLMs) can understand an English question. They can also write SQL for Joe’s question - many, many, [many](https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=text%20to%20sql&sort=byPopularity&type=story) people are working on this. It works. Mostly.

But what if there is another way that makes talking to data 100x better? And a different place to apply an LLM-generating SQL than on the business end of a user question.

## Hard Truths and Soft Decisions

Speaking of ways and places, let’s talk about Waze.

I like Waze a lot. I’m not a San Francisco native, which is why I recently had the misfortune to agree to an afternoon meeting in Pleasanton, California because it is “close by”.

Dear reader, never ever do that.

![Pleasanton, CA afternoon](/assets/blog/talk-to-your-data-loudly/pleasanton-ca-afternoon.png)

_Pleasanton, CA afternoon_

But if you do, Waze gives you the feeling you’ll get there. Eventually.

When Waze chooses a way, its guidance is _probabilistic_ - there are multiple ways to get from SF to Pleasanton. Some ways are faster, some are slower, and some [have a higher chance of getting shot](https://www.ktvu.com/news/interactive-map-a-look-at-bay-area-freeway-shootings). Waze tries its best, and we trust it to.

However, whether you reached Pleasanton, CA or not is binary. If you look around and see [cowboys](https://www.pleasantontx.gov/), you are probably not there. Location is a hard truth. The probabilistic Waze relies on other hard truths, like roads. You can only drive on roads (that is, unless you are [LBJ](https://slate.com/human-interest/2013/03/lyndon-johnson-drives-in-a-lake-in-his-amphicar-photo.html)).

Not following the hard truths leads people to lose trust in probabilistic machines. You drive a person into a lake _just once_, and it’s [all they remember](https://www.theguardian.com/travel/2023/aug/09/apple-maps-cycling-transport-google).

LLMs are probabilistic machines too - like Waze, they try to do their best. They are much smarter than Waze! You can ask an LLM not only how to get to Pleasanton but also suggest sightseeing along the way (just don’t ask for the [shortest path visiting all stops](https://en.wikipedia.org/wiki/Travelling_salesman_problem)).

LLMs can write anything, including SQL.

Which is why, this architecture of talking to data is so promising:

![](/assets/blog/talk-to-your-data-loudly/talk-to-your-data-loudly-fig-1.png)

_A simplified “Talk to Data” architecture: User asks a Business Question → LLM generates SQL → Data. The metadata provides context such as table names._

But what are the hard truths of data? What “roads” does it need to follow?

## Hard Truths of Data

The basics are fairly simple:

- Where tables are located and what are the column names
- Does the SQL compile or not

But if your SQL compiles and uses the right data, it does not make it _right_.

A marketing manager using Google Analytics looks at the number of users,

![](/assets/blog/talk-to-your-data-loudly/talk-to-your-data-loudly-fig-2.png)

_A Google Analytics Dashboard from [analytics.google.com](http://analytics.google.com) that shows 885 active users and 831 new users_

When Google Analytics data flows into Snowflake, and the marketing manager asks an LLM about data on the same date range, she would expect to see 885 active users and 831 new users. That’s her hard truth.

When she asks “How many people visited our website this weekend?”, she would love the AI to pick up that she meant a metric like “active user count” or “new user count”, or understand what “this weekend” means.

The choice of how to answer this question is _probabilistic -_ she did not indicate whether she meant new, active, or total users. Any choice is “correct” - though some are better than others.

But then, if the AI picked up “Active Users”? That is either right - or wrong. There is no “almost”.

Mind you, the definition of how to [count new or active users](https://support.google.com/analytics/answer/12253918?hl=en#:~:text=An%20active%20user%20is%20any,event%20from%20an%20iOS%20app) in Google Analytics is far from simple. It takes into it a notion of what is an “engaged session”. It distinguishes between activity on a website or an Android app. If you have a table with Google Analytics events, building that SQL correctly is not a small feat. Training an AI to do it right _every time?_ Harder.

And then, definitions can change overnight. When that happens, _all_ questions that use the old definition must use the _new_ one. Even if AI picked up on the old one after enough training to be mostly correct, it needs to forget its training at once and start again.

This is why we’ll talk about the way to set hard truths for data: Semantic Compilers.

![](/assets/blog/talk-to-your-data-loudly/talk-to-your-data-loudly-fig-3.png)

_An “Talk to Data” architecture with a hard truth layer: User asks a Business Question → LLM generates a Semantic Query → Semantic Compiler generates SQL → Data._

## Job Of A Semantic Layer

Imagine the following flow:

1. Define a metric (like active user count) in metadata: how it is calculated, where its data comes from, and how it is connected to other pieces of data like dates. That's a _Semantic Definition_.
2. Query it (”active user count where date = this weekend”) from some user tool. This is a _Semantic Query_. It does not concern itself with the how, only with the desired result.
3. The _Semantic Compiler_ gets the semantic query and compiles an actual SQL statement for it.

A semantic definition encodes the _hard truths_: what do you mean by “count active users”. A semantic compiler uses that definition to answer a question. An LLM (or a BI tool) asks the question. Together, they form a [semantic layer](/blog/so-lets-talk-about-semantic-layers/).

With a semantic layer, a user says

```
<code><span style="background-color: initial; font-family: inherit; font-size: inherit; color: initial;"></span>
```

An LLM chooses an active_users_count metric and makes a semantic query like

Semantic compiler gets this and says

In the context of LLMs generating SQL, Semantic Compilers deal with the “hairy stuff” of data generation such as:

- **Correct Metrics:** know when and how to aggregate. Deal with derived calculations, with levels of granularity of aggregations, handle edge cases of ratio calculations, and understand additive and non-additive metrics.
- **Correct Joins:** correctly connect data. Deal with multi-hop joins or duplicate rows. Avoid [fan traps and chasm traps](https://showmethedata.blog/sql-traps-unified-star-schema) to avoid wrong results or data explosion (surprisingly hard!).
- **Correct Dependencies:** understand calculation lineage and know how to apply context between steps. Understand pre-aggregations and when they can apply.
- **Correct Time:** understand time spines and handling missing data, know how to join dates to data, or how to construct a year-over-year or a year-to-date metric.
- **Performance**: filter pushdown, join pruning, leveraging pre-aggregated data (and knowing it is valid), balancing cost and flexibility.

And with less context to process, the LLM is cheaper too!

Or in practice,

![](/assets/blog/talk-to-your-data-loudly/talk-to-your-data-loudly-fig-4.png)

_Honeydew’s Semantic Layer with Cortex LLM on a Google Analytics Semantic Model_

## The User Perspective

When Joe asks a question from this “AI” black box that now has a semantic compiler, Joe gets the following advantages:

### **Correctness and Accuracy**

The [best Text-to-SQL systems](https://paperswithcode.com/task/text-to-sql) achieve **~80%** accuracy on test benchmarks. With larger real-world schemas (over 100 business objects or 20 tables) accuracy [drops considerably.](https://www.scitepress.org/Papers/2024/125552/125552.pdf)

Most text-to-SQL evaluations don’t distinguish between accuracy and correctness (as long as the SQL compiles).

However, with a semantic layer (such as Honeydew), it is possible to achieve **100%** correctness and >**95%** accuracy with >10,000 business objects and any (unbounded) number of tables underneath.

Correctness is a given: a semantic compiler will always produce correct joins and metric calculations. Accuracy with a semantic layer means a different thing: choosing the appropriate metrics for a user question. Inaccurate = you meant active users, but the LLM picked total users.

### Explainability

When you get a number, how do you know it is wrong?

Text-to-SQL LLM that generates a wrong calculation escapes scrutiny: many times it is impossible to notice a wrong result in a complex SQL, even for an expert eye. For business users blindly trusting numbers (until they don’t!) it is beyond realm of imaginable.

It is easy though to know when an AI picked a wrong metric: it has a name. Oh, total users? I meant active users. No, not _this_ weekend, I meant _last_ weekend. It uses the same language as the business user, allowing corrective instructions to the LLM.

But with an LLM generating SQL directly, even if the user smells a wrong answer, there is no direct way to provide guidance at that level.

### Time to Value

A semantic model (such as Google Analytics) is repeatable. Build it once, and every Google Analytics data will conform. The particular business context of using Google Analytics in a specific company is unique - different companies care about different things and correlate a website visit with different pieces of data.

With a semantic model, you only need to worry about training for your particular business context (where “training” essentially means expanding the semantic model). The baseline is a trusted and a “hard truth” to adjust to your needs while maintaining full control of it.

## The New Job of a Data Team

Data teams with semantic layers are the Department of Transportation. They maintain the roads. They put a warning sign around road construction, directing traffic to a bypass. They close dangerous bridges that lead into lakes, and redraw bad maps that point there. They figure out where there is congestion and design better roads. They understand which road signs are misleading. They know which traffic lights are annoying. They are Waymo’s [maps](https://waymo.com/blog/2020/09/the-waymo-driver-handbook-mapping/) [team](https://www.theverge.com/2019/10/7/20903034/waymo-self-driving-test-la-mds-data).

In short, you can’t drive anywhere without them.

![](/assets/blog/talk-to-your-data-loudly/talk-to-your-data-loudly-fig-5.png)

_Elevated road junctions in Cincinnati, OH (photo by Kelly Lacy)_

The data team's first job in the world of AI is to maintain the hard truth.

Knowing data, they might give good suggestions on how to use it - ask them about the best way to get from point A to point B and they’ll know how to answer. Sometimes better than AI. But if they maintain the roads right, you don’t have to ask them. You can use Waze. Or an LLM.

But they are also the ones who need a SQL-making LLM!

In the very immediate term, they can write SQL faster:

![](/assets/blog/talk-to-your-data-loudly/talk-to-your-data-loudly-fig-6.png)

_SQL co-pilot that works well: help a SQL developer write more SQL._

## The New Job of SQL-generating LLMs

LLMs can help data teams design better roads. It can help them build a better semantic model, faster.

1. One LLM helps data teams design roads (by helping them build new metrics and calculations).
2. Another LLM helps business users drive the roads (by using those metrics to answer questions).

In combination, there can be accuracy at scale, explainability, and control.

Will both those steps converge in the future, until the gap in between is so tiny you hardly see it? With AGI, they might.

But as long as there is a gap and a semantic model to review and rely on, there are hard truths - and people, talking to their data out loud.


## Blog: Strategic Decisions in Data Reporting : where to build metrics?
URL: https://honeydew.ai/blog/strategic-decisions-in-data-reporting-where-to-build-metrics/
Adam Morton met David Krakov, Honeydew’s CEO, and talked about… well… semantic layers 🙂

One of the first questions we ask in discovery calls is where the metrics reside. Data teams build metrics in ETL, during ingestion, in BI, or in a semantic layer. Choosing where to build your metrics isn't just a technical decision; it's a strategic one - and definitely part of this balance between creating flexible reports and maintaining consistency.

You can read Adam’s [newsletter](https://www.linkedin.com/pulse/future-reporting-adam-morton-ijqfc/?trackingId=lnU2ThAlRDGm%2BjrNwyECPw%3D%3D) or just watch the [video](https://www.youtube.com/watch?v=r9hU6XY8kGU&t=1746s) where Adam and David discuss the semantic layer challenge in more depth with a demo of Honeydew.

## About Adam Morton

Adam Morton is an experienced data leader and author in the field of data and analytics with a passion for delivering tangible business value. Over the past two decades Adam has accumulated a wealth of valuable, real-world experiences designing and implementing enterprise-wide data strategies, advanced data and analytics solutions as well as building high-performing data teams across the UK, Europe, and Australia.


## Blog: On the value of Expressiveness in Semantic Layers
URL: https://honeydew.ai/blog/on-the-value-of-expressiveness/
ccasionally (ok, **very commonly**) I find myself in a conversation comparing different Semantic Layers.

And while many times the conversation veers towards the fundamentals like performance, cost, or tool support, I think there is one crucial component lacking.

## ex·pres·sive·ness

_noun_

1. the quality of effectively conveying a thought or feeling. "you will be floored by the expressiveness of her eyes"

(source: Oxford Languages. They give expressive examples.)

What is the Expressiveness of a Semantic Layer and why does it matter so much?

![](/assets/blog/on-the-value-of-expressiveness/on-the-value-of-expressiveness-fig-1.png)

Let's get some semantics (hah!) out of the way:

A semantic layer captures how you calculate a thing. Like the quarterly revenue, or the daily user count. In miniature, it’s just a person who knows how to do it. However, when you scale, an _enterprise semantic layer_ is a tool.

That tool can be hand-written scripts in SQL, dbt models, no-code ETLs, a metric layer, a traditional BI (such as SAP Business Objects, IBM Cognos or Microsoft Analysis Server), or pure semantic layers such as AtScale. Anything where shared business logic sits. It can even a multi-billion balance sheet done entirely in [Excel](https://sambf.substack.com/p/ftx-pre-mortem-overview?utm_source=profile&utm_medium=reader2) (**don’t**).

The tool can help many people be effective: business users working towards a KPI, data analysts trying to predict it, data engineers piping data for it and executives choosing between trusting data and trusting their guts. It powers dashboards, notebooks, applications. Look under any action taken by a business you admire on how it uses data - there is a semantic layer peeking.

It’s better be good.

## Expressiveness, explained.

What is the “_Quality of Effectively Conveying a Thought_” of an enterprise semantic layer?

_Effective vs ineffective communication of allowed parking times. Source: LA Mayor's office._

_Effectively Conveying_ is about the effort needed to say something. If you convey a thought effectively you don’t do a lot of talking until someone understands. Take a look at the parking times above. One is faster to understand.

**_Quality of Effectively Conveying_** is about **_what can you say_ _effectively_**. Is it possible to describe a concept a short way? Do you even have the words needed to describe it in a precise way?

The LA picture above conveys allowed parking by the time of the week _very effectively_.

But, alas, it can’t effectively convey anything about the type of the vehicle, the passenger, the weather. In Florida, that might be a problem. After all, how do you tell that one must pay a meter when [parking an alligator or an elephant](https://www.spatzlawfirm.com/blog/2019/09/10-weird-laws-in-florida-you-probably-dont-know-about/), but not when parking a giraffe?

## Applied to Semantic Layers

People build and use semantics in semantic layers (that is, until [AGI takes over](https://en.wikipedia.org/wiki/AI_takeover). We got [a decade or so](https://www.metaculus.com/ai/)).

You may have someone that [knows everything about your data](/blog/so-lets-talk-about-semantic-layers/) and SQL. She can answer any question armed with just a query editor between her teeth.

But semantic layer serve lots of people. We need to consider what the _average data user_ can do with it, not the all-knowing **_Uberanalytiker._**

Apply the concept a semantic layer and ask:

1. _How much skill and tribal knowledge does it take to encode an idea?_ If only a few people have enough skills, then a semantic layer is less expressive.
2. _Which words (semantic constructs) does it have to express an idea?_ If the semantic layer makes it hard to build that metric you want, then it is less expressive.
3. _How easy it is to understand what you meant?_ If the semantic layer is akin to deciphering Egyptian hieroglyphs then is less expressive.
4. _What kind of new words can you build with it and reuse?_ The more you have to repeat yourself, the less expressive it is.

A very expressive semantic layer is one many people can say a lot of stuff with, and many people can understand. A not-so-expressive semantic layer is one where only a few can.

By the way, did I mention the expressiveness of a semantic layer can be _negative_? It’s the one semantic layer no one can change nor understand - but everyone has to rely on.

![](/assets/blog/on-the-value-of-expressiveness/on-the-value-of-expressiveness-fig-2.png)

## Forget cost, performance, and reliability

(ok, maybe not reliability)

> **If a semantic layer is not expressive enough for your business domain, the cost of maintaining it can outweigh any business benefits it can provide.**

Run the numbers. Take two semantic layers: fast, reliable, and reasonably priced. But differ in expressiveness.

**Low expressiveness**: only a few (engineers) can use it effectively, and it takes them time.

If your 100 business users ask for one change a day, and a change takes an engineers day ($1000) to design, build, test, and deploy: maintaining the semantic layer would cost **$20m/year**.

**High expressiveness**: most changes don’t need an engineer, and when they do, it’s easy.

If your 100 business users ask for one change a day, but only 10% of those need an engineer, and it takes just an hour, then maintaining the semantic layer would cost **$250k/year**.

Expressiveness matters.

## But don’t forget the business domain

Business domain and expressiveness are related: the same semantic layer capabilities can cover fully one business domain (making it expressive within it) and fail miserably on another (making it a hard-to-use pile of mess). Sometimes can make a reasonable guess based on capabilities. Often, the only real way is to try and find out.

## Examples!

**Negative Expressivess Semantic Layer:** No one can change it, or explain what it does.

That is, except for the rare pockets of sanity colloquially known as “Someone’s Job Security”.

Example: 1000 scattered scripts in 12 different languages, some of them dead, and one of them is processing crucial data from an AS/400 and uploading it to an FTP server via an obscure VBScript running in a Windows 95 machine that no one knows where it physically is, but it seems to be connected to the network somewhere in Building 5. Please no one touch that building.

It powers reports everyone relies on, but you [really hope it does not break up](https://time.com/4348494/pentagon-nuclear-floppy-disks/). If you get unlucky and have to fix it, the cost runs up into $Ms spent and years of clean up.

**Low Expressivess Semantic Layer**: Few people can change it, or explain what it does.

Example: [lots of SQL](https://forums.sqlteam.com/t/very-long-sql-query-with-lots-of-complex-calculations-and-conditions/15872).

Or, a best-case scenario: a 1000 well-organized dbt models that are managed by a strong analytics engineering with a library of Jinja Macros and an affinity for continuous integration.

The organization gets the consistency and integrity of data the semantic layer provides. But the maintenance can get costly. The more complex the lineage gets, the changes are dependent on high-end analytics engineering work.

**High Expressiveness Semantic Layer**: Many people can build on it and change it.

When a good enough semantic engine is coupled with a business domain that fits it.

Examples: [Airbnb Minerva](https://medium.com/airbnb-engineering/how-airbnb-achieved-metric-consistency-at-scale-f23cc53dea70); A well-done [Looker Explore](https://cloud.google.com/looker/docs/best-practices/how-to-create-a-positive-experience-for-looker-users); A well-designed [SAP Universe](https://michaelwelter.wordpress.com/2016/02/02/universe-design-best-practices/).

Or, on Snowflake, a [Honeydew](/) 🙂 (due disclosure: I am a co-founder of Honeydew).

## Expressive Power to the Win

Cost, performance, reliability, integrations, are all valid ways to compare semantic layers.

However, we need one more. And as a nerd, I like best the Computer Science [definition](<https://en.wikipedia.org/wiki/Expressive_power_(computer_science)>). It calls this concept **expressive power:** the expressive power of a language is the breadth of [i](https://en.wikipedia.org/wiki/Idea)deas that can be represented and communicated effectively in that language. The more expressive a language is, the greater the variety and quantity of ideas it can be used to represent well.

I like this definition because of the word power.

The term “expressive power of a semantic layer” conveys - and must say its does so with a high quality and effectively - the idea that having an expressive semantic layer is very **powerful**.

It is.


## Blog: Why did we build a Native App for Honeydew Semantic Layer on Snowflake?
URL: https://honeydew.ai/blog/why-did-we-build-a-native-app-for-honeydew-semantic-layer-on-snowflake/
## Introduction

Semantic layers are [awesome](/blog/so-lets-talk-about-semantic-layers/). But they are even more awesome when they are tightly integrated into your Snowflake, and right at your fingertips in your Snowflake Web Interface or Snowflake application.

Enter … 🥁

The Honeydew [Native App](https://app.snowflake.com/marketplace/listing/GZTSZ14KQ9/honeydew-semantic-layer).

## Our users demand a semantic layer in their Snowflake Workbooks

A semantic layer serves many purposes: it enables data democratization, provides consistency, ensures governance, and saves countless hours of engineering. With a semantic layer, analytics engineers can enjoy a weekend, and business users can trust a dashboard.

Users access our semantic layer with a to ol of their choice: their Looker, Tableau, Jupyter, or even DBeaver. But, alas, one very important tool was left behind: the [Snowflake Web Interface](https://docs.snowflake.com/en/user-guide/ui-snowsight), Snowsight.

No one likes switching tabs.

With a Native App, there is no need.

## Applications built on Snowflake want a semantic layer

Snowflake enables [building applications](https://www.snowflake.com/en/data-cloud/workloads/applications/) powered by the Data Cloud. Many of those applications include custom-developed query generators, to bridge between application code and the data warehouse. For an application developer, a semantic layer is a query generator on steroids: it understands data structure and relations and can construct correct fast queries for ad-hoc needs.

But how to integrate it into an application? Right, the Native App.

The Native App encapsulates and secures access to the semantic layer by any means of connection to Snowflake: [JDBC](https://docs.snowflake.com/en/developer-guide/jdbc/jdbc), [ODBC](https://docs.snowflake.com/en/developer-guide/odbc/odbc), [Node.js](https://docs.snowflake.com/en/developer-guide/node-js/nodejs-driver), [PHP](https://docs.snowflake.com/en/developer-guide/php-pdo/php-pdo-driver), [Go](https://docs.snowflake.com/en/developer-guide/golang/go-driver), [.NET](https://docs.snowflake.com/en/developer-guide/golang/go-driver), or [Python](https://docs.snowflake.com/en/developer-guide/python-connector/python-connector). A semantic layer on Snowflake can now be used to generate queries from any application built on Snowflake.

## More security

Snowflake provides user management, access control, encryption, and network separation for every query and connection. Organizations invest in security design ensuring sensitive or private data is always protected.

Now with a Native App, the semantic layer gets the same protection of the Snowflake environment. The access to it is confined to the Snowflake connection, whether it comes from Snowsight or any other Snowflake client.

## What can the users do with the Honeydew Native App?

The Native App provides access to the Honeydew semantic layer:

1. **Business metadata** for governance and cataloging, such as metrics and relationships.
2. **Query generator** for ad-hoc data access based on shared semantics.
3. **Management APIs** for automation and management purposes.

A few examples are below - covering just a small part of its abilities!

### Metadata access to shared semantics

List the available semantic entities in a workspace:

```sql
select name from table(HONEYDEW_APP.API.LIST_ENTITIES('tpch'));
```

![](/assets/blog/why-did-we-build-a-native-app-for-honeydew-semantic-layer-on-snowflake/why-did-we-build-a-native-app-for-honeydew-semantic-layer-on-snowflake-fig-1.png)

Explore the relations between different entities, to see how they are connected:

```sql
select source, target, type, connection from table(HONEYDEW_APP.API.LIST_RELATIONS('tpch')) where source = 'orders';
```

![](/assets/blog/why-did-we-build-a-native-app-for-honeydew-semantic-layer-on-snowflake/why-did-we-build-a-native-app-for-honeydew-semantic-layer-on-snowflake-fig-2.png)

Find all metrics that are related to “revenue”:

```sql
select name, entity, sql from table(HONEYDEW_APP.API.LIST_FIELDS('tpch')) WHERE TYPE = 'Metric' and NAME LIKE '%revenue%';
```

![](/assets/blog/why-did-we-build-a-native-app-for-honeydew-semantic-layer-on-snowflake/why-did-we-build-a-native-app-for-honeydew-semantic-layer-on-snowflake-fig-3.png)

### Data access powered by shared semantics

One of the advantages of using the Honeydew Semantic Layer on Snowflake is that the users do not have to worry about how to join tables while querying data.

Just combine attributes and metrics, and the Semantic Layer will generate the right query:

```sql
select HONEYDEW_APP.API.GET_SQL('tpch', 'select "orders.order_month" as order_month, AGG("customers.count") as customers_count from world.world order by order_month asc');
```

<video
  src="/assets/videos/honeydew-product-demo-video.mp4"
  controls
  preload="none"
  class="w-full"
></video>

Users can also run the generated query directly in Snowflake, and put the results in a transient table. Then that table can be used to build subsequent analysis steps.

```sql
call HONEYDEW_APP.API.RUN_SQL('tpch', 'select "orders.order_month" as order_month, AGG("customers.count") as customers_count from world.world order by order_month asc', 'customers_by_month');
select * from HONEYDEW_APP.QUERY_RESULTS.customers_by_month where year(order_month) = 1997;
```

<video
  src="/assets/videos/honeydew-product-demo-video.mp4"
  controls
  preload="none"
  class="w-full"
></video>

#### I only use Tableau/ Looker/ PowerBI - do I need the Native App?

Nope. The Honeydew semantic layer works without it as well, [securely and reliably.](/blog/honeydew-soc-2-announcement/)

However, the native app benefits few scenarios:

1. Using the semantic layer directly from Snowsight, the Snowflake Web Interface.
2. Using the semantic layer from full-stack application code built on Snowflake.
3. Using the semantic layer where security policies are highly custom and conservative, such as in government environments.

## Semantic Layer becomes a native platform capability

This Honeydew Native App integration allows organizations to embed a semantic layer deeper into Snowflake, making it a native platform capability.

Users can access the semantic layer directly within the familiar Snowflake environment, enhancing their productivity and efficiency. The native app helps streamline data security management, ensuring that only authorized users can access and analyze sensitive data. Additionally, Honeydew enables users to create more complex workflows, leveraging the semantic layer as a single source of truth.

## Now what?

You can [install the Honeydew Native App for Snowflake](https://app.snowflake.com/marketplace/listing/GZTSZ14KQ9/honeydew-semantic-layer).

Or [talk to us to set up a demo](/get-started/).


## Blog: dbt Semantic Layer vs Looker LookML
URL: https://honeydew.ai/blog/dbt-semantic-layer-vs-looker-lookml/
Last month, dbt [announced](https://www.getdbt.com/blog/new-dbt-cloud-features-announced-at-coalesce-2023) the general availability of their Semantic Layer and Looker announced a preview of their semantic layer [Open SQL interface](https://cloud.google.com/looker/docs/sql-interface).

This is a good opportunity to compare the new universal semantic layer with the old “semantic layer of the modern data stack”: LookML.

## A semantic what?

A **semantic layer** is a single place to define common business concepts of data (such as what is a customer or how to count revenue).

Shared definitions can be re-used by different users in an organization, like a monthly KPI report, a data exploration done in Tableau, or a data science analysis. If you have a semantic layer, more data users get safer, easier, and more consistent access to data, as [many have said](https://benn.substack.com/p/metrics-layer) over the last few years (yours truly [included](/blog/so-lets-talk-about-semantic-layers/)).

This comparison covers different aspects:

1. The developer view: how easy is it to build
2. The analytics team view: how flexible it is
3. The engineer view: performance and maintenance
4. The CFO view: cost

### The basics: who are they

**dbt semantic layer** is a standalone layer shared by different tools. It comes from dbt’s [acquisition of Transform](https://techcrunch.com/2023/02/08/dbt-acquires-transform/?guccounter=1&guce_referrer=aHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS8&guce_referrer_sig=AQAAAAv5SCz1HA2zKV3MuHLJzS1iilY_WW95rfHw6ccDdSJEM9BGMLWHVdRcILt2NBPKIUZ8opNdPABGtmdmDZ5cTnSu18zVxcQ6thS_Mrdfwza_3EBsPl5_-HgeBqAWZE_69Omu6px9nWYddPx4gNmTqc7yigDeErxrRGyTSGqUSzvx) in early 2023. (dbt previously built something on their own and [scraped the effort](https://docs.getdbt.com/blog/deprecating-dbt-metrics))

![](/assets/blog/dbt-semantic-layer-vs-looker-lookml/dbt-semantic-layer-vs-looker-lookml-fig-1.png)

_(image: dbt website)_

**Looker** ([acquired by Google](https://techcrunch.com/2020/02/13/google-closes-2-6b-looker-acquisition/) in 2020) started as a BI tool bundled with a semantic layer called **LookML**.

![](/assets/blog/dbt-semantic-layer-vs-looker-lookml/dbt-semantic-layer-vs-looker-lookml-fig-2.png)

_(image: Google)_

However, recently Google moved **LookML** towards being a universal semantic layer: it has native integrations with Google Sheets, [Tableau](https://cloud.google.com/looker/docs/tableau-connector) and [PowerBI](https://cloud.google.com/looker/docs/powerbi-connector). The Looker Modeler provides integration with 3rd parties like [ThoughtSpot](https://www.thoughtspot.com/blog/looker-thoughtspot-connector).

Today, both dbt and LookML are a universal semantic layer: Users can use a BI tool like Tableau or a a data science notebook like Jupyter. Every tool will use the same semantics.

#### Integrations

dbt semantic layer supports GraphQL (an API), [JDBC](https://docs.getdbt.com/docs/dbt-cloud-apis/sl-jdbc), as well as [BI tools](https://docs.getdbt.com/docs/use-dbt-semantic-layer/avail-sl-integrations): Tableau (beta), Google Sheets, and a few smaller BI players such as Hex.

Looker supports REST (an API), [JDBC](https://cloud.google.com/looker/docs/sql-interface?hl=en), as well as BI tools: Looker (itself), [PowerBI](https://cloud.google.com/looker/docs/powerbi-connector?hl=en), Tableau (beta), Google Sheets. Support for non-Looker tools is limited today to data on BigQuery only.

In addition, Looker can deliver [semantics as a table](https://cloud.google.com/looker/docs/derived-tables#persistent_derived_tables_pdts) in the database (not limited to BigQuery).

**If your data is in BigQuery, Looker has more integrations. Otherwise, dbt would probably be a better choice.**

Note - the JDBC interface to common tools such as Tableau is in beta or public preview in _both_ dbt and Looker. So to be fair, might be better to wait to use either tool with JDBC in production use cases.

#### Development Experience

Productivity is a key metric when evaluating a semantic layer.

Who can maintain it? How easy is it?

Changes to semantics happen all the time, so it matters a lot whether they take an hour or a day.

Both Looker and dbt rely on text files in their own propriety format to define the semantic layer itself. They both can store those text files in a git repository, enabling versioning and code review.

Both of them include a cloud IDE to edit those files and to deploy results.

_The LookML developer experience_ is based on tight integration between the IDE (LookML) and a BI tool to explore its output. Changes in LookML reflect immediately in the BI, and logic built in BI can be easily exported into code. The IDE has auto-complete and contextual hints.

![](/assets/blog/dbt-semantic-layer-vs-looker-lookml/dbt-semantic-layer-vs-looker-lookml-fig-3.png)

_(src: LookML cloud interface screenshot, Nov 2023)_

_The dbt developer cloud experience_ is geared much more toward a developer mindset. The main API to test data is GraphQL queries that come from a command line tool or a web tool that speaks GraphQL. The development flow is based on a build-compile-deploy run with an IDE. The IDE has lineage and tabs. Changes to the semantic layer in the cloud IDE do not immediately reflect in tools connected to the semantic layer [^ note: this seems like a bug, not a feature].

The dbt semantic layer YAML has a steeper learning curve than LookML due to less instrumentation in the IDE - and due to having more complex concepts like entities or metrics. Most analysts will find the GraphQL API or the CLI tool very different from their experience of using BI or the experience of using SQL.

![](/assets/blog/dbt-semantic-layer-vs-looker-lookml/dbt-semantic-layer-vs-looker-lookml-fig-4.png)

_(src: dbt cloud interface screenshot, Nov 2023)_

**The winner is Looker** - having the ability to quickly “close the loop” and test a piece of logic with BI is a significant time saver. Furthermore, building directly in BI makes the semantic layer more accessible and easier to learn.

## Expressiveness

Expressiveness is roughly defined as “what can you easily say” with it.

The world of data in an enterprise is built of thousands of pieces of information - metrics, dimensions, entities, relationships. What is a user, or how is revenue counted?

One of the largest costs part of implementing a semantic layer is the cost of the team that maintains those pieces of information. An expressive semantic layer requires less work to maintain and less expertise to use right. Conversely, a less expressive semantic layer is a world full of pain and ugly hacks.

The differences between dbt MetricFlow and LookML are major: they speak different languages.

### _Relationships and Entities_

Most data does not sit in one table. It requires JOINs and understanding how different tables relate. Tables might represent business entities.

dbt has a global concept of “entity” that Looker lacks, which is a strong advantage and can help model data [well](https://benn.substack.com/p/entity-layer).

However, dbt entities have limited usability due to JOIN limitations:

- **Multi-hop joins**: What if to connect between two tables one needs to go through an intermediate join? This is a very common scenario in most database schemas: consider a 3 table schema of Customers → Orders → Payments. Looker can automatically resolve the join path between customers and payments (via orders). The dbt semantic layer [does not support multi-hop joins](https://docs.getdbt.com/docs/build/join-logic#query-multi-hop-joins), requiring pre-joining data before connecting it.
- **Fan-out joins**: How to count a metric that requires a join with row duplication? This a common scenario with one-to-many relationships (for example when a Customers table is joined with an Orders table, every customer is each order row). Looker supports some Fan-out joins with [Symmetric Aggregates](https://cloud.google.com/looker/docs/best-practices/understanding-symmetric-aggregates). The dbt semantic layer will fail a query that requires a fan-out join.

**The clear winner is Looker** - real-world data schemas (such as the Salesforce objects schema) are full of multi-hop or fan-out joins. (\*as well as relationships neither Looker nor dbt support). Not being able to model those reduces the value of a semantic layer.

### Metrics

The key language of data is metrics: how to count users or revenue.

Here is dbt semantic layer strongest advantage - dbt treats metrics as a re-usable component. Many types of metrics are easy in dbt and hard with LookML. Specifically:

- **Metrics counted in different times**: dbt allows to easily define for metrics which time column it they are counted on. For example, active users can be counted based on the last activity date while installations are counted based on the first activity date.
- **Metrics based on time offset**: dbt allows to easily define metrics such as “last month’s revenue”, for example to use for month-over-month growth
- **Cumulative metrics**: dbt allows to easily define metrics such as “total revenue so far”.

Those metrics can be defined in LookML but it can get tedious and complex (see for example the [8 ways to build a month-over-month metric](https://www.googlecloudcommunity.com/gc/Technical-Tips-Tricks/Methods-for-Period-Over-Period-PoP-Analysis-in-Looker/ta-p/587538)). Some of those Looker can only easily do it in a dashboard (called a “table calculation”), but not as a reusable metric.

**The winner is dbt** - complex metrics made easy.

## Performance

How much time would it take a query using the semantic layer to return?

Both Looker and dbt server generate queries that hit the database underneath. The overhead of the semantic layer is small (about a second in our tests of dbt), which means the performance is mainly based on two factors:

_Quality of generated queries - can the database execute the query fast?_

This is highly dependent on the quality of the query generator. Query generation is context-specific. Any fair comparison requires implementing the same business domain in both, which is not in the scope of this blog post 🙂. For the relatively simple queries we tried, dbt and Looker seemed on par.

_Which optimizations does the semantic layer offer?_

dbt semantic layer does not do any data processing of its own - all processing is done by the date warehouse underneath (such as Snowflake). So does Looker, by default.

However, Looker has two important strategies to improve performance:

1. [Aggregate Awareness](https://cloud.google.com/looker/docs/aggregate_awareness): maintaining and automatically using pre-aggregated tables.
2. [Caching](https://cloud.google.com/looker/docs/caching-and-datagroups): keeping query results and skipping the database when relevant

**The winner is Looker.** Aggregate awareness can deliver an order-of-magnitude improvement over querying tables directly. While it is possible to construct aggregated tables with plain dbt, it takes away from the flexibility of the semantic layer.

## Cost

Both Looker and dbt lack transparency on the cost aspects.

dbt: The semantic layer pricing model appears to be consumption-based. Prices are unknown.

The package offered today (Nov 2023) is bundled with a dbt cloud account ($100/ seat), and comes with just 1,000 [query units](https://docs.getdbt.com/docs/cloud/billing#what-counts-as-a-query-unit) per month (equivalent to a single dashboard with 10 metrics, refreshing 3 times a day). The pricing for a query unit has not been announced.

The code under dbt semantic layer is [source-available](https://github.com/dbt-labs/metricflow): it is open but not free.

Looker: Looker pricing model for Looker-as-BI is user-based, starting from $5k/ month. The Standard edition includes 12 users, and can scale up to 50 users for $60/standard user. Access with a 3rd party API is limited to just 1000 calls per month ($5 per call!), however, higher tier editions are more geared towards API usage. No public pricing is available.

In both cases, the direct cost of the semantic layer does not include:

1. The cost of the data warehouse processing - depends on the quality of generated queries.
2. The cost of data transfer - Looker has an advantage when data stays within.
3. Enterprise tier features, such as SSO or private VPC.

**There are no winners here, but there is an opportunity for dbt.**

IMHO, Looker requires a too-steep entry price for SMBs. However, its pricing model has a strong advantage: query as much as you want (\*as long as you use Looker to do it).

dbt’s approach (pay-per-query) might make more sense for a decoupled semantic layer. If they can keep it low and predictable for heavy workloads, they can have an advantage.

## Bottom Line

If you are on any other data source - dbt semantic layer is well worth a look; but be wary if your schema has many JOINs. It still has a way to go compared to what mature semantic layers such as LookML can do.

If all your data is on BigQuery - Looker LookML wins on most fronts: developer experience, expressiveness, performance, and integrations. It's almost a no-brainer.

If you are on Snowflake, check out [Honeydew](/).

## Honeydew Semantic Layer

Honeydew is a modern semantic layer native to Snowflake. Honeydew enables to decouple between semantics and the user tools that consume them.

There are a few distinct differences between Honeydew and dbt or LookML:

1. **User Tool Support: **Honeydew has a SQL API, enabling the reuse of metrics in any tool. It supports all the major BI tools (SaaS and On-Prem) - such as PowerBI, Tableau, and Looker.
2. **Complex Semantics**: Honeydew supports composable metrics, enabling to create complex logic with ease. Metrics can also be used to build data marts.
3. **Development Experience**: dbt and LookML are code-first. Honeydew's is multi-modal: Semantics can be edited in code by engineers (similar to dbt), in UI by analysts (similar to tools such as Tableau), and with API.
4. **Snowflake Native**: Honeydew is native to Snowflake in its integrations and way of operation, including how queries are generates and caches are managed.
5. **No Data Movement:** Honeydew operates in your Snowflake environment.

Want to know more? Set up a demo [any time](/get-started).


## Blog: Semantic layers are awesome
URL: https://honeydew.ai/blog/so-lets-talk-about-semantic-layers/
When is the last time you thought about water treatment plants?

Domestic wastewater treatment is an essential part of [modern city construction](https://www.ign.com/wikis/simcity/Sewage_Treatment_Plant) in a world of a rising population. But it can be so [boring](https://www.netsolwater.com/latest-innovations-in-waste-water-recycling-systems.php?blog=1324).

_So let’s talk about semantic layers._

## Your First Semantic Layer

When the company was small, you had this database. A few dashboards were attached on top, dutifully showing some KPIs: how many leads do we have? [are they good](https://www.forentrepreneurs.com/saas-metrics-2/)? [do they like us](https://www.netpromoter.com/know/)?

But the company grew, and with it, the databases, the dashboards, and the KPIs. Data is now so _messy._ Numbers misalign, answers are irrelevant, and the best source of truth is metrics_final3.xlsx . Everything is scattered, and everything is a Project.

So the company hires Eddie. Eddie has a beard.

Eddie’s task is to get the numbers to align. He hates disparate logic, so he builds a _script_. The script has many stages of SQL, and it generates Perfectly Fine Tables. The script knows how to join the data sources, what to filter out, and how to compute all the messy KPIs. There is no more chaos.

Your first semantic layer is not that script.

Your first semantic layer is Eddie.

### The Role of the Semantic Layer

A semantic layer bridges the gap between business and data. People who want to use data tend to ask questions like “why don’t we grow in Australia”, while data people `SELECT WHERE (country=61) AND (is_bot_score<0.1)` . If there is no way to jump across, the answer is 🤷.

A semantic layer allows everyone to use data. To do it, it must:

- Keep data consistent, so today’s 10 active users are still counted as 10 tomorrow.
- Keep data understandable, so when we say “active user”, we all know what it means.
- Keep data flexible, so when you want to count active users just in Australia, you can.

Eddie’s script is very consistent. But when you want to understand what it does, or when you want it to do something new, you ask Eddie and hope he writes in his script what you meant, and hope he likes you enough to do it soon.

The company’s ability to [use data](https://en.wikipedia.org/wiki/Data-driven) well to advance the business rests on Eddie’s shoulders.

Alas, as the stress mounts and the chaos keeps returning, Eddie had had enough. He leaves to pursue his childhood dream of growing apples in the [desert](https://www.gardeninginthedesert.com/how-to-grow-apple-trees-in-the-desert/). Now, not only there is no semantic layer, there is this _script_ full of dead code.

## Your Second Semantic Layer

Enter: Dana, a [Data Person](https://erikbern.com/2021/07/07/the-data-team-a-short-story.html). She brings a Snowflake, or a BigQuery, or a Redshift to get all the data in one place. She builds a coherent team of people who know SQL. She puts all that scattered logic in one place. It takes Dana a year, but she disentangles Eddie’s code, and the Excels and ad-hoc dashboards built on top of it while waiting.

She structures a team to serve diverse data demands: data engineers to maintain the data pipelines, and data analysts with domain expertise serving business domains. She creates mentorship and collaboration between the many people who do data in Marketing, Product, Finance.

Dana does not bring order to the chaos. Instead, she creates a Process.

And thus, Dana isn’t your semantic layer, nor any of her analysts or engineers, or tools. The process is.

A combination of a [relay race](https://www.youtube.com/watch?v=d2RVs3aoXJA&ab_channel=OlympicsAquatics) and a game of [Telephone](https://en.wikipedia.org/wiki/Chinese_whispers), it scatters the meaning and context of data across the team, pushing everyone to answer _fast_ while penalizing any _error_.

- For consistency, it goes through a data engineer to implement an ETL pipeline.
- For understandability, it goes through to a Wiki, or a catalog, or a Slack.
- For flexibility, it goes through a data analyst, or a BI developer building a self-serve tool.

Maintaining the process - correcting the errors, aligning the players, removing duplication, becomes the main drag of [using data well](https://hbr.org/2020/02/10-steps-to-creating-a-data-driven-culture) for the business.

### The Expanded Role of the Semantic Layer

The semantic Layer allows many people to use data in a way that helps them achieve their goals.

Few have the time or inclination to understand every step of the data flow process and its complexities. Fewer will even try. One curse of the “[modern data stack](https://www.moderndatastack.xyz/)” is that while it allows for a much richer data pipeline, its richness makes it harder for most data users to leverage data effectively.

Users either trust the process, can participate in it and wait for its roundtrip - or won’t trust and use the data.

When users are tired of waiting, they start hiring Eddies to their own domain, and build their own pockets of impenetrable mess, in an ever-growing [data mesh](https://www.datamesh-architecture.com/) of entropy.

As an organization expands, in addition to consistency, understandability, and flexibility, a fourth component becomes essential: _Curation_. Help the users work with a trustable subset where there is consistency and flexibility - while abstracting the hard parts.

## Your Last Semantic Layer

Like water treatment, semantic layers are a boring piece of technology. But even more so than the effect of water treatment on urban quality of life - semantic layers have the most profound effect on how well a business uses data.

A semantic layer is not “a single source of truth” (though it can be one!), or a “data mesh” (though it can facilitate one!) nor is it the solution for every data problem.

A semantic layer is the glue that holds the data together. When it is good, using data is a natural part of doing business.

When it is absent, dissipated in Telephone-game like process, or silo-ed in fortified pockets of non-reusable logic, data is hard and frustrating. Its anecdotal real successes glimpse a potential far from being fully realized.

At Honeydew, we change this. We make data integral to the daily operation of every business.

We create a semantic layer that frees data practitioners to focus on creative data work and not on the process. That unifies the meaning of data without creating another silo. That helps curate data for everyday business users. The helps domain expert data analysts to do a deep dive. That is based on a transparent collaboration of data analysts, data engineers, and data consumers.

_More details soon!_

## Update May 2024

Exactly 18 months passed since publishing this blog. Now this is not only a dream but a reality - Honeydew is the first Semantic Layer native to Snowflake. You can use it [today](/get-started).

Over the last months, we have learned that this short post captured a transition that thousands of companies go through: from _people_ to _process_ to a _platform_.

Almost every aspect of enterprise goes through that kind a transition. We are proud we can enable it in one of the most crucial aspects of business: the data foundation.

Now that analysts and data scientists are joined by LLMs such as ChatGPT leveraging that same data foundation, this is more important than ever.


## Blog: Honeydew – SOC 2 Announcement
URL: https://honeydew.ai/blog/honeydew-soc-2-announcement/
## It's official! We are SOC 2 Type II compliant and we want to talk about it.

We are delighted to announce that we are officially SOC 2 compliant and proud to have the "official" stamp that recognizes our secure data protection practices.

### What is SOC 2 compliance?

SOC 2 is a voluntary, security compliance standard for tech companies with cloud-based products. In a nutshell, it's all about how you handle customer data and keep it safe. SOC 2’s compliance guidelines are set by the AICPA (American Institute of Certified Public Accountants) and ensure services are secure, available, and confidential.

#### Why SOC 2 compliance matters

Cyber attacks, data breaches and ransom attacks are an ever-present threat, now more than ever. Organizations need to protect their data and adhere to federal regulations and industry standards. Here at Honeydew, having robust protection of customer data is our top priority.

Being in accordance with SOC 2 standards allows us to demonstrate our report to our customers, partners and stakeholders, serving as evidence of our compliance with the universally-acknowledged information security benchmark.

Moreover, it pertains to guaranteeing that our organization implements information security policies, controls and practices at the highest level, thereby earning the trust of our customers and partners!

##### So what exactly was audited

You might be curious about what exactly gets evaluated to achieve SOC 2 compliance. Our audit covered three essential Trust Services Criteria, namely Security, Availability, and Confidentiality. Numerous internal verifications were conducted to ensure the proper implementation and effectiveness of all aspects.

[Scytale](https://scytale.ai/) assisted in customizing controls to fit Honeydew's infrastructure, software, processes, personnel and data. This involved implementing controls pertaining to:

- Remote onboarding/offboarding of employees
- Cloud infrastructure security
- Information security risk management
- User access review
- Multi-factor authentication
- User access review
- Threat detection
- Change management procedures
- Asset management
- Data encryption
- Secure development and more

###### What comes next?

Once an organization is SOC 2 compliant, it does not end there. This is not a once-off project and here at Honeydew, we will continue to maintain our compliance, monitor our security systems and update all necessary policies and procedures.

Honeydew will remain committed to continuous review of information security, supplying top-notch data security and compliance to our customers