Knowledge Catalog and Atlan: How They Work Together

What Knowledge Catalog and Atlan Deliver Together: At a Glance

Google renamed Dataplex Universal Catalog to Google Knowledge Catalog on April 10, 2026. Google’s wording is that “the API, client library, CLI, and Identity and Access Management (IAM) names remain unchanged,” and the endpoint is still dataplex.googleapis.com, so this page says Knowledge Catalog for the product and keeps Dataplex for the API, the connector, the URL slugs and the billing SKUs. Google’s own pricing page is explicit: “Pricing SKUs will remain named as Dataplex.” Note the name is shared: IBM sold a product called Knowledge Catalog until May 2025 and its docs still use the name, so say Google Knowledge Catalog when the two could be confused. Google also names Atlan on its own Knowledge Catalog product page, which says the product “supports integrations with third-party databases and partner catalogs like Ab Initio, Anomalo, Atlan, Collibra, and Datahub.” Sources: Knowledge Catalog overview and Knowledge Catalog pricing, both verified 2026-09-16.

At a glance: Knowledge Catalog vs Atlan vs Knowledge Catalog + Atlan

---

What Does Google Cloud Knowledge Catalog Provide?

Google Cloud Knowledge Catalog unifies metadata management for data and AI assets within the Google Cloud Platform ecosystem. The service automatically ingests technical metadata from BigQuery, Cloud Storage, Spanner, Vertex AI, Pub/Sub, Dataform, and Dataproc Metastore without requiring manual configuration.

The platform operates on three core metadata constructs:

• Entries represent individual data assets like BigQuery tables or Cloud Storage buckets. Each entry carries system-generated technical metadata including schema definitions, data types, and resource identifiers.

• Aspects attach structured business or governance metadata to entries. Organizations define custom aspect types to capture classifications, ownership information, data quality standards, or compliance tags.

• Entry groups organize related entries by project, location, or business domain. These groupings support federated governance models where different teams manage their own data domains while maintaining centralized visibility.

Data Lineage in Knowledge Catalog

Knowledge Catalog automatically captures job-level and column-level lineage for BigQuery operations including CTAS, INSERT, MERGE, and VIEW definitions. Lineage from external tools like dbt and Airflow can be ingested via the OpenLineage-based Data Lineage API, though this is limited to table-level events. Lineage metadata is retained for 30 days and can take up to 24 hours to appear after job completion.

Data Quality in Knowledge Catalog

Knowledge Catalog includes built-in data quality scanning for BigQuery assets through Data Quality rules and Data Metric Functions. Quality scan results surface directly as catalog metadata, making freshness, completeness, and rule pass rates visible alongside the asset’s technical metadata.

Governance in Knowledge Catalog

Governance in Knowledge Catalog is enforced through Google Cloud IAM and policy tags. Policy tags applied to BigQuery columns control access at the field level. Tags and classifications are scoped to GCP assets and do not automatically propagate to systems outside the Google Cloud perimeter.

Knowledge Catalog Limitations

Three practical limitations constrain Knowledge Catalog for enterprise use:

1. Coverage is documented around Google Cloud, with federation at the edges: Google documents Iceberg REST federation for Databricks Unity, AWS Glue and Snowflake Horizon, all in Preview, and announces SaaS context federation for SAP, Salesforce Data360, Workday, Palantir and ServiceNow on its blog. Google’s own caveat on the same overview is the boundary that matters: “While Knowledge Catalog supports major third-party systems, certain automated semantic extractions might be limited to built-in Google Cloud services.” A registered asset is not yet a described asset, and for anything outside that set teams extend lineage through the API using OpenLineage.

2. Business context is a separate workflow: Knowledge Catalog documents glossary terms, term-to-column links and Gemini-derived descriptions, all generated from metadata Google Cloud already holds. Google’s documentation covers those objects; what it does not document is a collaboration surface where two teams argue a definition to agreement, or automatic propagation of business metadata along a lineage path. Those stay separate processes.

3. The console assumes Google Cloud fluency: Knowledge Catalog’s interface is organized around Google Cloud concepts, projects, entries, aspect types and IAM roles that still carry dataplex.* names. That fits the engineers who run the estate. Business stakeholders arriving to look up what a number means meet the platform’s vocabulary first.

---

---

How Does Atlan Extend Knowledge Catalog Capabilities?

