Can a Data Catalog Sit Atop Existing Catalogs Without Replacing?

---

Yes. A data catalog can sit on top of existing catalogs without replacing them, as long as it reads metadata from each platform catalog and leaves the data, the table registrations, and access enforcement where they already live. The pattern is called a catalog of catalogs, a meta-catalog, or a federated data catalog: one layer for search, definitions, and lineage across the stack, while each native catalog keeps doing its own job.

---

What is a catalog of catalogs, and what does it leave alone?

A catalog of catalogs is a metadata layer that connects to the catalogs you already run and builds one index across them. Say your warehouse tables are governed in Snowflake Horizon, your lakehouse tables in Databricks Unity Catalog, your S3 tables in the AWS Glue Data Catalog, and your Fabric, Power BI, and Azure assets in Microsoft Purview. The layer on top reads from all four through their APIs. The data does not move. The tables stay registered where they are.

The usual design is hub and spoke. The hub holds what has to be consistent across the company: business definitions, ownership, classifications such as PII, and lineage that crosses tool boundaries. The spokes, the platform catalogs, register physical tables, run queries, and check access at query time.

A platform catalog is the enforcement point inside its own platform, and nothing on top should try to take that over. What the hub adds is everything a single platform cannot see. A platform catalog often does not see what a BI dashboard metric means to finance, which job outside the platform fed a table, or who signed off on the revenue definition.

So ask any vendor which metadata the overlay reads, which it writes back, and which it leaves untouched.

---

Don’t the platform catalogs already federate with each other?

Partly. The big platform catalogs now federate tables from other catalogs:

Platform catalog	What it federates	Where access is checked	Sync
Glue Data Catalog	Remote Apache Iceberg tables from Unity Catalog, Polaris, and other Iceberg REST catalogs, “without moving or duplicating” them (added 26 November 2025)	AWS Lake Formation, the authorization layer	Latest table metadata fetched from the remote catalog at query time
Unity Catalog	External catalogs such as external Hive metastores, Snowflake, OneLake, and Salesforce Data 360, crawled into a foreign catalog	Unity Catalog, which checks access and audits; read-only for external sources	Metadata refreshed at query time, or on a REFRESH FOREIGN schedule
Snowflake Horizon	External catalogs such as Unity Catalog and Glue, as linked databases	Horizon’s centralized access policies and masking	Snowflake’s May 2026 example uses a 30-second sync interval

Microsoft Purview scans metadata from other platforms rather than federating their tables. Its Data Map source list includes Azure Databricks Unity Catalog and Snowflake, both with data lineage.

Open standards make this possible. The Iceberg REST catalog specification gives engines a shared API, and Apache Polaris, an open catalog for Iceberg, graduated to an Apache top-level project in 2026.

Two limits matter for the replacement question. First, each platform federates toward itself. Federate Snowflake into Unity Catalog and Unity Catalog becomes the hub. Federate Unity Catalog into Horizon and Horizon becomes the hub. A company on three platforms can end up with three hubs, each claiming the center.

Second, platform federation centers on table access. Snowflake’s Horizon post does add semantics, lineage, and ownership to its hub, but that hub is still one vendor’s platform catalog. The Azure Databricks docs also note that features such as data quality monitoring and AI Search are not available on Hive metastore foreign tables, and that performance can be marginally worse because two catalogs sit on the query path.

---

Which catalog should own which metadata?

Before you connect anything, decide which system is authoritative for each type of metadata.

Metadata or job	Platform catalog (where the tables are registered)	Catalog on top
Table registration and schemas	Owns it	Reads it
Access checks and masking at query time	Enforces it	Sets policy intent, pushes tags back
Lineage inside one platform	Captures it	Reads it
Lineage across platforms, pipelines, and BI	Sees only what is federated into it	Owns it
Business glossary and metric definitions	Partial, per platform	Owns it, links terms to columns
Ownership and stewardship	Partial	Owns it, often fed by the identity system
Search across the estate	Its own platform plus federated catalogs	Owns it
Classification tags such as PII	Enforces locally	Curates once, syncs to each platform

The enforcement row keeps access checks in the native catalog, because it sits on the query path and the layer on top does not. The Azure Databricks docs describe that role for Unity Catalog: it “provides the governance layer, performing functions such as access control checks and auditing” (source).

The classification row says a tag gets curated once and written back to every platform, so each platform’s masking rules act on the same label.

If your overlay can only read, the table collapses into a search index, and you keep maintaining tags by hand in every platform. Ask for write-back per platform and per metadata type before you sign. For other ways catalogs drift and stall, see these data catalog challenges.

---

How do you add a catalog on top without a migration?

A typical sequence:

1. Pick one scope: one domain, one platform, or one analytics team.
2. Connect read-only first. Harvest schemas, technical metadata, and query history from each platform catalog through its API. Keep human input for meaning, such as definitions and owners.
3. Write down one owner system for each metadata type: table registration, access checks, lineage, glossary terms, ownership, and classification tags.
4. Link glossary terms to physical columns. An unlinked glossary is only a reference list.
5. Turn on write-back for tags and descriptions. Start with sensitive-data classifications, because a mismatch there becomes a compliance finding.
6. Measure coverage per platform: the share of priority assets with an owner, a description, lineage, and a classification.

Start with working connectors and named owners on a small set of high-value assets. Then add cross-tool lineage, glossary terms, and a refresh schedule, and expand where usage pulls you; failed searches show where curation is missing.

Watch for drift. When two systems run separately, owners go stale and lineage stops at the platform boundary. Unity Catalog refreshes foreign-table metadata at query time and recommends a scheduled REFRESH FOREIGN job for foreign tables accessed by external engines (source). The layer on top needs the same discipline: a sync schedule per connector, and an alert when one fails.

The data catalog best practices guide covers adoption and ownership in more depth.

---

When does a catalog on top not make sense?

If all your data sits in one platform, the native catalog may be enough. A team on one warehouse, with a handful of people querying it, can get far with consistent naming, column comments in the warehouse, and transformation docs.

The case for a layer on top gets stronger with each of these signals:

• Data spans two or more platforms, each with its own catalog.
• One classification, such as PII, must mean the same thing and mask the same way on every platform.
• Lineage questions cross platform boundaries, such as a dashboard number traced to a table in another catalog.
• AI agents need definitions and ownership, as well as table schemas, to answer business questions correctly.

There is a middle path. If your platforms all use Iceberg, platform federation through the open Iceberg REST specification may cover table access on its own. You then add a layer on top for definitions, lineage, and ownership only.

Price in the operating effort. A catalog on top needs owners, a refresh schedule, and someone who settles disputes over definitions. If nobody owns the revenue definition today, a new layer will show the disagreement more clearly. It will not settle it. For how a catalog relates to the storage platforms underneath it, see data catalog vs data warehouse.

---

How does Atlan sit on top of existing catalogs?

Atlan connects to the platform catalogs a team already runs and syncs metadata in both directions, so each native catalog stays the enforcement point.

With Databricks, Atlan’s Unity Catalog page states that “tags and policies flow both ways”: a classification curated in Atlan lands on the Unity Catalog object as a tag and drives masking inside Databricks, and a tag applied in Databricks appears in Atlan. With Snowflake, Atlan imports Snowflake tags and can reverse-sync tag updates back. On AWS, the SageMaker Unified Studio documentation lists bidirectional metadata synchronization between Amazon SageMaker Catalog and Atlan, including glossary terms and descriptions.

Fox runs its stack this way. Oliver Gomes, VP Analytics & Strategy at Fox, is quoted on Atlan’s Context Lakehouse page:

“We have Atlan as the metadata plane across our tech stack, independent of where technology is. We have one place to define the data, understand what it means, and where it comes from.”

One limit to know before a pilot: reverse sync updates tags that already exist in the platform. For Databricks, the docs say it “neither creates nor deletes any tags in Databricks”, and the Snowflake docs say the same for Snowflake tags. Create the tag in the platform first, then govern it from Atlan.

---

FAQs about catalogs on top of existing catalogs

Is a catalog of catalogs the same as a federated data catalog?

Mostly, yes. Both names describe one metadata layer that indexes several underlying catalogs without moving data. Some teams use “federated catalog” more narrowly, for a platform feature that lets one engine query tables registered in another catalog, such as Unity Catalog foreign catalogs. A catalog of catalogs usually covers definitions, ownership, and cross-tool lineage as well.

Does a catalog on top move or copy my data?

No. It reads metadata, such as schemas, tags, lineage, and query history, through each platform’s API. The data stays in your warehouse, lakehouse, or object storage, and the tables stay registered in their native catalog. Some products cache metadata to make search fast, so ask where that cache lives and how often it refreshes.

Will it conflict with Unity Catalog or Snowflake Horizon permissions?

It should not, if each type of metadata has one owner system. Access checks and masking stay in the native catalog because it sits on the query path. The layer on top curates tags and policy intent once and writes them back, so each platform enforces the same label. Conflicts usually come from two systems both editing the same tag by hand.

Can Iceberg REST federation replace a separate catalog layer?

For table access, often yes. Glue can now read Iceberg tables from Unity Catalog and Polaris through the Iceberg REST API, and Horizon can link Unity Catalog and Glue. Each federates toward its own platform, so definitions, lineage, and ownership end up in whichever platform catalog is the hub. Teams with more than one platform usually keep federation for queries and add a layer for context.

How long does it take to add a catalog on top of existing catalogs?

Connecting the first platform catalog is the quick part. The slower work is agreement: who owns each definition, which classification scheme applies, and which system wins on each field. Plan a first phase for one scope with named owners, then a second for cross-tool lineage, glossary terms, and write-back of tags.

---

Sources

1. The Metadata Hub: Unify Your Data Estate, Snowflake Blog
2. Catalog federation, Azure Databricks documentation (Microsoft Learn)
3. Introducing catalog federation for Apache Iceberg tables in the AWS Glue Data Catalog, AWS Big Data Blog
4. Data sources that connect to Microsoft Purview Data Map, Microsoft Learn
5. Iceberg REST catalog specification, Apache Iceberg
6. Apache Polaris graduates to a top-level project, Apache Polaris blog (February 19, 2026)
7. Hive metastore federation concepts, Azure Databricks documentation (Microsoft Learn)
8. Atlan integration, Amazon SageMaker Unified Studio user guide, AWS documentation