A Dataplex Alternative for Multi-Platform Teams: Knowledge Catalog vs Spellbook Data Catalog

If you're searching for a Dataplex alternative, you probably run more than Google Cloud. Google Knowledge Catalog (the new name for Dataplex Universal Catalog) is a very good inventory for BigQuery, Spanner, Pub/Sub and Cloud Storage. It harvests entries on its own, Gemini drafts descriptions through data insights, and lineage records itself for BigQuery and Dataflow jobs.

The seams show up in two places. The first is the rest of the estate: the dbt project, the self-managed Airflow, the Snowflake warehouse finance runs, the Databricks workspace the ML team lives in. The second is newer. Agents now write metadata as well as read it, and someone has to decide which AI-written text becomes the definition everyone relies on.

Knowledge Catalog is the inventory. Data Workers is the control plane. Data Context Wizard builds one governed context graph across Google Cloud and everything else. Spellbook Data Catalog, in preview today, is where your people review, approve, roll back and audit agent work on every platform. Knowledge Catalog records what your Google Cloud data is. Data Workers keeps the whole estate right.

A note on names: Google renamed Dataplex Universal Catalog to Knowledge Catalog on April 10, 2026. The API, client library, CLI and IAM names are unchanged, so you'll still see dataplex in your code, your roles and the pricing SKUs. For the platform-wide picture, read Data Workers on Google Cloud.

Key takeaways

• •Knowledge Catalog is a strong inventory for Google Cloud. Auto-ingest of GCP sources, the glossary, auto data quality, profiling and lineage are GA. Keep it for that.
• •Outside Google Cloud, its reach is mostly preview or one-way. Database connectors and federation with Unity Catalog, Glue and Snowflake Horizon are preview. The Snowflake connector is community-built. dbt import went GA on September 24, 2026, and it is one-way into Knowledge Catalog.
• •Its GA approvals govern data access, not meaning. Review of metadata changes to glossaries and entries is in private preview, and publishing Gemini data insights is a per-run choice.
• •Data Workers is the control plane across every platform. One context graph, 50+ connectors, 20+ specialist agents, and one approval flow with a receipt on every change.
• •Data Workers connects to Knowledge Catalog over its MCP servers today: your coding agent reads entries and lookupContext bundles and hands them to the graph. Nothing migrates.
• •Fixes land in code. An approved definition fix ships back to dbt as a doc change with a receipt.

What a Dataplex alternative should add: six things Data Workers gives you

1. One review inbox for every agent. Gemini, your coding agent and our 20+ specialist agents all propose changes. In Spellbook each proposal lands in one queue where your team approves, steers, sends back or rolls back.

2. AI-written metadata that stays a proposal until someone approves it. Data Context Wizard records AI-written definitions as proposed facts with their source and confidence. Promotion to authoritative needs a named human, and the check is enforced in code.

3. One definition across every platform. The Context Wizard imports MetricFlow, Databricks metric views and Cube definitions and lines up every variant of a metric with its source.

4. Lineage that crosses every hop. Google's lineage stays in Knowledge Catalog, and Data Workers joins your dbt manifest, Airflow DAG runs, Snowflake query history and the team's notes in one graph.

5. Fixes that land in code. An approved description fix ships back to dbt as a doc change (as a pull request once your team turns on the GitHub pull-request target). If your project uses dbt's persist_docs, the merged text reaches the BigQuery column, and Knowledge Catalog's dbt import brings it in on the next run.

6. A receipt on every change, with the diff, the approver, the time and the rollback path.

One definition, five systems

Here's how a wrong definition spreads in a mixed estate. It's an illustration, not a customer case.

• •Monday, 09:00. A dbt Cloud job changes the model behind fct_orders in BigQuery so net_amount excludes refunds. Knowledge Catalog's dbt import picks up the run artifacts that night.
• •Monday, 10:30. An analyst runs data insights on fct_orders and picks "Generate and publish". The Gemini description calls net_amount revenue including refunds, and it becomes searchable for everyone.
• •Tuesday, 02:00. The Snowflake finance mart, which applies its own refund rule, loads from the same source. Knowledge Catalog sees it only through preview federation, read-only.
• •Wednesday, 11:15. A coding agent answering a revenue question calls the Knowledge Catalog MCP server, pulls the published description with lookup_context, and reports a number that includes refunds.

