Why Malloy?

Every semantic model in Credible is written in Malloy, an open-source language for analyzing, transforming, and modeling data. Malloy compiles to optimized SQL for BigQuery, Snowflake, PostgreSQL, Databricks, Trino, DuckDB, and more — so it runs wherever your data lives — but it captures something SQL cannot: what your data means.

The ideas behind Malloy are decades in the making, built by the team whose earlier work on LookML defined the modern semantic layer. Malloy is their second take — a full language rather than a configuration format, stewarded in the open by the Malloy Foundation.

SQL Says How. Malloy Says What.

SQL is an instruction set: you tell the database which tables to scan, how to join them, and what to group by — every time, in every query. The business logic is buried in the mechanics, and nothing stops two analysts from writing it two different ways.

Malloy inverts this. Relationships, definitions, and calculations live in the model, declared once. Queries just ask questions of it:

source: orders is conn.table('sales.orders') extend {
  join_one: customers on customer_id = customers.id
  measure: total_revenue is sum(order_amount)
}

run: orders -> {
  group_by: customers.region
  aggregate: total_revenue
}

The equivalent SQL restates the join condition and the revenue formula inline — and every query that follows restates them again. In Malloy, total_revenue means the same thing in every query, every dashboard, and every AI-generated answer, because there is only one definition.

Correct by Construction

Data teams lose trust one subtly wrong number at a time. Malloy is designed to make the most common classes of error impossible:

• Symmetric aggregates — Malloy understands the data graph, so joining orders to order_items never double-counts order revenue. Aggregates compute correctly at any grain, automatically — the fanout bugs that silently corrupt SQL results simply don't happen.
• Compile-time validation — Every field reference is checked against the warehouse schema before a query runs. Rename a column and the compiler tells you exactly what broke, instead of a dashboard quietly serving wrong numbers.
• Explicit dependencies — Sources reference each other as named language constructs, not strings in templates. The compiler builds the dependency graph itself, so breaking changes surface before runtime.

Freedom and Safety

Raw SQL offers maximum freedom but no safety — there's no way to save or reuse a calculation, so definitions drift. YAML-based semantic layers like LookML offer safety but constrain what you can express, and complex logic ends up escaping back into raw SQL.

Malloy combines both: the safety of a governed semantic model with the full power of a relational query language. A few examples of what that unlocks:

• Composition — Dimensions can reference other dimensions directly; transformations that take four chained CTEs in SQL take four lines in Malloy. Sources extend other sources, so enterprise_customers inherits everything from customers and adds only what differs.
• Nesting — Queries return rich hierarchical results natively — revenue by region, with a monthly breakdown nested inside each row — without rewriting or re-joining anything.
• Pipelines — Query results feed into further queries, supporting sophisticated multi-stage analysis in a single readable definition.

And when you genuinely need database-specific functionality, sql() blocks give you an escape hatch with type safety intact.

One Language for the Whole Lifecycle

In most stacks, the model is scattered across tools: SQL for transformation, YAML for metrics, a catalog for documentation, warehouse policies for access control, an orchestrator for materialization. Malloy's annotation system pulls the whole lifecycle into the model itself:

#(doc) Net revenue recognized at order completion, in USD
measure: total_revenue is sum(order_amount)

• #(doc) and #(index) document fields and index their values, so agents can find and understand your data
• #(authorize) and field modifiers define row- and column-level access control next to the data they protect
• #@ persist materializes expensive sources — no separate YAML config or external orchestration, with incremental rebuilds handled by the compiler

Everything lives in one set of version-controlled files: reviewable in a pull request, testable in CI, and deployable as a versioned package.

Built for AI

Malloy predates the AI wave, but it turned out to be exactly what AI needed. Frontier models write Malloy fluently — it's in their training data — and the language's design compounds the advantage:

• Agents write it well. Malloy is compact and declarative, and the compiler validates every query against the model before execution. When an agent gets something wrong, it gets a precise error instead of a plausible-looking wrong answer.
• Agents read it well. A Malloy model is dense with meaning — definitions, relationships, documentation, and access rules in one place. That's the context that turns a generic chatbot into an analyst that answers with your definitions.
• The model is the contract. Because every AI-generated query runs through the semantic model, answers are auditable, access-controlled, and consistent with what humans see in dashboards.

This is why Credible's AI Analytics Engine and open-source agent skills are built around Malloy: the language gives agents something SQL never could — the meaning behind the data.

Open Source, No Lock-In

Malloy is open source and committed to backward compatibility. Your models are portable, inspectable text files — you own the meaning you encode in them. The whole serving stack is open too: Malloy Publisher serves Malloy models over REST and MCP, and Credible's agent skills and MCP tools are contributed there in the open. Credible is the hosted, governed platform on top of that stack — not a walled garden around it.

Next Steps

For the language itself, see the Malloy Language Documentation and the Malloy GitHub repository.