Datus Blog
Evan Paul·

GoodData: How a 17-Year BI Company Became an AI-Native Analytics Platform ​

In 2007 — the year the iPhone launched and "cloud BI" did not yet exist as a category — a Czech entrepreneur named Roman Stanek founded a business intelligence startup in San Francisco. Its architecture made an unusual bet: a proprietary query language called MAQL, designed to let business users define metrics declaratively without writing SQL, sat between every dashboard and every database. That decision was not strategic foresight about AI agents. It was a practical response to the problem of BI consistency — make sure every dashboard computed revenue the same way. Seventeen years later, after a rebrand to GoodData.AI in April 2026, that same MAQL engine has become the company's most valuable asset — not because dashboards still matter most, but because AI agents need exactly the kind of governed, composable metric definitions MAQL was built to provide. This article traces GoodData's evolution, examines the architecture that survived three industry shifts, and extracts the lesson that matters for every data team: governed semantics outlast every interface built on top of them.

TL;DR ​

  • GoodData was founded in 2007 by Roman Stanek as a cloud BI platform. It built one of the industry's earliest universal semantic layers with MAQL (Multidimensional Analytical Query Language), a proprietary query engine that translates business logic into optimized SQL.
  • Key differentiators: MAQL (composable, auto-optimizing metric query language), FlexQuery (Apache Arrow + DuckDB + Iceberg-based analytics engine), Analytics Lake (data + metadata + models + metrics in one platform), and true multi-tenant architecture (one instance serves thousands of tenants with isolated data).
  • Rebranded to GoodData.AI in April 2026, adding AI Assistant (semantic-grounded chat), Agent Builder (build and deploy AI agents), MCP Server (governed analytics execution), and Smart Search.
  • GoodData's 17-year arc — from cloud BI → headless BI → AI-native analytics — mirrors the industry trajectory: the semantic layer, once a feature of the BI tool, becomes the platform's central infrastructure layer for AI agents.
  • Lesson for data engineering: the companies that survive the AI transition are the ones that built their semantic layer before they needed it for AI. GoodData's MAQL and LDM were built for BI consistency; they turned out to be the foundation for trustworthy AI agents.

1. GoodData's evolution: four phases ​

Phase 1: Cloud BI pioneer (2007–2015) ​

GoodData launched as one of the first cloud-native BI platforms — before Tableau Online, before Looker's acquisition, before the modern data stack existed as a category. The founding insight: BI was moving from on-premise, IT-owned reporting to cloud-based, self-service analytics. GoodData provided a multi-tenant cloud platform where business users could build dashboards without waiting for IT.

This era established two architectural decisions that proved durable:

  • True multi-tenancy: a single GoodData instance serves thousands of customers with isolated data, centralized updates, and per-tenant customization. Most BI platforms added multi-tenancy later as an enterprise feature; GoodData built it into the architecture from day one.
  • Semantic layer as core infrastructure: GoodData's LDM (Logical Data Model) and MAQL were not add-ons — they were the platform's foundation. Every dashboard, every report, every API call routed through the semantic layer. This was architecturally unusual in 2007 and became GoodData's primary competitive moat.

Phase 2: Headless BI and API-first (2015–2022) ​

As the modern data stack matured — Snowflake, dbt, Fivetran — GoodData recognized that dashboards alone were insufficient. Customers wanted to embed analytics in their own products, serve metrics through APIs, and consume data through custom frontends. GoodData pivoted to headless BI: the semantic layer and query engine as the product, with dashboards as one consumption option among many.

Key moves:

  • 100% API coverage: everything in GoodData became API-accessible — semantic models, metrics, dashboards, user management.
  • Analytics-as-code: VS Code extension, GitHub integration, CI/CD for analytics — treating metric definitions and dashboards as software artifacts.
  • React SDK (GoodData.UI): a component library for embedding analytics in custom applications, with the semantic layer providing governed metrics underneath.

Phase 3: FlexQuery and Analytics Lake (2022–2025) ​

GoodData rebuilt its query engine around open-source technologies: Apache Arrow for in-memory caching (FlexCache), DuckDB for embedded query processing, and Apache Iceberg for open table format compatibility. The product vision: an Analytics Lake — combining data, metadata, models, metrics, and reports in a single platform — with FlexQuery as the composable data service layer.

This phase signaled a broader industry pattern: BI platforms becoming data platforms. If you already have the semantic layer, the caching layer, and the query engine, adding data storage and transformation is architecturally natural. The risk: competing with Snowflake and Databricks at the storage layer is a different game than competing with Tableau at the visualization layer.

Phase 4: GoodData.AI — agentic analytics (2026–present) ​

