Saiku 4.8: A semantic layer that speaks MDX, SQL, and MCP from one cube

One cube, three consumers

Saiku 4.x solves a specific coordination problem: the same business definitions, hierarchies, measures, and synonyms are needed by Excel users who speak MDX/XMLA, by dashboard builders who want drag-and-drop, and by AI agents that should never see MDX. The project answers with a single semantic cube, defined in Mondrian schema, exposed through three surfaces: a browser SPA that writes MDX for you, a SQL planner via Apache Calcite, and a typed REST API under /rest/saiku/api/ai/*. The audience is a data team that has outgrown hand-written SQL per tool and wants one source of truth for analytical dimensions and measures. The README positions it as a semantic layer, not just an OLAP browser, and the 2026 rebuild is aimed squarely at teams that now have LLM agents querying data. If you only need a dashboard tool, Saiku is heavier than necessary; if you only need an MDX server, Mondrian alone might do. The value is in the unification.

How the pieces fit: Mondrian, Calcite, Arrow, and a typed AI contract

The architecture is a stack of Java components. Mondrian 4.8.1.x, a Spicule fork, is the cube engine. It has two SQL planners: the legacy SqlQuery builder and a Calcite-based planner, which is the default. You can force the legacy one with -Dmondrian.backend=legacy. The Calcite planner is what lets Saiku reach modern engines like Trino and Iceberg, as shown in the examples/lakehouse-demo. Query results travel as Apache Arrow cellsets, so the browser and programmatic consumers share a zero-copy envelope. The server is a single JAR with Jetty 12, Jersey 3.1, Spring 6, and Spring Security 6.5, launched via Picocli. The SPA is SvelteKit 5, served from inside the same JAR at /ui/. The AI surface is a set of endpoints: /ai/cubes and /ai/schema expose hierarchies, levels, measures, and synonyms; POST /ai/query takes a JSON description of a question, translates it to validated MDX, runs it, and returns typed {value, formatted, unit} cells. Validation failures return a {status, field, available} envelope so an agent can self-correct without scraping logs. There is also a SQL-side twin for the Ossie semantic layer, with the same shape and an /ai/ossie/ask endpoint. This design is notable: the AI does not see raw SQL or MDX, only a typed contract.

Getting it running: Docker is easy, building from source is not

The fastest path is Docker. The README gives a one-liner: docker run -d -p 8080:8080 --name saiku -e SAIKU_DEMO=true ghcr.io/spiculedata/saiku, then open http://localhost:8080/ui/ and log in with admin / admin. Demo mode ships a self-contained H2 database with the FoodMart cube. For a real deployment, you must drop SAIKU_DEMO=true and set SAIKU_ADMIN_PASSWORD to a strong value. The README states that Saiku refuses to start on default admin/admin once it is network-reachable, which is a sensible guard. Building from source is a different story. You need JDK 21 and Maven 3.9+. The build fails before compiling unless you set up GitHub Packages auth, because Saiku's Mondrian fork, olap4j, saiku-query, and Ossie artifacts are published to GitHub Packages and require an authenticated token even though the packages are public. You must create a classic personal access token with only read:packages scope, because GitHub's Maven registry does not accept fine-grained tokens. Then you add five <server> entries to ~/.m2/settings.xml. The README warns that without this you get a bare 401 Unauthorized on pentaho:mondrian that never mentions tokens. This is a sharp edge: a public project that requires auth to build is a real barrier for evaluation.

AI agents: skills, spaces, and MCP

Beyond the query API, Saiku has two extension mechanisms for agents. Skills are markdown files in saiku-home/skills/*.md with YAML frontmatter, discoverable from /ai/ask. You can invoke one explicitly by prefixing an ask with /<skill-name>, or let the LLM route naturally. Spaces are JSON files in saiku-home/agent-spaces/*.json that define named personas with a system prompt, a cube allowlist, and a skill allowlist. POST /ai/spaces/{id}/ask enforces the persona server-side, so a cube outside the allowlist returns a 403 the user cannot override. That server-side enforcement is a meaningful security feature: it prevents an agent from being prompted into querying unauthorized cubes. The MCP wrapper is bundled as saiku-mcp, a stdio Model Context Protocol wrapper. The README shows a Claude Desktop / Cursor / Cline config using docker exec -i saiku saiku-mcp. This is a concrete integration path for LLM tools. The combination of a typed validation envelope and server-side spaces is a thoughtful design for agent safety, but it is also new and unproven in production.

Dashboards and observability: what you get and what you don't

The dashboard feature is not an afterthought. The README lists cross-tile filters, click- and brush-cross-filtering, drill-down/through, conditional formatting, combo charts, anomaly/forecast overlays, auto-refresh, PDF/PNG export, and read-only share links. There is an embeddable <saiku-embed> web component for putting a dashboard in your own app. This is a full BI front-end, not just a query API. On the operations side, Saiku ships opt-in OpenTelemetry instrumentation via the OTel Java agent. Setting OTEL_EXPORTER_OTLP_ENDPOINT activates auto-instrumentation for Jetty, Jersey, JDBC (every Mondrian-emitted SQL becomes a child span), outbound HTTP, JVM metrics, and DBCP2 pool metrics. Without that env var, the agent is never loaded, so zero overhead when off. The trace context is injected into the Saiku log pattern automatically. The README is honest that some custom spans are not yet covered, such as ThinQueryService, listed as Tier 2. This is a pragmatic observability story, but if you need deep tracing into the query planner, you will have to wait.

Limitations and wrong-tool cases

The most obvious limitation is the build friction. The GitHub Packages auth requirement is a genuine barrier for anyone who wants to audit or fork the code. It also means the project depends on a private-ish registry for public artifacts, which is fragile. A second limitation is the dual planner. The Calcite planner is default, but it is new, and the legacy SqlQuery builder still exists for a reason. If you have a complex Mondrian schema that relies on legacy behavior, you may need to force -Dmondrian.backend=legacy, which means you are not getting the modern SQL generation. Third, the AI API is designed for agents, but it is not a natural-language-to-SQL engine; it translates a JSON description into MDX. That means an agent must be able to produce that JSON, which requires discoverable schema. If your use case is free-form natural language over arbitrary tables, Saiku is the wrong tool. Fourth, the project is a rebuild in 2026, so the community and ecosystem are thin. The README mentions a live demo and a Slack, but there is no evidence of a large contributor base. Finally, the SPA is a separate repo, served inside the JAR, which complicates custom UI work.

Alternatives: where Saiku differs

The closest alternative is Apache Superset, which is a Python-based BI tool with a SQL-first semantic layer. Superset does not use MDX or Mondrian; it generates SQL directly against your warehouse. The difference in approach is fundamental: Saiku keeps a cube model (MDX) as the source of truth, then translates to SQL via Calcite, while Superset treats SQL as the primary interface and adds a thin semantic layer on top. If your team is comfortable writing SQL and does not need MDX/XMLA for Excel, Superset is simpler and has a larger community. Another alternative is dbt with a metrics layer, which defines metrics in YAML and compiles to SQL, but it does not expose an MDX endpoint. For AI agents, you could use a text-to-SQL tool like Vanna or a semantic layer like Cube, which has its own REST API and supports multiple databases. Cube also has a semantic layer but uses a different modeling language (YAML or JavaScript) and does not have Mondrian underneath. Saiku's differentiator is the MDX heritage and the XMLA/Excel compatibility, which neither Superset nor Cube offers directly. If Excel users are a hard requirement, Saiku is the only open-source option in this comparison that speaks native MDX.

Maintenance and upgrade cost

Saiku is Apache-2.0 licensed, which is permissive and safe for commercial use. The project is actively maintained: the latest release is v4.8.0-RC2 from August 2026, with RC1 and v4.7.1 in the same month. That cadence suggests ongoing development, but release candidates are not stable. The maintenance cost comes from the fork of Mondrian and the custom SPA. You are not using upstream Mondrian; you are using Spicule's fork, which means you must track its changes. The build requires Java 21 and Maven 3.9+, so your CI must support that. The OpenTelemetry setup is opt-in and zero-code, which reduces operational overhead. The upgrade path between 4.x versions is not documented in the README, so you should check the release notes for breaking changes. The biggest cost is the initial build setup: you must configure GitHub Packages tokens in your build environment, which is a one-time but non-trivial hurdle. Also, because the SPA is a separate repo, upgrading the UI may require a separate build and integration step, though the container bundles it. Overall, the maintenance burden is moderate but higher than a pure SQL tool because of the MDX and Mondrian complexity.

Editorial conclusion

Adopt Saiku 4.8 if you need a single semantic cube that serves Excel/MDX clients, browser dashboards, and LLM agents with a typed contract, and if you can tolerate a build that requires GitHub Packages auth and a Java 21 toolchain. Skip it if you want a pure SQL semantic layer with no MDX heritage, or if your team cannot commit to maintaining a fork of Mondrian and a custom SPA. Before adopting, verify that the Calcite planner handles your target SQL dialect (e.g., Trino, Iceberg) by running the lakehouse-demo, and check that the AI query and MCP endpoints cover the question types your agents will ask. The project is actively released (4.8.0-RC2 in August 2026) but it is a rebuild with a narrow community, so plan for upstream maintenance yourself.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes