Catalog and lakehouse
The catalog is the control plane of the data platform. It is the single place to answer what data exists, who owns it, what it is made of, where it came from, what will break if you change it, and who may reach it, with the answer scoped to a workspace and carried across cells.
Underneath it sit open lakehouse table formats as first-class citizens, so the governance is ours and the storage format is not proprietary.
The catalog
| Page | What it covers |
|---|---|
| The catalog and lineage | The three-level namespace over every engine, the metadata every asset carries, contracts enforced on write, quality scoring, deny-by-default lineage capture, domains, catalog operations, and the four co-equal ways it spans cells |
| The ontology | Object, link and action types over catalog assets, with staged changes under review, verified evolution chains, signed bundles, and SDK emitters that turn the model into typed client code |
| Environments and promotion | Moving catalog objects between environments as a signed, sealed, reviewed bundle with a promotion ledger and contract validation |
| Catalog interoperability | OpenMetadata-compatible endpoints for the metadata tooling a customer already runs, with enumeration filtered by need-to-know so the surface never advertises a table the caller could not query |
| Search and discovery | Full-text, faceted and hybrid search kept current by background workers, quality-aware ranking, and visibility that respects classification |
The lakehouse
| Page | What it covers |
|---|---|
| Lakehouse tables | Delta and Iceberg as co-equal open formats, format neutrality as a deployment policy, and zero-copy reads over object storage |
| The virtual graph | A zero-copy property graph projected over the lakehouse, queryable in GQL, including over external tables read in place |
| Open sharing | Delta Sharing and the Iceberg REST catalog, governed the same way, where a share is not an export |
Why the catalog is the interesting half
Most platforms have a catalog that describes the data and a policy layer that guards it, with a gap between them that a determined caller can step through.
Four properties close that gap here.
- The namespace is complete across engines. An asset is not only a SQL table. It can be a view, volume, function, connection, model, stream, structure, graph, vector space or document collection, so nothing lives outside the catalog's reach.
- Contracts are enforced on write. An operation that would violate an active data contract is blocked, rather than the violation being discovered later in a report.
- Lineage capture is guarded at the write boundary. A mutation that cannot be captured leaves a durable coverage gap by default and can be configured to be rejected outright, so a non-covered tool cannot silently evade capture.
- The catalog and the directory replicate together, so a cell resolves the asset, the entity and the grant locally and compiles policy into the plan without reaching for a remote service.
Related topics
- Data governance, the enforcement plane the catalog feeds.
- The semantic layer, metric definitions authored once over catalog assets.
- Data products, a curated asset with typed ports and a contract.
- Platform replication, how the catalog and directory actually cross cells.