Can I use apache/gravitino commercially?

Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is apache/gravitino still maintained?

Yes. The repository received new commits within the last day.

What programming language is apache/gravitino written in?

Mainly Java, according to GitHub's language statistics.

Apache Gravitino: federated metadata lake and Iceberg REST

At a glance

What is it?: Apache Gravitino is an Apache-2.0 metadata catalog written in Java that manages metadata in the systems where it already lives and exposes it through one model and API. The interesting part is the connector model and the Iceberg and Lance REST services; the weak part is that several headline features are still marked work in progress.
Who is it for?: Adopt Gravitino if you already run several metadata stores across regions and want one API plus an Iceberg or Lance REST endpoint in front of them, and if your team is comfortable with a Java server configured through conf/gravitino.conf. Do not adopt it if you need a single fully managed catalog today, if you run Windows build hosts (the README states Windows is not currently supported), or if you depend on AI model and feature tracking, which the README marks as WIP.
Can I use it commercially?: Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository received new commits within the last day.
What is it written in?: Mainly Java, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · August 8, 2026 · apache/gravitino

The problem Gravitino targets: metadata that lives in six places

Most data platforms end up with metadata scattered across systems that were never designed to talk to each other. A Hive metastore here, a MySQL or MariaDB instance holding table definitions there, object storage under S3, files under HDFS, and now Iceberg and Lance tables with their own catalog semantics. Each engine that needs to read those assets carries its own connector, its own identifier rules, its own notion of what a schema is. The README frames Gravitino as a federated metadata lake that "manages metadata directly in different sources, types, and regions." That word directly carries the design claim: Gravitino does not ask you to copy metadata into a central store and keep the copy in sync. It reads and writes the underlying systems through connectors, so a change made in Hive is visible through Gravitino without a replication job in between. The audience is infrastructure and platform engineers who own more than one of those systems, and who are tired of writing a new integration for every engine pair. It is not aimed at a single-team warehouse on one engine; if that is your situation, a plain Hive metastore or a managed catalog is less machinery.

How the federated model actually works

The architecture visible in the repository is a Java server with a pluggable catalog layer. The top level contains core/, server/, server-common/, common/, api/, catalogs/, catalogs-contrib/, clients/, plus per-engine modules: iceberg/, lance/, flink-connector/, spark-connector/, lineage/, authorizations/, mcp-server/ and maintenance/. The api/ module is the contract; catalogs/ holds the implementations that speak to the underlying systems; server/ hosts the process that serves the unified REST API. Two services are called out by name in the README: a native Iceberg REST catalog service and a native Lance REST catalog service. Those matter because they let existing engines point at Gravitino using protocols they already understand, rather than a Gravitino-specific client. The Trino integration is the same idea from the other direction: Gravitino ships a Trino connector for federated metadata access, and the README claims multi-engine compatibility "without modifying SQL dialects." The geo-distribution claim is the hardest to evaluate from the README alone. It states that metadata can be shared across regions and clouds, but the README does not document the replication or consistency model behind that, so treat it as a deployment property to verify against the docs site rather than something the repository front page explains.

Installing Gravitino and running a first server

There are two documented paths. The recommended one is the Docker Compose playground in the separate apache/gravitino-playground repository, which the README describes as a full-stack experience; clone that repository and follow its README. The other path is a binary release. The README says to download and extract a binary release from the downloads page, edit conf/gravitino.conf to configure settings, then start the server with the script in bin/. The command below is the one the README gives for starting and stopping:

bash

./bin/gravitino.sh start
./bin/gravitino.sh stop

After start, the server process is running with the configuration you placed in conf/gravitino.conf. The README does not print the default port in the quick start, so read the configuration file for the HTTP endpoint rather than assuming one. There is also a UI switch. Gravitino uses the Web V2 UI by default, and the README documents a fallback to the legacy v1 UI through an environment variable, either set in conf/gravitino-env.sh or exported before starting:

bash

export GRAVITINO_USE_WEB_V2=false
./bin/gravitino.sh restart

Setting GRAVITINO_USE_WEB_V2 to true selects Web V2 explicitly. If you build from source instead, the project uses Gradle and the README gives these targets:

bash

./gradlew clean build -x test
./gradlew compileDistribution -x test
./gradlew assembleDistribution -x test

Artifacts land in the distribution/ directory. The README states that Windows is not currently supported for building, which rules out Windows build agents. There is also a -PskipWebBuild=true flag documented for skipping both Web UI builds when you only want the server.

Where Gravitino is the wrong tool

