Querying the dbt Semantic Layer (JDBC, GraphQL, BI)

The same semantic model, four front doors

Once semantic_models/*.yml and metrics/*.yml exist, the dbt Semantic Layer exposes them through four surfaces:

1. MetricFlow CLI — mf query --metrics revenue --group-by metric_time__week,country. Used in CI, notebooks, ad-hoc.
2. GraphQL — programmatic, typed; the canonical way for embedded apps and LLM agents.
3. JDBC — jdbc:arrow-flight-sql://... lets Tableau, Hex, Mode and Power BI ask SELECT {{metric('revenue')}} BY {{dimension('country')}} like any database.
4. dbt Cloud Semantic Layer integrations — Looker, Hex, Mode etc. consume the GraphQL endpoint natively.

All four share the same compiler (MetricFlow), so the answer is identical regardless of front door. That property is the entire point: a Tableau executive dashboard, a Streamlit ops tool, and a Slack-bot LLM all see the same revenue because they're calling the same compiler.

Four front doors onto one compiler is a bank you can reach by branch counter, ATM, phone line and mobile app. You check your balance through whichever channel is nearest, but every channel reads the same core banking ledger — so the number is identical no matter how you asked. dbt SL's JDBC, GraphQL, CLI and native integrations are those four channels; MetricFlow is the single ledger behind them all. The day two channels disagree about your balance is the day you stop trusting the bank — which is precisely why the semantic layer routes every front door through one compiler instead of letting each compute its own answer.