Knowledge Catalog did its job: it found the table, described it and served the description. Nothing in the path asked whether the description matched the code before agents relied on it. Data Workers adds that step and keeps a record of who decided.

What Google Knowledge Catalog covers, as of October 2026

Google presents Knowledge Catalog as the context engine of what it calls the Agentic Data Cloud, with three pillars: aggregation, enrichment and search. Here's what its documentation and release notes say ships today.

That's a serious catalog for Google Cloud data, and Google is also retiring the legacy Data Catalog in phases from June 1, 2026, so most GCP teams will land on it.

One platform, not one more tool

Cataloguing is one job on a data team's list. The same team writes quality checks, runs incidents, changes pipelines, plans migrations, manages access, cuts spend and keeps the data under its models healthy. Each point tool adds another console, another contract and another handoff.

Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail. We score the same ten lifecycle stages on every comparison page. Knowledge Catalog leads on its home ground, catalog and context, and edges us on governance and access inside Google Cloud, where it grants IAM directly.

Knowledge Catalog vs Data Workers on the catalog outcomes you buy

This view narrows to eight outcomes a data leader buys from a catalog. Knowledge Catalog leads on two, both on its own surface: finding and scoring Google Cloud assets. We're even on lineage for Google Cloud jobs, because we read the same lineage. Data Workers leads on every outcome that spans the estate or involves agents changing things.

These are directional scores of scope, not benchmarks. The reasoning is shown so you can argue with any line.

Where Knowledge Catalog stops

Each limit below comes from Google's own documentation. None is a flaw. Google built Knowledge Catalog to make Google Cloud the center of gravity for your data and your agents, and a catalog built that way reads the rest of the estate as sources.

Outside Google Cloud, reach is mostly preview. The Oracle, MySQL, SQL Server and PostgreSQL connectors are preview. Snowflake and other community connectors are "not officially supported by Google". Federation with Unity Catalog, Glue and Snowflake Horizon is preview and read-side.

dbt import is GA and one-way. Since September 24, 2026, Knowledge Catalog imports dbt Core, Fusion and dbt Cloud runs. There's no direct connection to dbt Cloud: runs come in through artifacts, the dbt platform CLI or the Admin API with webhooks. Lineage covers BigQuery resources only, and nothing flows back into the dbt project.

Metadata leaves as events, for you to wire up. Change feeds push entry and aspect events to Pub/Sub, and Google lists syncing to external catalogs as a use. Export jobs and SAP BDC publishing exist too. Knowledge Catalog doesn't write definitions back into dbt, Snowflake or Databricks.

Lineage is short-lived and GCP-centered. Lineage is kept for 30 days. Other systems contribute through OpenLineage run events, with limits on message size and links per event.

AI context review is early. A person chooses "Generate and publish" or "Generate without publishing" each time data insights runs. Review of metadata changes to glossaries and entries through governance workflows is in private preview.

The approvals that ship are access approvals. Data products route access requests to approvers and grant IAM. That's the right control for who can see data. It isn't a review of what an agent changed about what the data means.

Why doesn't Knowledge Catalog just do this itself?

Because it's a Google Cloud service, built to be a deep inventory and context engine for data that lives in Google Cloud, and that focus is the right business decision. Its writes target its own entries, aspects and data products. Its enforcement runs through Google Cloud IAM. Its reach into Snowflake and Databricks is federation, which reads.

Running agent work across the estate is a different product. It needs blast-radius scoping before a change, an approval step a named person owns, rollback when a change is wrong, a receipt that records the diff and the approver, and context about every other system the change touches. It also means taking responsibility for proposed changes in tools Google doesn't own: a dbt doc change, a Snowflake grant drafted for its owner, a Unity Catalog grant applied after approval. A cloud provider has good reasons to stay out of that liability. That's the product Data Workers is, and it's why the two sit side by side rather than one replacing the other inside Google Cloud.

Where the two overlap

"Both" means Data Workers builds on the Knowledge Catalog capability.

Keep Knowledge Catalog for the inventory, run the estate with Data Workers

Keep Knowledge Catalog to harvest, profile and score Google Cloud data and to govern access through data products. It does that well.

Choose Data Workers to run the estate. It connects to Knowledge Catalog, joins it with every other platform, keeps AI-written text a proposal until a named person approves it, and ships the fix in code with a receipt. A multi-platform team with agents in production needs that job done across the estate, and that's the job Data Workers was built for.