The April 2026 rebrand to GoodData.AI formalized the company's AI-first direction. New capabilities:

  • AI Assistant: conversational, natural-language interface grounded in the semantic layer — the MAQL engine ensures that AI-generated queries respect governed metric definitions.
  • Agent Builder: build, deploy, and scale AI agents in production, with the semantic layer providing governed context and MAQL handling query execution.
  • MCP Server: governed end-to-end analytics execution — external AI agents (Claude Desktop, Claude Code, custom agents) can query GoodData's semantic layer through the MCP protocol.
  • Context Management: production-ready agentic analytics — agents maintain context across sessions within the governed boundaries of the semantic layer.

The architecture: AI agents don't query databases directly. They query GoodData's semantic layer, which translates business-language questions into optimized SQL, enforces access controls, and caches results. The semantic layer is the trusted proxy between AI and data — the same role Cube's D3 and Datus's Context Engine play, implemented with a different history and a different set of tradeoffs.

2. MAQL: the engine that survived three industry shifts ​

MAQL (Multidimensional Analytical Query Language) is GoodData's proprietary semantic query engine and its most durable technology asset. It is worth understanding because it solves a problem that every AI agent eventually hits: composing metrics from reusable components with automatic SQL optimization.

A MAQL metric definition:

SELECT SUM(revenue_usd - refund_usd - chargeback_usd)
WHERE order_status = "completed"

Looks simple, but MAQL handles:

  • Automatic join resolution: if revenue_usd and refund_usd live in different tables, MAQL resolves the join path from the LDM without the user specifying it.
  • Dimensional composition: slicing by region when region lives in a dimension table — MAQL resolves the join, enforces the grain, and generates the correct SQL.
  • Metric composition: gross_margin_pct = (net_revenue - cogs) / net_revenue — MAQL composes the component metrics, resolves their underlying tables and joins, and generates a single optimized query.
  • Multi-source federation: the same metric definition can query Snowflake, BigQuery, and Postgres — MAQL generates dialect-appropriate SQL for each target.

What makes MAQL architecturally interesting for the AI era: it is a declarative metric composition engine that predates MetricFlow by a decade. The problems it solves — metric composition, automatic join resolution, grain enforcement, multi-engine SQL generation — are exactly the problems AI agents face when they try to generate complex analytical queries. MAQL solved them for BI; MetricFlow is solving them for the modern data stack; OSI is standardizing the interchange. The pattern is the same: declarative metric definitions + engine-resolved SQL generation = trustworthy answers.

3. What GoodData's trajectory reveals about the market ​

Lesson 1: The semantic layer was always the real product. GoodData started as a dashboard company and evolved into a semantic layer company that happens to ship dashboards. The dashboards are replaceable — GoodData.UI, custom React apps, embedded analytics, third-party BI tools can all consume the semantic layer. The semantic layer, with its 17 years of MAQL optimization and LDM governance, is what customers pay for.

This pattern repeats across the industry: Looker's real product was LookML. Cube's real product is the semantic API. dbt's real product is the transformation layer; MetricFlow adds semantics on top. The dashboard is a commodity. The governed, composable, API-consumable metric definition is the durable asset.

Lesson 2: AI agents need the semantic layer, not the dashboard. GoodData didn't add AI to its dashboards. It made the semantic layer AI-accessible — through an AI Assistant, an Agent Builder, and an MCP Server. The dashboard is still there for humans. But the architectural bet is that the semantic layer, exposed to AI agents through APIs and protocols, is more valuable than any dashboard feature.

This is the same bet Datus, Cube, and MetricFlow are making — from different starting points and with different architectures. The convergence is striking: a graph database company (Neo4j), a BI company (GoodData), a semantic layer startup (Cube), a transformation company (dbt), and an open-source data engineering agent (Datus) all landing on the same pattern — semantic layer as agent infrastructure.

Lesson 3: Multi-tenancy as an AI feature. GoodData's architectural decision to build true multi-tenancy in 2007 turns out to be an AI-era advantage. When you deploy AI agents across thousands of customers, each customer's data must be isolated, each customer's metrics can differ, and each customer's agents must be scoped to their data only. GoodData's multi-tenant LDM — one semantic model, instantiated per tenant with tenant-specific data and overrides — is exactly the pattern that enterprise AI agent deployments require.

4. GoodData and data engineering agents ​

GoodData occupies a different tier of the data agent stack than Datus:

DimensionGoodDataDatus
Starting pointBI consumption — dashboards, reports, embedded analyticsData engineering — context building, Subagent creation, CLI-first
Semantic layerProprietary (MAQL + LDM), built over 17 yearsOpen, MetricFlow-compatible, auto-generated from schema and SQL
Agent roleAgents consume the semantic layer — AI Assistant queries MAQLAgents produce and evolve the semantic layer — generate models, capture SQL, refine context
Primary userBusiness users consuming analytics; developers embedding analyticsData engineers building and maintaining agent infrastructure
DeploymentCloud platform (SaaS), multi-tenantOpen-source core (Apache 2.0) + Cloud Personal + Enterprise
AI approachSemantic-grounded AI on top of existing platformAI as the operating model — context evolves with every agent interaction

