Cube — REST, GraphQL & SQL APIs

Three doors, one room

Cube exposes the same cube model through three protocols — and the choice is mostly about what the consumer already speaks:

• REST (/cubejs-api/v1/load) — JSON in, JSON out, easiest for embedded React/Vue dashboards and LLM tool-calling. Pagination, security context and caching are all handled per-request.
• GraphQL — typed, introspectable, autocompletable; the default for new internal tooling and IDE-driven exploration. Queries map almost 1:1 to REST under the hood.
• Postgres-wire SQL API — Cube speaks the Postgres protocol, so any SQL client (Tableau, Superset, Metabase, Hex, psql) can query measures and dimensions as if they were Postgres columns. Joins, filters, GROUP BY all work.

Security context — the cross-cutting concern

All three doors share the same securityContext (a JWT). Cube applies row-level filters, column masks and rate limits server-side based on the JWT claims — so a Tableau connection and an LLM agent both honour the same tenant_id boundary, and there is no front-end where a developer could 'forget' the filter.

Server-side security context is airport security versus asking each gate to check its own bags. Picture an airport where every departure gate ran its own screening with its own rules — some thorough, some half-asleep. Chaos, and one of them eventually waves the wrong bag through. Real airports screen everyone once, centrally, and the gates trust the result. Cube's securityContext is that single checkpoint: the JWT is screened once, server-side, and the REST, GraphQL and SQL consumers all inherit the identical row-level filter. A WHERE tenant_id = … living in a dashboard is a gate doing its own bag check — fine until the day it isn't.