What it costs

Knowledge Catalog is billed by use, with SKUs still named Dataplex. Standard processing covers data discovery at $0.06 per DCU-hour, with the first 100 DCU-hours each month free (the free tier applies to standard only). Premium processing covers data lineage, data quality and data profiling at $0.089 per DCU-hour in us-central1. Metadata storage is billed per GiB. Gemini-powered features, including data insights and automated metadata generation, are billed under Gemini in BigQuery or Gemini Code Assist. Discovery scans can also bill on Cloud Storage, BigQuery and other services they touch.

Data Workers is a flat platform fee. The Apache 2.0 core is free. The Pilot Program is $7,500 one-time, credited in full against your first year. Scale starts at $1,000 a month and Enterprise at $3,000 a month, at the annual rate. Seats are unlimited, there's no usage meter, and there's no markup on model spend because you bring your own model. See pricing.

The fastest first win: one definition, settled across platforms

Start with the definitions your agents already read. Connect Data Workers to your dbt project and one non-GCP platform such as Snowflake, with Knowledge Catalog's MCP server in the same coding agent. The Context Wizard takes the Knowledge Catalog entries your agent hands it, the dbt manifest and the other platform's metadata into one graph.

The first thing you see is lineage across platforms in one place and a Spellbook queue of metric definitions that disagree with each other, each variant with its source. Stewards pick the definition that's right, and each fix ships back to dbt as a doc change with a receipt. Nothing migrates, and every agent starts observe-only.

What Spellbook and Data Context Wizard add

Spellbook Data Catalog. The control plane for agent work, and the idea behind our whitepaper From the Traditional Data Catalog to the Agentic Data Catalog. A traditional catalog records what exists and what it means. Once agents do the work, the catalog also has to be where people review, approve, roll back and audit that work, on every platform.

• •One inbox for all agent work: approve, steer, send back or roll back.
• •Asset pages that cover the whole estate, across BigQuery, dbt, Airflow, Snowflake and Databricks.
• •An authority guard enforced in code. No agent can promote its own output to canonical, and no agent can approve its own goal.
• •Provenance and blast radius on every proposed change.

Data Context Wizard. One governed context graph across Google Cloud and everything else, with 50+ connectors. Every fact records its source, author, confidence and when it was observed. A multi-signal authority score orders the review queue, and a named human approves what becomes authoritative. It can also import and export Open Knowledge Format bundles, the format from Google's open-source knowledge-catalog repository, with every import passing through the same governed write gate.

The rest of the platform, the Data-Agents Swarm and the Autonomous Data-Conductor, is covered in Data Workers on Google Cloud. For the stage-by-stage path, read From Google Cloud to an autonomous data platform.

Guardrails

Knowledge Catalog lets a person decide whether generated insights are published and governs who gets access to data products. Data Workers makes every agent change a proposal, approved at the autonomy level you set.

• •New deployments start at L1, observe-only, and you extend autonomy one domain at a time, up to L4 where your team chooses.
• •Autonomy is set per domain. Catalog definitions can stay at propose-and-approve while routine reruns move higher.
• •Anything irreversible needs a named human to approve it.
• •Every action is approved or reversible, with a receipt covering the diff, approver, timestamp, blast radius and rollback path.
• •No agent can approve or promote its own work, enforced in code in the write path.
• •Least privilege. Data Workers reads Google Cloud with the IAM roles you grant, and access enforcement stays in IAM.

"Knowledge Catalog has MCP servers and a context API. Isn't that enough for agents?"

For reading Google Cloud context, it's a good start. The discovery MCP server gives any agent search_entries, lookup_entry and lookup_context, with IAM applied. The lookupContext API launched in preview in June 2026. The lineage MCP server and the data products MCP server are in preview.

Reading is half the job. Agents also change metadata. The data products server can create and update data products, assets and aspects, and Google's MCP documentation describes no review step on those writes; metadata change review is in private preview. Every Data Workers agent is an MCP server too, and each one runs behind the approval flow, the authority guard and the receipts. Knowledge Catalog's MCP servers and Data Workers' agents sit in the same client today, so the two work together from day one.

How it fits together

Getting started takes no migration. Connect Data Workers with a scoped service account, add Knowledge Catalog, your dbt or Dataform project, your orchestrator and your non-GCP platforms, and let the Context Wizard build the graph. Your coding agent stays the way your engineers ask for work. Spellbook is where people look, review and approve.

