Architecture and Concepts
Datastrato Enterprise manages metadata where it already lives. Rather than crawling source systems on a schedule and holding a copy, it connects to each source and reads and writes through to it. A table created through Gravitino exists in the underlying metastore immediately, and a table created directly in that metastore is visible without waiting for a scan.
The result is one addressable surface over metadata that is spread across lakehouses, metastores, relational databases, object storage, message queues, and model registries, without that surface becoming a second copy that drifts from the first.
Architecture
Interface layer. A REST API, with Java and Python clients over it, plus a CLI, an MCP server for AI tools, and the administration UI.
Governance layer. Tags, policies, access control, and lineage, applied across every connected source rather than per source.
Object model. One representation of metadata regardless of where it comes from, so a table in Hive and a table in PostgreSQL are the same kind of object to a caller.
Connection layer. A connector per source type, translating between the object model and what that system natively speaks.
Engines reach data through this stack rather than around it. Trino, Spark, Flink, and any client speaking the Iceberg REST protocol resolve metadata through Gravitino, which is what makes governance enforceable rather than advisory.
Terminology
| Term | Meaning |
|---|---|
| Metalake | The top-level container. Usually one per organization or tenant, holding all its catalogs |
| Catalog | A connection to one metadata source, with a connector appropriate to that source |
| Schema | The second namespace level, mapping to a database or schema in relational sources and to a logical grouping elsewhere |
| Table | A relational table in a catalog that supports them |
| View | A stored query definition |
| Fileset | A collection of files and directories, for data that is not tabular |
| Topic | A message queue topic, in catalogs that support them |
| Model | An ML model and its versions, in catalogs that support them |
| Function | A user-defined function, exposed to engines that can call it |
Names resolve as catalog.schema.object within a metalake.
Federation
A catalog can front another catalog rather than a storage system directly. An Iceberg REST catalog in one region can proxy to one in another, so callers see a single namespace across regions or clouds without data being copied between them.
This extends to catalogs you do not own. A Glue catalog or a vendor's Iceberg REST endpoint can be connected alongside your own, and governed by the same tags and policies.
Multiple Engines
Gravitino does not process queries. Engines do, and they reach it in one of two ways.
A native connector, for Trino, Spark, Flink, and Daft, loads catalogs from Gravitino directly and gives the engine the full object model.
The Iceberg REST protocol serves anything that speaks it, including Doris, StarRocks, PyIceberg, and Ray, without a connector.
Either path enforces the same access control, so a policy written once applies regardless of which engine a user reaches the data through.
Data and AI Assets
Filesets and models are first-class objects rather than an afterthought. Training data, feature sets, and model versions are cataloged, tagged, and governed the same way tables are, which matters when the same governance obligations apply to a training corpus as to a warehouse.