Atlan sits above Knowledge Catalog as a sovereign enterprise context layer, ingesting its metadata alongside metadata from every other system in the stack, enriching it with business context, and activating it for both human teams and AI agents across the full data estate.

Think of Atlan as a federated, interoperable, multi-platform control plane, where Knowledge Catalog continues to govern GCP assets natively. Atlan extends that across the heterogenous stack of cloud platforms, BI tools, ETL tools, SaaS solutions, and AI agents.

Automated, Column-Level Lineage Across Platforms

Atlan stitches column-level lineage across every connected system into a single continuous enterprise data graph, connecting upstream sources through GCP transformations to downstream BI tools. Where Knowledge Catalog provides column-level lineage for BigQuery and table-level lineage for external sources, Atlan closes that gap across dbt, Airflow, Fivetran, Tableau, Snowflake, and Databricks without requiring custom connector development.

That same lineage graph powers:

• Root cause analysis when data quality issues surface, tracing problems back through the pipeline to their origin.

• Impact analysis before upstream changes are made, identifying every downstream asset and AI workflow that will be affected.

A Collaborative Workspace Driving Adoption Across Personas

Atlan embeds collaboration directly into the asset record: annotations, discussion threads, review workflows, and ownership assignments tied to specific tables and columns.

Persona-based experiences surface different views of the same metadata depending on who is asking, so data engineers, business analysts, compliance teams, and domain owners all work from the same governed layer without needing to navigate a technical interface designed for one audience.

Atlan’s platform also includes data products that package related datasets with documentation, quality SLAs, and access request workflows. This abstraction helps business teams discover and request data without understanding underlying technical complexity.

Automated Governance at Scale

Atlan’s automation engine continuously enriches metadata with AI-generated descriptions, classifications, ownership assignments, and policy tags. Governance decisions made in Atlan propagate bidirectionally to Knowledge Catalog and every other connected system, eliminating the manual synchronization that produces drift between the central catalog and individual platforms.

AI-Native Architecture

Atlan exposes metadata through a Model Context Protocol (MCP) server that AI agents consume directly. This enables intelligent operations like natural language search (“find all customer revenue metrics updated in the last week”), automated documentation generation, and proactive data quality monitoring that flags issues before users encounter them.

As a result, AI agents operating across GCP, Snowflake, and Databricks simultaneously consume the same governed context layer, grounded in authoritative definitions rather than raw schemas.

Context Lakehouse as the Open Context Store

The Context Lakehouse underneath Atlan stores all context in an open, queryable format.

It is Iceberg-native: lineage, governance policies, quality signals, glossary definitions, and usage patterns all live in Apache Iceberg tables, with ACID transactions, schema evolution, and time travel. Any Iceberg-compatible engine reads it with standard SQL, including BigQuery, Spark, Trino, Snowflake, and DuckDB. A metadata knowledge graph sits over that storage, so relationships between assets stay traversable rather than being flattened into rows.

Because the storage is an open table format rather than a proprietary data model, any tool in your stack queries it directly, and the context stays yours regardless of which platforms sit on top.

Data Quality Across the Full Stack

Atlan aggregates data quality signals from the built-in Knowledge Catalog quality scans alongside quality metrics from dbt tests, observability tools, and external monitoring platforms with the Data Quality Studio.

Quality scores, freshness indicators, and rule pass rates surface alongside asset metadata across every connected system, not just BigQuery. This gives data teams and AI agents a consistent, cross-platform view of data fitness rather than fragmented quality signals that vary by platform and require manual reconciliation.

Deep, Two-Way Integration With GCP

Atlan maintains bidirectional synchronization with Knowledge Catalog, meaning metadata, tags, classifications, and policies flow in both directions. Knowledge Catalog governs GCP assets natively. Atlan ingests that metadata, enriches it, and syncs changes back, keeping both systems consistent without manual intervention. This makes the two platforms complementary by design rather than competing for the same governance role.

---

How Does the Knowledge Catalog Integration Work?

The integration operates through a combination of direct API connections and automated enrichment packages that move metadata between the two platforms in near real-time.

The names in this section still say Dataplex, and that is correct. Google renamed the product, not the plumbing: the IAM permissions, the API, the endpoint, and Atlan’s connector and Solutions packages all kept their original names.

Step 1: Initial Connector Setup

Teams configure authentication by creating a custom IAM role in Google Cloud with specific Dataplex permissions including dataplex.entries.list, dataplex.entries.get, dataplex.aspectTypes.list, and dataplex.aspectTypes.get. A service account assigned this role generates a JSON key that Atlan uses for read-only metadata access.