The case for your CFO

The outcome. One approval trail for every change an agent makes to what your data means, across Google Cloud and every other platform. Fewer wrong numbers reaching finance, and an answer when someone asks who changed a definition and why.

The risk story. At L1 agents observe. At L2 they propose, and a person approves. At L3 they act on reversible changes, and L4 autonomy comes only in domains you choose. Anything irreversible needs a named approver at every level. Each change carries a receipt with the diff, the approver, the time, the blast radius and the rollback path. Nothing migrates: Knowledge Catalog, BigQuery, IAM and dbt stay where they are.

Why now. In 2026 Knowledge Catalog shipped MCP servers and lookupContext, which make it easy for any agent to read published context. That's useful, and it also means unreviewed AI text now reaches agents at scale.

The first win. Lineage across platforms in one place and a queue of conflicting metric definitions, settled by stewards and shipped back to dbt with receipts.

What stays the same. Knowledge Catalog stays the Google Cloud inventory. The team's tools stay. The coding agent stays the way in.

The path. Start with a pilot (pricing). The pilot is credited in full against the first year. For the executive version, read the Google Cloud data leader's guide.

The sentence to repeat upstairs: "We keep Knowledge Catalog as the inventory for Google Cloud and put Spellbook in front of every agent that changes what our data means, on every platform."

When Knowledge Catalog alone is enough

Knowledge Catalog can be enough if your estate is Google Cloud only and people, not agents, write the metadata others rely on. Once definitions live on more than one platform, or agents start changing them, you need one place where those changes are proposed, approved and recorded. That's where Data Workers comes in.

FAQ

What is a good Dataplex alternative for multi-platform teams? If you run more than Google Cloud, pair Knowledge Catalog with Data Workers rather than replacing it. Data Workers builds one context graph across BigQuery, Snowflake, Databricks, dbt, Airflow and BI, and puts every agent change behind one approval flow with a receipt. Knowledge Catalog stays the inventory for Google Cloud.

Is Knowledge Catalog the same as Dataplex? Yes. Dataplex Universal Catalog was renamed Knowledge Catalog on April 10, 2026. The API, client library, CLI and IAM names are unchanged, so code still calls dataplex, and the pricing SKUs still say Dataplex.

Does Knowledge Catalog support dbt? Yes. dbt metadata import went GA on September 24, 2026, covering dbt Core, Fusion and dbt Cloud runs, MetricFlow models and metrics, and tests. It's one-way, it has no direct connection to dbt Cloud (you bring artifacts or wire webhooks), and lineage covers BigQuery resources only.

Can Knowledge Catalog see Snowflake and Databricks? Through catalog federation with Snowflake Horizon and Databricks Unity Catalog over Iceberg REST, which is in preview and read-side. The Snowflake managed connector is community-built and not officially supported by Google.

Does Data Workers work with Google Knowledge Catalog? Yes. Knowledge Catalog connects over its MCP servers today: your coding agent reads entries and lookupContext bundles and hands them to the Context Wizard graph. Data Workers doesn't write into Knowledge Catalog entries, aspects or the glossary: approved facts land in the Context Wizard graph, approved definition fixes ship back to dbt as doc changes, and Knowledge Catalog's dbt import picks them up on its next run. Where your team wants an aspect or glossary term updated directly, a steward applies it, or your MCP client writes it where Google's MCP server allows.

Does Data Workers replace Google's data quality scans? No need. BigQuery scans can stay where they are. Data Workers runs its own checks on BigQuery, Snowflake and Postgres and routes failures into a loop that fixes them at the source and verifies the result.

How much does Data Workers cost? The Apache 2.0 core is free. The Pilot Program is $7,500 one-time, credited in full against your first year. Scale starts at $1,000 a month and Enterprise at $3,000 a month at the annual rate, with unlimited seats and no usage meter. See pricing.

Sources

Sources for Knowledge Catalog capabilities, statuses and pricing: Google Cloud documentation, release notes and blog posts current as of October 2, 2026, including the release notes, Knowledge Catalog launch post, catalog overview, dbt import, database connectors, managed connectivity, metadata change feeds, MCP reference, remote MCP, lineage MCP, supported MCP products, retrieve data context, data insights, business glossary, governance workflows, data domains, data lineage, OpenLineage, auto data quality and pricing. Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.