Getting started: Sovereign Data Platform ========================================== This page covers the **Sovereign Data Platform** product specifically: the per-customer, Spark-on-Kubernetes environment for interactive notebooks (JupyterHub) and BI/query serving (Trino) over a Unity Catalog-backed Delta Lake catalog, secured end to end by a single Keycloak identity and Trino's native OPA access-control plugin. Scheduling production jobs on a customer-scoped Apache Airflow instance is a separate, optional product — see :doc:`../airflow/getting-started` for its own getting-started page. For a step-by-step walkthrough of the user interface, see the :doc:`../user-manual/index`. Management summary ------------------- The rest of this page is written for the people who will actually build on the platform. This section is for anyone deciding whether to, or reporting on it afterwards — a manager, product owner, or sponsor who wants the shape of the thing without the implementation detail. You get a dedicated environment for your organization, not a shared multi-tenant service, covering two jobs that normally require separate tools and separate procurement: a place to explore data interactively, and a place to query it for BI and dashboards. Both are built on established open-source projects (Apache Spark, Trino, JupyterHub) rather than proprietary lock-in, and both sit behind one identity system, so access is managed in one place instead of per tool. Add the optional :doc:`Airflow product <../airflow/getting-started>` if you also need production scheduling. It's low-risk to adopt because the same code path an analyst runs by hand in a notebook is the exact code path a scheduled production job uses. There's no separate "dev" version of the platform that can drift out of sync with what actually ships. Every customer's environment is also fully isolated from every other customer's, down to the Kubernetes identity a job runs under, so this isn't a shared blast radius. As for cost: see the `pricing page <../../pricing/>`_ on the marketing site. It lists three sizing tiers (small/medium/large) matched to real deployment profiles already in production, not invented marketing numbers. Get in touch for a quote. Provisioning itself is a per-customer Keycloak realm plus JupyterHub and Trino. After that, onboarding is mostly about identity: who gets ``platform-users`` vs. ``platform-admins``. The sections below walk through each of those in order. Identity -------- A single Keycloak realm is provisioned per customer. Every component you use, JupyterHub and Trino, authenticates against that same realm and reads the same ``groups`` claim from your token, so there's one place group membership is managed, not a separate directory per tool. Two groups exist for every customer out of the box: ``platform-users`` and ``platform-admins``. Running notebooks interactively -------------------------------- Log into JupyterHub with your Keycloak account. Your notebook kernel *is* the Spark driver (client mode): the same container image and the same platform code path that production jobs use. There's no separate "dev" environment to keep in sync with production. Querying data ------------- Trino, authenticated against the same Keycloak realm, serves your Delta Lake tables. Row-level and column-level policy (who can see which rows, or which columns get masked) is authored self-service by your product owners in security-center, if your organization has that module enabled.