In Atlan’s interface, administrators navigate to Data Governance connectors and select Google Cloud Dataplex. They upload the service account key, specify GCP regions where aspects and entries exist, and optionally filter by BigQuery connection to control which metadata gets ingested.

The crawler runs on schedule or on-demand, extracting all Dataplex entries and their associated aspects. Results appear in Atlan’s asset search within minutes, tagged with Dataplex-specific metadata fields.

Step 2: Aspect Metadata Surfacing

Dataplex aspects become first-class metadata in Atlan’s interface. Users can filter global asset searches by aspect name, aspect key, or aspect value. On individual asset pages, a dedicated Dataplex metadata section displays all aspects associated with that entry, with additional filtering capabilities for detailed inspection.

The aspect structure defined in Dataplex translates directly to searchable, actionable metadata in Atlan.

Step 3: BigQuery Enrichment Packages

For deeper integration with BigQuery workflows, teams deploy Solutions packages that attach Dataplex metadata directly to BigQuery assets in Atlan. The Dataplex Enricher executes custom Dataplex queries to extract specific field values and creates or updates custom metadata structures in Atlan.

Configuration requires providing the GCP organization ID, service account JSON, a Dataplex query specifying which tags to extract, the target BigQuery connection in Atlan, and a list of Dataplex fields to load. The package optionally propagates metadata from schemas down to tables, views, and materialized views.

The Dataplex Custom Metadata Enricher focuses specifically on data quality results. It retrieves scan outputs from the BigQuery table where Dataplex publishes quality metrics and attaches scores, rule statistics, and pass/fail indicators as custom metadata on the relevant BigQuery columns in Atlan.

Both packages run on configurable schedules, keeping Atlan’s BigQuery metadata synchronized with the latest Dataplex scans and classifications.

Step 4: Cross-Platform Lineage Stitching

Once Dataplex metadata flows into Atlan, the platform stitches it with lineage from other connected sources. Atlan’s lineage engine combines BigQuery’s native lineage (captured by Dataplex) with transformation logic from dbt and consumption patterns from BI tools to build the complete end-to-end view.

This integration model preserves Dataplex as the authoritative source for GCP-native metadata while extending visibility into the broader data ecosystem. Teams benefit from both platforms’ strengths without maintaining duplicate governance definitions or manual synchronization.

---

Who Needs Both Knowledge Catalog and Atlan?

Organizations running Google Cloud infrastructure benefit from the native Knowledge Catalog integration with BigQuery and other GCP services. Those with any of these conditions should evaluate adding Atlan as the enterprise metadata layer:

1. Multi-Cloud or Hybrid Data Estates

Teams operating across GCP, AWS, and Azure need one governance record that holds the same meaning in every one. Knowledge Catalog now federates beyond Google Cloud: Google documents Iceberg REST federation for Databricks Unity, AWS Glue and Snowflake Horizon, all in Preview. “Native means single-cloud” stopped being true in April 2026. The gap that remains is the one Google states itself, that certain automated semantic extractions might be limited to built-in Google Cloud services, so a warehouse in BigQuery, a CRM in Salesforce and an on-premise Oracle estate end up described to different depths.

CME Group faced exactly this challenge. Operating one of the world’s largest derivatives exchanges, they needed complete enterprise-wide lineage across cloud and legacy systems. Dataplex, as it was called at the time, provided strong coverage for their Google Cloud assets but left gaps in visibility to operational systems and trading platforms.

Source: Atlan

After implementing Atlan, they reduced implementation cycles from weeks to days while maintaining compliance across their complex data flows.

Source: Atlan

Modern Data Stack With Transformation Layers

Organizations using dbt to transform warehouse data hit a resolution gap. Google documents lineage captured from BigQuery query jobs, which records the relationship between tables. The dbt model name, its documentation and its transformation logic live in dbt’s own manifest, not in the query text, so an analyst reading table-level lineage sees that table_b depends on table_a without seeing that the relationship represents the customer_lifetime_value model and the business rules documented alongside it.

Atlan parses dbt’s manifest.json files to surface model-level lineage with full context. Users searching for “customer lifetime value” find both the dbt model definition and the downstream Tableau dashboard it feeds, all connected through column-level lineage.

BI-Heavy Workloads Requiring Business User Access

