Skip to main content

Installation requirements

Datastrato Enterprise is deployed on Kubernetes. There is no tarball install and no bare-metal path. One deployment artifact means one thing to test, support, and upgrade.

Cluster​

RequirementMinimum
Kubernetes1.29 or later
Helm3.8 or later, for OCI registry support
CPU2 cores requested across the install, up to 6.4 at the limits
MemoryAbout 14Gi requested across the install, up to 21Gi at the limits, with 8Gi allocatable on one node for the Gravitino server
StorageA default storage class, unless you supply persistent volumes yourself

Workloads and resources lists each pod's requests, limits and persistent volumes. Managed Kubernetes on any cloud works, as does a self-managed cluster. Helm earlier than 3.8 cannot pull from an OCI registry and will fail at the first step.

Registry access​

The chart and the container images are served from the same OCI registry. Nodes must be able to pull images from it, and whatever machine runs Helm must be able to reach it.

Air-gapped clusters mirror the registry into an internal one. Because the chart and the images live together, one mirroring operation covers both, and relocating them keeps them in step.

Storage backend​

Gravitino stores its own entities in a relational backend. The chart can deploy one for you, which is appropriate for evaluation and not for production.

For production, supply an existing database. Size it for metadata rather than for data: the metadata database holds catalog definitions, tags, policies, and grants, not table contents.

Ports and network​

Services and ports​

Every component runs behind a ClusterIP Service. Nothing is reachable from outside the cluster until you publish it through an ingress, as described in Install.

ServicePortServes
{release}-ui3000The Enterprise UI
{release}-gravitino8090The REST API, used by the Java and Python clients and the Gravitino connectors
9001The Iceberg REST service
9101The Lance REST service
9201SCIM provisioning, when enabled
{release}-mcp8000The MCP server
{release}-marquez3050The lineage API
{release}-marquez-web3050The lineage web view
{release}-gravitino-postgresql5432The in-cluster metadata database, also holding the lineage database. 3306 for {release}-gravitino-mysql
opensearch-cluster-master9200, 9300The search index: HTTPS on 9200, node transport on 9300

The metrics service runs without a Service and listens on no port.

Inbound from outside the cluster​

Who connectsToPublished through
BrowsersUI, 3000ingress.hosts
AI agentsMCP, /mcp on the UI hostingress.hosts, or ingress.mcp.host on a host of its own
Java and Python clients, Gravitino connectorsREST API, 8090ingress.api.host
Iceberg enginesIceberg REST, 9001ingress.iceberg.host
Lance clientsLance REST, 9101ingress.lance.host
Your identity provider, for SCIMSCIM, 9201ingress.scim.host

Each published host needs a DNS name and a certificate the caller trusts. The SCIM host is called from your identity provider's cloud, so its certificate must be publicly trusted. The UI host forwards only the UI's own API calls to the server; engines and clients need the REST API published on a host of its own.

The metrics endpoints, /metrics and /prometheus/metrics, need no credentials and answer on 8090, 9001 and 9101. Publishing the Iceberg REST or Lance REST host therefore publishes them too. Scrape metrics from inside the cluster, and block those paths at the ingress if the hosts are public.

Inside the cluster​

FromTo
ServerThe metadata database; OpenSearch on 9200; the lineage API on 3050
Metrics serviceThe metadata database, and the connected sources it reports on
UIThe server on 8090; the lineage services on 3050; the Kubernetes API, to read the server's configuration and the published hosts
MCP serverThe server on 8090
LineageThe PostgreSQL database; OpenSearch on 9200

Outbound from the cluster​

DestinationFromWhen
The image registry, 730335553010.dkr.ecr.us-east-1.amazonaws.com, and the S3 hosts ECR serves image layers fromEvery nodeAlways. global.registry points every image at your own registry instead
Your identity provider's discovery, token and key endpointsUI, serverWith OAuth sign-in
Connected sources: metastores, databases, Kafka, object storageServer, metrics serviceFor each catalog
Cloud token services: AWS STS, Microsoft Entra ID, Google STSServerWhen a catalog vends credentials
Maven Central, repo1.maven.org, and storage.googleapis.comServer, metrics serviceOnly when the chart downloads JDBC drivers or Iceberg Spark jars. A Maven mirror value redirects them

Every source must be reachable from the server pod and from the metrics service pod. A JDBC catalog tests its connection when it is created, so one whose database the cluster cannot reach fails at creation; other catalog types fail on first use instead.

Proxies and network policies​

The chart has proxy values only for its download steps, under gravitino.jdbcDrivers.download and the Iceberg Spark jar download. To send the UI through a proxy, set HTTPS_PROXY and NO_PROXY in enterpriseWeb.env; NO_PROXY must include .svc, .cluster.local and the Kubernetes API address, or the UI cannot reach the server.

To restrict traffic with Kubernetes network policies, the tables above list the connections each component needs: allow the inbound rows from your ingress controller's namespace, and the inside and outbound rows for each workload.

Java and client requirements​

The server runs inside the container image and needs nothing installed on the host.

The Java client requires Java 8 or later. The Python client requires Python 3.10 or later. Engine connectors have their own version requirements, listed with each connector.

License​

A license key is required. The chart refuses to install without one, and the server stops at startup when its key is missing or past its grace period. See Licensing.