Semantic Layers Are Dashboards Wearing a Trench Coat

The semantic layer is having a moment. The pitch is that you define your metrics once (revenue, active users, churn) in a central place, and then every tool and every query pulls from those shared definitions instead of each person reinventing them. It's sold as the fix for the "nine definitions of active user" problem, and as the thing that finally makes AI-on-your-data trustworthy.

I want to like it more than I do. Because when I look closely at how most semantic layers get used, I see a dashboard with extra steps and a better marketing budget.

The good idea inside it

Let me steelman it first, because there's a real, correct idea here.

The core insight of the semantic layer is right: metric definitions should live in one place. "Revenue" should mean one thing, defined once, and everyone (humans, dashboards, AI agents) should compute it the same way. That's genuinely important. The chaos of every team having its own slightly-different revenue number is real and expensive, and a shared definition layer is a legitimate answer to it.

If that were all a semantic layer was, a single source of truth for what each metric means, I'd have no complaint. I'd be a fan.

Where it turns back into a dashboard

The problem is what happens next. To define a metric in the semantic layer, someone has to anticipate it and model it ahead of time. Revenue gets defined. Active users gets defined. Churn gets defined. Great. Now someone asks "what's revenue for enterprise customers who signed up in Q1 and used the export feature," and that exact slice wasn't pre-modeled.

So you're back to the dashboard problem in a new outfit. The dashboard could only show you the views someone built in advance. The semantic layer can only answer questions composed from the metrics and dimensions someone modeled in advance. The day you want something outside the model, you file a request and wait for someone to extend it. The rigidity didn't go away. It moved up a level and got a nicer name.

That's the trench coat. Underneath the "define once, query anywhere" pitch is the same old constraint: you can only ask what someone already thought to support.

The tell

Here's how you know you're looking at a dashboard in disguise. Ask: when I want something the layer didn't anticipate, what happens?

If the answer is "I extend the model, or file a ticket for someone who can," it's a dashboard. A really good, centrally-governed dashboard, but a dashboard, bounded by what's been pre-built and gated behind whoever maintains the model.

If the answer is "I just ask the question and the system composes it, using the shared definitions where they apply," now you have something genuinely different. The metric definitions constrain meaning without constraining which questions you can ask.

Most semantic layers in practice are the first thing. The pitch is the second thing. The gap between them is where the disappointment lives.

What I actually want

I don't think the choice is "rigid governed metrics" versus "anarchic everyone-queries-raw." That's a false binary, and it's the binary the semantic-layer pitch quietly relies on to look good.

What I want is the definitions without the bottleneck. Pin down what "revenue" and "active user" mean, so those words are consistent everywhere. But don't require that every possible question be modeled in advance. Let someone ask an open-ended question against the real database, and have the shared definitions apply automatically when the question touches them, so "revenue" always means revenue, even in a query nobody pre-built.

That's the line we're trying to walk at QueryBear: you can describe your metrics and your schema so meaning stays consistent, but the agent can still compose questions you never anticipated, against live data, instead of being limited to a pre-modeled menu. Definitions as a constraint on meaning, not a constraint on curiosity.

The honest version

I'll grant the semantic-layer crowd this: a governed, pre-modeled layer is still better than the dashboard sprawl it replaces, and far better than everyone querying raw with their own definitions. If those are the only two options on your team, the semantic layer is the right move.

I just don't think those are the only two options anymore, and I think calling the semantic layer "the future" understates how much of the old rigidity it quietly keeps. It solves the definitions problem and reintroduces the anticipation problem. Half a fix dressed as a whole one. Take the good half, define your metrics once, and don't accept the part where you can only ask what was pre-built. That part you've already lived through. It was called the dashboard.