The Knowledge Catalog interface serves data engineers well but creates friction for business analysts and executives. Atlan’s business-friendly search and collaborative features address this directly. The same metadata lives in Knowledge Catalog, but Atlan’s presentation makes it accessible to non-technical stakeholders.

AI and ML Initiatives Requiring Governed Data

Machine learning teams building models on BigQuery data need to understand data lineage for feature engineering and track model dependencies for AI governance. Knowledge Catalog ingests Vertex AI assets alongside BigQuery, Spanner and Cloud Storage, so the model artifacts are catalogued in the same place as the tables.

Atlan’s AI lineage capabilities trace individual features back through transformation layers to source systems, enabling teams to debug model performance issues and ensure compliance for AI deployments. The platform’s MCP server lets AI agents consume this lineage metadata directly for intelligent operations.

Organizations Outgrowing Basic Cataloging

As data maturity increases, teams need data products with SLAs, access request workflows, and custom compliance reporting. These governance patterns require a programmable metadata platform. Atlan’s app framework enables teams to build custom workflows on top of the unified metadata layer while Knowledge Catalog continues serving as the authoritative source for GCP technical metadata.

---

---

Knowledge Catalog + Atlan: What Does a Typical Implementation Look Like?

Most organizations follow a phased approach that establishes Knowledge Catalog coverage first and then layers Atlan on top for cross-platform governance.

Phase 1: Enable Knowledge Catalog for GCP Assets (1-2 Weeks)

Teams start by activating Dataplex APIs for their GCP projects and defining aspect types for business classifications. They configure data quality scans for critical BigQuery tables and enable lineage capture for analytics workloads.

This phase focuses on getting clean technical metadata flowing from GCP services into Knowledge Catalog. Organizations define their taxonomy of aspects, document what each classification means, and establish governance roles for who can create or modify aspect definitions.

Phase 2: Deploy Atlan and Connect Non-GCP Sources (2-4 Weeks)

With Knowledge Catalog providing strong GCP coverage, teams deploy Atlan and configure connectors for their BI tools, transformation engines, and any data sources outside Google Cloud. This typically includes Tableau or Looker dashboards, dbt projects, and connections to Snowflake, Salesforce, or on-premise databases depending on the data architecture.

Atlan automatically discovers assets and builds lineage as soon as connectors authenticate. Teams see cross-platform data flows emerge within days without manual mapping.

Phase 3: Integrate Knowledge Catalog Metadata Into Atlan (1 Week)

The Dataplex connector configuration takes hours. Teams create the service account with appropriate permissions, configure the connector in Atlan, and run an initial crawl. Aspect metadata from Knowledge Catalog becomes searchable in Atlan’s unified interface immediately.

For organizations wanting deeper BigQuery integration, deploying the Dataplex Enricher and Custom Metadata Enricher packages adds 1-2 days for configuration and testing. These packages pull aspect field values and data quality results directly onto BigQuery asset pages in Atlan.

Phase 4: Establish Unified Governance Workflows (Ongoing)

With technical integration complete, teams shift to governance process design. They define data products that span GCP and non-GCP sources, establish glossary terms that apply consistently across platforms, and configure access request workflows that route appropriately whether data lives in BigQuery, Snowflake, or elsewhere.

This phase involves training different user personas. Data engineers learn to use cross-platform lineage for impact analysis. Business analysts adopt Atlan’s search interface for data discovery. Data governance teams define policies that enforce consistently across all connected systems.

Maintenance and Evolution

Once operational, the integration requires minimal maintenance. Knowledge Catalog continues ingesting GCP metadata automatically while Atlan connectors sync on configured schedules. Teams typically review aspect definitions quarterly to ensure they still meet business needs and audit unused metadata to keep the catalog lean.

As new data sources enter the ecosystem, teams simply configure additional connectors in Atlan. The unified metadata layer expands to accommodate new systems without disrupting existing governance processes or requiring changes to Knowledge Catalog configuration.

---

How Atlan’s Architecture Supports Google Cloud Deployments

Organizations committed to Google Cloud infrastructure can deploy Atlan entirely within their GCP environment. Atlan’s cloud-agnostic architecture runs on major cloud platforms including GCP, AWS, and Azure, allowing teams to host the metadata control plane wherever their data resides.

For GCP deployments, Atlan uses Google Kubernetes Engine for container orchestration and Cloud SQL for metadata storage. This keeps all data within Google Cloud’s infrastructure and supports compliance requirements for data residency.