The README's own feature list contains the caveat that matters most: AI asset management, meaning AI model and feature tracking, is marked WIP. If model lineage is the reason you are evaluating a catalog, this is not a shipped capability in the documentation available. The second limitation is platform. The build section states plainly that Windows is not currently supported, and the build tooling is Gradle with a shell wrapper, so a Windows-only engineering team is out before installation. Third, the direct-integration model is a trade-off, not a free win. Because Gravitino reads and writes the underlying systems rather than owning a copy, its availability and behaviour depend on those systems. The README does not document what happens when a backing metastore is unreachable, whether catalog operations degrade or fail, or how partial failures surface through the unified API. That is a real gap for anyone planning an outage story. Fourth, the repository carries a large surface area: separate LICENSE and NOTICE files for iceberg, lance, trino and the binary distribution, plus modules for Flink, Spark, lineage, authorization and an MCP server. That breadth is useful if you need it and a maintenance burden if you do not, because a self-hosted deployment means you own upgrades of the server and every connector you enable.

Gravitino compared with Apache Polaris

Polaris is the natural comparison point, and the difference is in scope rather than in quality. Polaris is built around the Iceberg REST catalog specification: it is a catalog implementation that Iceberg clients talk to. Gravitino also exposes an Iceberg REST catalog service, but that service sits on top of a broader federation layer whose stated job is managing metadata in Hive, MySQL, MariaDB, HDFS and S3 alongside Iceberg. So the practical question is how many non-Iceberg sources you have. If every table you care about is Iceberg and your engines all speak the Iceberg REST protocol, a narrower catalog is less to operate, and you avoid the connector matrix entirely. If you have a Hive metastore, a relational metadata store and object storage that all need to appear under one API, Gravitino's federated model is the reason to pick it, and the Iceberg REST service becomes one endpoint among several rather than the whole product. The README does not publish a migration path between the two, so treat any switch as a fresh catalog wiring exercise.

Licence, release cadence and the cost of staying current

Gravitino is licensed under the Apache License, Version 2.0, and the LICENSE file is in the repository root. The distribution bundles components under their own terms: the repository carries LICENSE.iceberg, LICENSE.lance, LICENSE.trino, LICENSE.bin and matching NOTICE files. If you redistribute a built distribution, those files are the ones to read, and the ASF trademark note at the bottom of the README lists Apache Gravitino, Hive, Iceberg, Kafka, Spark, Submarine, Thrift and Zeppelin as Apache Software Foundation trademarks. This is a description of what the repository contains, not legal advice; get your own review before redistributing. On cadence, the recent releases are v1.1.1 on 2026-04-01, v1.2.1 on 2026-05-12 and v1.3.0 on 2026-06-29, and the last push to the default branch was on 2026-06-29. That is roughly a release every six to eight weeks across the visible window, which is a real upgrade cost: a self-hosted server plus whichever connectors you enable means reading release notes before each bump. The README does not document a rollback procedure or a compatibility guarantee between server and connector versions, so pin versions and keep the previous distribution until the new one is verified in your environment.

Editorial conclusion

Adopt Gravitino if you already run several metadata stores across regions and want one API plus an Iceberg or Lance REST endpoint in front of them, and if your team is comfortable with a Java server configured through conf/gravitino.conf. Do not adopt it if you need a single fully managed catalog today, if you run Windows build hosts (the README states Windows is not currently supported), or if you depend on AI model and feature tracking, which the README marks as WIP. Verify first: which catalogs your release actually ships (the repository has catalogs/ and catalogs-contrib/, and the split matters), whether the v1.3.0 release notes list the connectors you need, and whether the legacy v1 UI is required for your tooling before you flip GRAVITINO_USE_WEB_V2.

Frequently asked questions

What is Apache Gravitino?

It is an Apache-2.0 metadata catalog written in Java that the README describes as a high-performance, geo-distributed and federated metadata lake. It manages metadata in the underlying sources through connectors and exposes it through a single model and API.

What is Gravitino used for?

The README lists federated metadata discovery across data lakes and warehouses, multi-region metadata synchronization for hybrid or multi-cloud setups, governance with unified audit and access control, and plug-and-play access for engines such as Trino and Spark.

Does Gravitino support the Iceberg REST catalog?

Yes. The README states that Gravitino provides a native Iceberg REST catalog service and links to the Iceberg REST service page in the documentation. It also provides a native Lance REST catalog service.

Can I build Gravitino on Windows?

No. The build section of the README states that Gravitino uses Gradle and that Windows is not currently supported.

How do I install and start Gravitino?

The README recommends the Docker Compose playground in the apache/gravitino-playground repository. Otherwise, download and extract a binary release, edit conf/gravitino.conf, then run ./bin/gravitino.sh start and stop it with ./bin/gravitino.sh stop.

Official sources

Community notes