apache/gravitino

Gravitino is worth a look if your data landscape has already outgrown a single catalog: it is aimed at teams that want one metadata layer across heterogeneous, possibly multi-region storage instead of stitching together per-system catalogs by hand.

The problem

A team wants to query a Hive table, a MySQL schema and objects in S3 through one engine without teaching each engine every backend. Today that usually means registering each source separately in every engine, keeping access rules and discovery in several places, and reconciling them whenever something changes upstream. Gravitino inserts a metadata service between the engines and the underlying systems, so the engine connects to one endpoint and the catalog owner registers sources once. The result is a shared view of tables and, nominally, AI assets across engines and regions.

What's different

The core mechanism is direct metadata integration: connectors read from the underlying systems rather than importing snapshots on a schedule, so the README claims upstream changes are immediately reflected. On top of that it exposes native Iceberg and Lance REST catalog services and a Trino connector, which matters if those are already in your stack. Governance features — access control, auditing and discovery — sit at the same layer, which is the real argument for adopting it: one place to reason about who can see which asset.

The trade-off is that Gravitino becomes a piece of infrastructure in the query path. You are adding a server between engines and storage, with its own configuration, releases and upgrade cadence, and the value scales with the number of sources and engines you actually run. The README also frames AI model and feature tracking as work in progress, so treat the "AI asset" angle as direction rather than something to depend on today.

Who should try it

A good fit is a platform team running several engines over a lakehouse with sources spread across clouds or regions, where federated discovery and centralized governance are concrete pain points. The Docker Compose playground is the sensible way to evaluate the full stack before committing. A poor fit is a single-database project or a small team with one engine and one storage layer: the federation and geo-distribution machinery would add an operational component without solving a problem you have. If you only need Iceberg REST access, the Iceberg REST catalog service documentation is the narrower entry point.

Requirements and limitations

The README states that building from source via Gradle does not currently support Windows, so Windows-based contributors need another environment for local builds; running from a binary release is the documented alternative for trying the server. Building and packaging involves Gradle and the bundled Web UIs, with options to skip the UI build. Beyond setup, the ongoing cost is governance and connector upkeep: each source type you add is another integration to configure and keep aligned with upstream changes, and the access-control and audit features need their own policy decisions.

The AI asset management feature is explicitly marked WIP, and the README does not document migration paths or compatibility guarantees for existing catalogs; anyone with an established metastore should check the documentation for their specific connectors before planning a migration.

HotRepo's take

HotRepo's record covers only two daily-board dates, 2026-10-24 (+11 stars) and 2026-10-25 (+8 stars), so trend persistence cannot be judged from this sample. Gravitino is not a weekend experiment — it has been on GitHub since April 2023 and is an Apache project — but long-term adoption here should be driven by whether you genuinely need cross-engine, cross-region federation, not by board appearances. Before investing, verify that the specific connectors for your storage and engines are documented, since the catalog's value rests entirely on those integrations.