Skip to main content

Release notes

Releases are listed in reverse order, starting with the latest release of Datastrato Enterprise. Each release lists new features, improvements, fixed issues, upgrade notes and known issues, and includes only the headings that apply to it.

1.3.0 Enterprise (September 2026)​

Datastrato Enterprise 1.3.0 is built on Apache Gravitino 1.3.1 and includes its features, described in the Apache Gravitino release notes.

New features​

User interface​

  • A new UI organized around the tasks administrators perform: exploring metadata, governing assets, authorizing access, automating tasks, monitoring health and configuring settings.
  • Connection status and testing. Each catalog shows its connection status, and a catalog's connection can be tested with proposed changes before they are saved.
  • Topic creation, alongside catalogs, schemas, filesets and models.
  • Metalake ownership can be set and changed from the UI.
  • Tag coverage. Each tag shows the objects that carry it.
  • Governance overview. Tag, policy and ownership coverage across catalogs, and data lineage, in one place.
  • Authorization overview. A summary of roles, users and groups, with each role's members listed and grants that can be added or removed from any object.
  • Health monitoring. Request rates, latency, top operations, and server memory and garbage collection.
  • Job automation. Jobs run from templates, with their status and history tracked.
  • Client access. The endpoints and connection details that engines and clients need, with links to their setup guides.

Identity and access​

  • Built-in identity provider. Local users sign in with a user name and password, can change their own password, and can sign in when the external identity provider is unavailable.
  • Directory provisioning over SCIM from Microsoft Entra ID and Okta, using bearer tokens created in Datastrato Enterprise, with the last activity of each token shown. See SCIM provisioning.
  • A server-wide directory of users and groups that records where each one came from: created locally, provisioned over SCIM, or created on first sign-in from the identity provider. Users and groups can be suspended and reactivated, and a suspended or deprovisioned user can no longer sign in.
  • Configurable session inactivity timeout for the UI.

Security​

  • Credential masking. Secrets in catalog properties, including cloud storage keys, client secrets and JDBC passwords, are masked when catalogs are read or listed.
  • Permission-filtered search. Search results include only the objects the caller is allowed to see.
  • Clean error responses. API errors return a message and an error code, without internal stack traces.
  • Separated internal endpoints. Endpoints that serve the UI are separated from the public REST API and require authorization.
  • Secured lineage. The lineage service is reached through the UI rather than exposed on its own ingress.
  • Durable logs. Server and audit logs are written to a persistent volume and survive pod replacement. Server logs rotate without overwriting earlier archives, and audit entries record the roles granted or revoked.

Catalogs and connectors​

  • Oracle and SQL Server catalogs, available in Datastrato Enterprise and not in Apache Gravitino. See Oracle and SQL Server.
  • BigQuery catalogs, for managing BigQuery datasets and tables alongside the other sources. See BigQuery.
  • Memory that scales with providers. Catalogs of the same provider share the provider's classes, so memory grows mainly with the number of providers in use rather than the number of catalogs.
  • The MCP server on Kubernetes, deployed by the Helm chart alongside the server, serving every metalake from one instance. See MCP server.

Scale and operations​

  • Large directories and schemas. Listing users, tables and models is optimized for large directories and schemas, and lists in the UI show every item.
  • Request metrics. Request rates and latencies are recorded for every API call, including objects created through the UI, and shown on the monitoring page.
  • Kubernetes deployment with a Helm chart pulled from the Datastrato registry, an ingress for the Iceberg REST catalog, and license keys for evaluation and production. Upgrades stop if a schema migration fails. See Install with Helm and Licensing.

Known issues​

  • Object names containing a dot. When authorization is enabled, listing a schema that contains an object whose name includes a dot returns a 400 error that names the object, and loading that object returns a 400 error stating that the dot is reserved. One such object makes the whole schema unlistable. The workaround is to rename the object in the source system. Full support for names containing dots is planned for 2.0.
  • Catalog names must be unique across metalakes. A catalog name can be used in only one metalake on a server. Creating a catalog in a second metalake with a name that already exists in another metalake fails with a 409 error. Independent catalog names in each metalake are planned for 2.0.
  • Object owners need access to the parent catalog and schema. Owning a table does not by itself allow the owner to reach it. To act on an object, or to find it in the UI, the owner also needs USE_CATALOG on its catalog and USE_SCHEMA on its schema. Without them, the owner can still read the object's owner and transfer ownership through the REST API.
  • Per-user authorization through the Trino connector requires OAuth2. The connector carries the Trino session user to Gravitino only when it is configured with gravitino.client.authType=oauth2 and gravitino.client.session.forwardUser=true. Under gravitino.client.authType=basic the session user cannot be forwarded, so every query through that catalog is authorized as the user named in gravitino.client.basic.username, and the grants, denies and revokes that apply to the person running the query are not consulted. Configure the connector for OAuth2 when Gravitino authorization is to apply per user. Session forwarding under basic authentication is planned for 2.0.
Last updated on