The relationship is complementary, not competitive: GoodData provides a mature, governed semantic consumption layer. Datus provides a context creation and evolution layer. A team could use Datus to generate and evolve semantic models and metrics, and GoodData to serve them through governed APIs with multi-tenant access control — the creation tier and the distribution tier working together.

5. What data teams can learn from GoodData's arc ​

Build the semantic layer before you need it for AI. GoodData invested in MAQL and the LDM for BI consistency — not for AI. That investment turned out to be the foundation that made their AI transition credible. The lesson for data teams: the metric definitions you create today for dashboard consistency are the same definitions your AI agents will need tomorrow. Invest in them now, in a portable format (MetricFlow YAML, OSI-compatible), and the AI transition becomes a consumption pattern change rather than a rebuild.

The dashboard is not the product; the metric definition is. GoodData's evolution from dashboards → headless APIs + embedded → AI-native analytics tracks the industry's understanding that governed metrics are the durable asset, not the visualization layer on top. Choose tools that expose metrics through APIs, support open standards (OSI), and allow you to swap the consumption surface without rebuilding the metric definitions.

Multi-tenancy is not optional for enterprise AI agents. If you plan to deploy AI agents across teams, departments, or customers, each scope needs isolated context, isolated data, and isolated agent behavior. A single-tenant architecture that works for internal analytics breaks at enterprise scale. GoodData's 17 years of multi-tenant architecture is a reference pattern.

Don't bet against open standards. GoodData's adoption of Apache Arrow, DuckDB, Iceberg, and participation in OSI signals that even companies with proprietary technology assets (MAQL) recognize that interoperability wins. The companies that make their semantic definitions portable — through OSI, MetricFlow compatibility, or open APIs — will outlast the ones that treat semantics as a proprietary moat.

Conclusion ​

The most instructive thing about GoodData's 17-year arc is not that it survived — plenty of BI companies survived. It is that the architectural decision that saved the company was made in 2007 for a completely different reason. MAQL was built to solve dashboard consistency. It turned out to solve AI agent grounding. The dashboards evolved; the interfaces multiplied; the consumption model shifted from embedded charts to headless APIs to MCP servers — and through all of it, the governed metric definitions remained the platform's center of gravity. The counterfactual is the real lesson: if GoodData had built a thin visualization layer on top of raw SQL (as many early BI tools did) and treated semantics as a dashboard configuration problem rather than a platform infrastructure problem, there would be nothing to build GoodData.AI on top of. The semantic layer had to exist before the AI agents needed it. For data teams making architecture decisions today, the implication is uncomfortable because it asks you to invest in something — governed, portable, API-consumable metric definitions — whose full value will not be realized until your organization deploys AI agents at scale. That is a harder sell than "we need better dashboards." But GoodData's arc suggests it is also the right one.

Frequently asked questions ​

What is GoodData? ​

GoodData (now GoodData.AI) is an AI-native analytics platform founded in 2007. It provides a universal semantic layer with MAQL (a proprietary metric query language), a composable analytics engine (FlexQuery), and — since April 2026 — AI agents that consume governed metrics through natural language and MCP. 140,000+ customers, headquartered in San Francisco.

What is MAQL? ​

MAQL (Multidimensional Analytical Query Language) is GoodData's proprietary semantic query engine. It defines metrics declaratively, automatically resolves joins from the Logical Data Model, composes metrics from reusable components, generates optimized SQL for multiple database engines, and enforces metric grain. It is functionally similar to MetricFlow — the key difference is that MAQL is a proprietary technology built into GoodData's platform, while MetricFlow is open-source (Apache 2.0).

Why did GoodData rebrand to GoodData.AI? ​

The April 2026 rebrand to GoodData.AI signals that the company sees AI agents — not dashboards — as the primary consumption surface for governed metrics. The semantic layer (MAQL + LDM) remains the foundation; the rebrand reflects that the interface on top is now AI-native (assistants, agents, MCP) rather than dashboard-native.

Is GoodData a competitor to Datus? ​

Not directly. GoodData is a semantic consumption and distribution platform — it serves governed metrics to dashboards, embedded apps, and AI agents. Datus is a context creation and evolution system — it builds semantic models, generates metrics from SQL, and maintains evolving context for data engineering agents. They occupy different tiers of the data agent stack and are architecturally complementary.

Built with VitePress

Copyright © 2025 Datus.ai