Analytics Query Language (AQL)

An analytics query language (AQL) is a query language that operates on metrics and dimensions rather than tables and columns. Where SQL asks "join these tables, group by these columns, aggregate this expression," an AQL asks "take this metric, filter it, compare it over time, rank the result." The abstraction level is higher – closer to how business users think about data, further from how databases store it.

SQL was designed for relational data manipulation. It's excellent at that job. But translating a business question into SQL requires the author to know the physical schema – which tables hold the data, how they join, what filters apply, what grain is correct. An AQL removes those decisions. The semantic layer handles table resolution, join paths, and grain management. The query author works with business concepts.

How AQL differs from SQL

The differences are structural rather than cosmetic.

Operates on metrics instead of expressions. In SQL, you write SUM(order_items.price * order_items.quantity) and hope every analyst applies the same logic. In an AQL, you write revenue – a named metric defined once in the semantic layer. The calculation logic is governed centrally.

Dimensions are declared rather than joined. In SQL, adding a dimension means adding a JOIN clause and a GROUP BY column. In an AQL, you declare which dimensions you want – by: [region, product_category] – and the semantic layer resolves the necessary joins. Fan-out protection, grain validation, and join-path selection happen automatically.

Operations compose. An AQL supports chaining: filter a metric, aggregate it, compare it to a previous period, rank the result. Each operation takes the output of the previous step as input. This is what makes composable metrics possible. SQL can do this too, but it requires nested subqueries or CTEs that most business users can't write and most AI systems generate unreliably.

Grain shifts are explicit. Computing a product's share of total revenue requires two grains – product-level and total. In SQL, this typically means a window function or a self-join. In an AQL, you express the grain shift directly: revenue / revenue(across: all). The engine handles the implementation.

What operations an AQL supports

A capable AQL covers the operations that business questions actually require:

• Filter. Restrict a metric to a subset: revenue | where: region = 'APAC'.
• Aggregate. Group a metric by dimensions: revenue | by: [product_category, month].
• Compare. Compute a metric across two conditions and return the difference or ratio: revenue | compare: previous_year.
• Rank. Order results by a metric and return position: revenue | rank: descending.
• Chain. Combine operations sequentially: filter, then aggregate, then compare, then rank – all in a single expression.

These operations map directly to how people phrase analytical questions. "Show me APAC revenue by product category this month vs. last month, ranked by growth" is a filter-aggregate-compare-rank chain.

Why AQL matters for AI

When an AI system answers analytical questions, it needs to generate some kind of query. If the target is SQL, the AI must infer table structures, join paths, filter conditions, and aggregation logic from schema metadata. This is text-to-SQL – and it's fragile. Ambiguous column names, complex joins, and multi-step logic produce errors that look plausible but return wrong numbers.

If the target is an AQL, the AI's job is simpler and more constrained. It selects from a known set of metrics and dimensions. It chains a known set of operations. The semantic layer validates the query against its definitions before execution. Wrong metric names get caught. Invalid dimension combinations get flagged. The AI operates within a governed vocabulary instead of guessing at a physical schema.

This is the practical difference between AI that generates fluent SQL which may be wrong, and AI that composes governed metric expressions which the semantic layer can validate.

Relationship to the semantic layer

An AQL is the query interface to a semantic layer. The semantic layer defines what metrics and dimensions exist. The AQL defines how users – human or AI – combine them into questions. A semantic layer without an expressive AQL limits what questions can be answered natively. An AQL without a semantic layer has no governed definitions to operate on. They're complementary: the semantic layer provides meaning, and the AQL provides composition.