The platform integrates naturally with GCP’s identity and access management through service account authentication. Teams reuse existing Google Cloud IAM policies rather than maintaining separate identity systems. Single sign-on through Google Workspace covers end-user access.

Networking configurations support both public internet access and private connectivity through VPC peering or Cloud Interconnect. Organizations with strict security requirements can deploy Atlan in a private subnet with no public endpoints, accessing the interface only through approved network paths.

Atlan’s Dataplex connector operates entirely through Google Cloud APIs using least-privilege service accounts. No data moves outside the GCP project boundary during metadata extraction. The connector reads Knowledge Catalog entries and aspects through standard GCP client libraries, maintaining Google Cloud’s security and audit posture.

For teams standardizing on BigQuery as their analytics warehouse, Atlan treats it as a first-class citizen. The BigQuery connector captures comprehensive metadata including datasets, tables, views, materialized views, stored procedures, and query history. Column-level lineage traces dependencies across BigQuery resources and extends to upstream ingestion tools and downstream BI dashboards.

For GCP deployments, the Context Lakehouse holds all of that as Apache Iceberg tables in your own Google Cloud Storage, which BigQuery reads directly. Teams query their context with the SQL tools and BigQuery workflows they already run. Custom compliance reports, usage dashboards, and governance metrics become ordinary SQL queries.

---

Real Stories From Real Customers: Unified Governance in Action

---

Frequently Asked Questions

Does Atlan replace Knowledge Catalog or do they work together?

Atlan and Knowledge Catalog work together in a complementary architecture. Knowledge Catalog remains the authoritative metadata source for GCP assets, while Atlan ingests that metadata and extends governance across non-GCP systems as the enterprise-wide metadata control plane.

How does lineage work between Knowledge Catalog and Atlan?

Knowledge Catalog captures lineage automatically for BigQuery query jobs within GCP. Atlan ingests this lineage and stitches it with column-level dependencies from dbt, Snowflake, Tableau, and other connected systems to show complete end-to-end lineage from source to BI dashboards.

Can I use Atlan if my data warehouse is BigQuery?

Yes. Atlan provides native BigQuery integration regardless of whether you use Knowledge Catalog. Organizations can use Atlan with BigQuery alone or enhance the setup by also ingesting Knowledge Catalog aspects and data quality results.

What happens to Knowledge Catalog aspects when they sync to Atlan?

Knowledge Catalog aspects become searchable metadata fields in Atlan’s unified catalog. Users can filter asset searches by aspect name, key, or value. The Dataplex Enricher package, whose name still follows the pre-rename product, optionally pulls aspect field values directly onto BigQuery assets in Atlan.

Do I need special GCP permissions to connect Atlan to Knowledge Catalog?

Yes. The integration requires creating a custom IAM role with specific Dataplex permissions including dataplex.entries.list, dataplex.entries.get, dataplex.aspectTypes.list, and dataplex.aspectTypes.get. The connector operates with read-only access and does not modify Knowledge Catalog metadata.

How much does the Knowledge Catalog integration cost?

Knowledge Catalog follows Google Cloud’s pay-as-you-go pricing, metered in Data Compute Unit hours. The billing SKUs are still named Dataplex, so look for that on the invoice. Atlan pricing operates separately with enterprise contracts. The integration itself requires no additional fees beyond configuring the standard Dataplex connector and optional Solutions packages included in Atlan subscriptions.

---

Why Knowledge Catalog and Atlan Are Better Together

Knowledge Catalog and Atlan are complementary layers in a governance architecture designed for how enterprise data actually moves.

Knowledge Catalog is the right foundation for GCP-native governance. It handles BigQuery lineage, data quality scanning, IAM-based access control, and metadata management for Google Cloud assets automatically and at low operational overhead. For organizations running exclusively on GCP, it is a strong and cost-effective starting point.

The gap emerges when data crosses the GCP boundary. Atlan addresses precisely those gaps, not by replacing Knowledge Catalog but by sitting above it as the enterprise metadata context plane. Knowledge Catalog continues governing GCP assets natively. Atlan ingests that metadata, stitches it with context from every other system in the stack, enriches it with business meaning, and activates it for human teams and AI agents through a single governed layer the enterprise owns.

Organizations implementing both platforms reduce time-to-insight, improve data quality through automated governance, and enable AI initiatives with comprehensive metadata context. The approach scales as data ecosystems grow more complex while maintaining consistent governance regardless of where data lives.

Book a demo