Apache Gravitino is a federated metadata lake: rather than copying metadata into its own store, it manages metadata in place across Hive, JDBC databases, object storage, and message systems, exposing one model and one API for data and AI assets across regions and clouds.
A self-hosted Java server exposing REST, Java, and Python surfaces plus a web UI. A metalake holds catalogs that stay in their source systems, across fifteen providers including Hive, Iceberg, Hudi, Paimon, JDBC databases, filesets, and Kafka. Datastrato sells an enterprise distribution; there is no hosted service.
How Apache Gravitino answers the questions Data Catalogs turns on.
| How it works | |
| Metadata model | Federation rather than ingestion: a metalake holds catalogs that stay in their source systems, so an engine resolves through Gravitino instead of around it and there is no second copy to keep current. Under the metalake sit catalogs, schemas, and then tables, views, filesets, topics, models and user-defined functions |
| Lineage | OpenLineage rather than a graph of its own, a Spark JAR emits events stamped with Gravitino identifiers, and the server receives, processes and sinks them onward to other systems. Column-level, and spanning fileset, Iceberg, Hudi, Paimon, Hive and model catalogs |
| Search and discovery | Browsing rather than searching: the web UI, a CLI and the REST, Java and Python SDKs walk the metalake hierarchy, with tags to narrow it. There is no documented full-text discovery surface of the kind DataHub and OpenMetadata are built around |
| Business glossary | None: the only glossary in the project is a page of documentation terminology. Business vocabulary is not something Gravitino models, which is the clearest single sign it is a metastore rather than a catalog built for people |
| Quality checks | None: no tests, expectations or assertions anywhere. Table and partition statistics are collected and served, but nothing evaluates them |
| Custom metadata | Properties on every object, tags that inherit downward, and custom policies whose rules Gravitino stores and serves without interpreting. Deeper, both the catalog provider interface and the authorization plugin interface are open, the docs note the pushdown interface is not specific to Ranger, which is simply the only implementation shipping |
| Connections | |
| Connectors | Fifteen catalog providers, each a live connection rather than a scraper, Hive, Iceberg, Hudi, Paimon and a generic lakehouse; MySQL, PostgreSQL, Doris, StarRocks, Hologres, OceanBase and ClickHouse over JDBC; filesets over any Hadoop-compatible filesystem; Kafka topics; and models. OceanBase and ClickHouse ship in catalogs-contrib rather than the release tarball |
| Access | |
| Policy and compliance | Two mechanisms, both unusual here. Access control is ownership plus privileges collected into roles and granted downward, deny-by-default, with an explicit DENY beating any ALLOW, and authorization pushdown writes those grants into Apache Ranger so the engine enforces them at the data. Separately a policy is a named rule set attached to an object and inherited downward, either a built-in type Gravitino acts on or a custom one it stores and serves back to your own enforcement system |
| Access requests | None: no request, approval or grant workflow. A privilege is granted through the API by someone who already holds the right to grant it, and asked for however the organisation already asks |
| Cost | |
| Billing unit | Nothing to pay: an ASF project with no commercial edition of its own, one of two such rows here. Datastrato sells an enterprise distribution around it, with hardened images, LDAP and SCIM and support tiers, but that is a distribution rather than a hosted service |
vs Apache Gravitino: Commercial · Self-hosted · Managed · Subscription
vs Apache Gravitino: Commercial · Managed · Serverless · Subscription · Operational complexity: Low
vs Apache Gravitino: Operational complexity: High