Snowflake Horizon Catalog vs Spellbook Data Catalog: Horizon Enforces the Grants, Data Workers Governs the Work

Snowflake Horizon Catalog is the lock on your Snowflake data. It holds the roles, grants, masking and row-access policies, classification tags and access history, and since February it also serves your Snowflake-managed Iceberg tables to Spark, Trino and Flink through its Iceberg REST endpoint, under the same roles. Spellbook Data Catalog is the control plane around that lock: it governs the work agents do across the whole estate and drafts each approved change as Snowflake SQL for the owner to apply, so Horizon keeps enforcing it.

If you run Snowflake as the warehouse, your week probably looks like this. A security admin works through a queue of access requests from people whose queries failed. A data engineer adds a column through Fivetran and dbt, and nobody is sure which roles can now read it. A Databricks team reads your Iceberg tables over Horizon's REST endpoint with a service role someone granted last spring. CoCo, your coding agent and a few internal agents all want to change things. Every grant and policy lives in Snowflake, and every decision about them lives in Slack threads and tickets.

Data Workers is the better choice for running that work. Horizon decides whether a role can read a column. Data Workers decides, with a named approver, which roles should, proposes the change across every platform it touches, and keeps the receipt. For the whole Snowflake picture, read Data Workers on Snowflake. This page is about the catalog and access layer; the context layer (Horizon Context, Cortex Sense, semantic views) has its own comparison in Snowflake Horizon Context vs Data Workers.

Key takeaways

• •Horizon Catalog is the right enforcement point for Snowflake. RBAC, masking and row-access policies, classification and Trust Center are mature, and the Iceberg REST endpoint is GA for reads and writes from outside engines. Keep all of it.
• •Snowflake already asks before it changes things in the account. Trust Center runs its remediation SQL after you approve the plan, and Cortex descriptions are kept only when a user saves them. Those approvals are scoped to one account and one admin role.
• •Spellbook governs the work across the estate. Every agent's proposed change, on Snowflake, Unity Catalog, BigQuery or dbt, lands in one inbox with its blast radius, a named approver, a rollback path and a receipt.
• •Approved changes go back through Snowflake. Data Workers drafts grants, revokes and policies as Snowflake SQL, and the owner runs them under their own role. Horizon still enforces every one.
• •Open Catalog is closed to new customers. Snowflake now points new Iceberg customers to Horizon Catalog. Data Workers reads the roles and grants on those Iceberg tables through Snowflake either way.
• •The first win is the access queue. Requests go from ticket to a dry run of the grant (effective privileges, the sensitive columns it reaches) to an approved, time-boxed grant the owner applies, to receipt, with the expiry recorded.

Six things you get with Data Workers on top of Horizon Catalog

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

2. Access requests closed end to end. The Governance agent takes a request from the ticket, dry-runs the grant to show its effective privileges after role inheritance, the sensitive columns it would reach and any policy conflict, routes it to the data owner, proposes the grant as Snowflake RBAC for the owner to apply and keeps the receipt, with the grant's expiry recorded.

3. Grants kept in step across platforms. The same analyst often needs matching access in Snowflake and in Unity Catalog. Data Workers diffs the grants on each platform against the intended set and proposes one plan: the Unity Catalog grant is applied after approval, and the Snowflake grant goes to its owner as SQL.

4. New sensitive columns caught before outside engines read them. Pull request review flags new columns whose names look sensitive, and Data Workers proposes the tag, the masking policy and any grant change for the owner to apply, with the downstream readers traced through lineage and the grant dry-run attached.

5. Grants that carry their expiry. Every grant Data Workers drafts, including those for the service roles external engines use over Iceberg REST, is recorded with its expiry in a ledger your access reviews start from, and each revoke is a proposal with a rollback path.

6. A receipt on every change: the diff, the approver, the time, the blast radius and the rollback path, kept tamper-evident for your auditors.

One new column, five systems

Here's how a single field becomes an access problem in a mixed estate. It's an illustration, not a customer case.

• •07:55, Salesforce and Fivetran. Sales ops adds a contact email field. Fivetran syncs it into the raw schema in Snowflake.
• •08:40, dbt and Airflow. The nightly DAG runs dim_customers, which selects * from the staging model and writes a Snowflake-managed Iceberg table.
• •09:00, Databricks. A Spark job reads dim_customers through Horizon's Iceberg REST endpoint with a service role that has SELECT on the schema.
• •Later, Snowflake. Classification tags the column as an email address on its next run. Policy enforcement for external engines through the Scan Plan API is in public preview and isn't turned on in this account.
• •The question. Who should have been able to read that column, and who approved it?

Horizon did its job: it enforced the grants that existed. Nothing in it asked, before the column landed, whether the grants still made sense for the data about to arrive. Data Workers adds that step, and Horizon enforces the answer.

What Snowflake Horizon Catalog covers, as of October 2026

Here's what Snowflake's documentation and release notes say ships today, using the more conservative status where pages differ.

That's a strong catalog and enforcement layer for Snowflake, and it's getting more open every quarter.

One platform, not one more tool

Enforcing access is one job on a data team's list. The same team writes quality checks, runs down incidents, changes pipelines, plans schema changes, cuts spend and keeps models fed. Each point tool adds another console, another contract and another handoff.

Data Workers covers the whole lifecycle with one context graph, one approval flow and one audit trail. We score the same ten stages on every comparison page. Snowflake leads on its two home stages, governance and security, and Data Workers covers every stage.

Horizon Catalog vs Spellbook on the outcomes you buy

This view narrows to eight outcomes a data leader pays for from a catalog and access layer. Snowflake leads on three, all on its own surface: enforcing grants and policies, serving Iceberg tables to other engines, and fixing account posture findings. We're even on finding sensitive columns. Data Workers leads on every outcome that spans platforms or involves agents changing things.

The scores measure scope, not answer quality. They're directional judgments, not benchmarks, and the reasoning is shown so you can argue with any line.

Where Horizon Catalog stops

Each limit below comes from Snowflake's own documentation. None is a flaw. Snowflake built Horizon to make the Snowflake account a safe, open home for data, and an enforcement layer built that way is scoped to the account by design.

Approvals live inside one account and one admin role. Request Access sends requests to ACCOUNTADMIN or SECURITYADMIN, who approve, reject or mark them approved elsewhere. Trust Center asks before it runs remediation, for supported CIS findings. Both are good patterns, and both stop at the account boundary.

Open table access isn't shared policy. Horizon's Iceberg REST endpoint applies Snowflake roles to outside engines, and enforcing masking and row-access policies for those engines through the Scan Plan API is public preview. Grants in Unity Catalog, BigQuery or a Polaris catalog are their own systems with their own owners.

Other platforms arrive as tables, not as governance. Catalog-linked databases read and write Iceberg tables in Glue, Unity Catalog and Open Catalog. That's data access. Who may see the same customer data in Databricks is still decided in Databricks.

Agents get identities, not a review queue. Agent Identity gives each Snowflake agent a role and an audit trail. CoCo asks before it runs a fix. There's no single place where every agent's proposed change, from every platform, waits for the right owner.

Nothing in the catalog owns the change. Horizon enforces what was granted. It doesn't decide what should be granted when a new column lands, a team changes, or a service role outlives its project.

Why doesn't Snowflake just do this itself?

Because it would be a different product. Horizon's job is to make every Snowflake object safe to share, and the right design for that job enforces inside the account and asks an account admin before it changes anything. Governing agent work across the estate means proposing changes in systems Snowflake doesn't run: Unity Catalog grants, dbt models, Airflow DAGs, Fivetran connectors. That needs blast-radius scoping across those systems, approvals routed to owners outside the Snowflake admin role, rollback, receipts, context about every other platform, and liability for changes in tools Snowflake doesn't own. That's the product Data Workers is.

Where the two overlap

"Both" means Data Workers works through the Snowflake capability.

Why Data Workers is the better choice next to Horizon Catalog

Keep Horizon Catalog as the enforcement point for Snowflake data. Keep your roles, policies, classification and Trust Center. They're good, and Data Workers depends on them.

Choose Data Workers to run the work around them. It reads what Horizon knows, joins it with Unity Catalog grants, dbt, Fivetran and the rest of the estate, turns every change into a proposal with a blast radius, routes it to the owner who should decide, hands the approved change to that owner as Snowflake SQL and keeps the receipt. No Snowflake product does that across the estate, because it isn't Snowflake's job.

The case for your CFO

The outcome. Access requests close in hours instead of sitting in an admin queue, with the right data owner approving each one. Grants stay consistent between Snowflake and the other platforms your teams use, and every change to who can see customer data comes with a receipt your auditors can follow without a scramble at quarter end.

The risk story. Agents never get more power than you give them. They start observe-only. Access changes stay at propose-and-approve, so a named person signs off before any grant, revoke or policy changes. Every approved change is applied by its owner through Snowflake RBAC, under a role you control, carries its blast radius and rollback path, and lands in a tamper-evident receipt. Nothing migrates and nothing leaves Snowflake's enforcement.

Why now. Iceberg REST has opened your Snowflake tables to every engine, and agents now have identities and roles of their own. The number of principals that can reach your data is growing faster than an admin queue can review them.

The first win. The access queue and a review of the service roles outside engines use, inside one pilot.

What stays the same. Horizon Catalog, your roles and policies, Trust Center, classification and the way your security team reviews the account.

The pilot path. Start with a pilot on one domain: Snowflake plus one other platform. The pilot is credited in full against the first year. See pricing.

The sentence to repeat upstairs: Snowflake enforces who can touch our data; Data Workers makes sure every change to that access is approved by the right person, on every platform, with a receipt.

What it costs

Horizon's core features come with Snowflake, and many fine-grained policy features need Enterprise Edition. The Iceberg REST Catalog API is billed at 0.5 credit per million calls as Cloud Services, with billing scheduled to begin in the second half of 2026. Open Catalog billing was set to begin in the first half of 2026 for existing customers.

Data Workers is a flat platform fee. The Apache 2.0 core is free. A pilot is $7,500 one-time. Scale starts at $1,000 a month and Enterprise at $3,000 a month (billed annually). 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 only Snowflake credits Data Workers uses are for the queries it runs under the role you grant.

The fastest first win: the access queue

Start where the work piles up. Connect Data Workers to Snowflake with a scoped role, add your ticketing channel and one other platform where the same people need access, such as Unity Catalog. New access requests go to the Governance agent. Each one arrives in Spellbook with its dry run: effective privileges, the sensitive columns it would reach and a suggested time limit. The data owner approves, the owner applies the proposed Snowflake RBAC grant, and the receipt records who approved what. In parallel, route requests for the service roles that outside engines use over Iceberg REST through the same dry run. Within a pilot you have a working request queue, a ledger of every grant and its expiry, and an audit trail your security team didn't have to assemble.

What each Data Workers product adds next to Horizon Catalog

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 who may touch it. Once agents do the work, the catalog also has to be where that work is proposed, approved, rolled back and audited.

• •One inbox for all agent work: approve, steer, send back or roll back.
• •Asset pages across the estate: Snowflake, Iceberg tables, Unity Catalog, dbt and Airflow on one page per asset.
• •An authority guard enforced in code. No agent can approve or promote its own work.
• •Provenance and blast radius on every proposed change.

Spellbook is the business-user app; Approval requests also reach the team in Slack or email.

Data-Agents Swarm. The Governance agent handles access, policy and entitlement work; the Schema and Pipelines agents scope the changes that create new access questions; the Cost agent reads Snowflake warehouse spend. Each agent is an MCP server your coding agent can call.

Data Context Wizard. The graph Spellbook reads from, with 50+ connectors, including Snowflake, Unity Catalog, dbt and Airflow. The context side of the Snowflake story is covered in Snowflake Horizon Context vs Data Workers.

Autonomous Data-Conductor. Runs each fix end to end, from detection through approval to verification, and writes what it learned back to the graph. The Databricks version of this comparison is Unity Catalog vs Spellbook Data Catalog, and the Google Cloud version is the best Dataplex alternative.

Guardrails

Snowflake governs change inside the account well: Trust Center asks before it runs remediation, Cortex descriptions need a user to save them, and every action runs under a role. Data Workers adds the same discipline across the estate, at the autonomy level you set.

• •New deployments start observe-only (L1), and you extend autonomy one domain at a time.
• •Autonomy is set per domain. Access grants can stay at propose-and-approve (L2) while documentation upkeep runs at L3.
• •Anything irreversible needs a named human to approve it.
• •Every action is approved or reversible, with a tamper-evident 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 acts with the Snowflake role you grant, so Horizon's policies apply to everything it touches, and it never keeps a shadow permission system.

What agents can and can't do at each level is explicit: at L0 people do the work by hand, at L1 agents read and report, at L2 they propose and wait for approval, at L3 they act on reversible changes and report back, and at L4 they act autonomously in the domains you've chosen. Access changes in Snowflake rarely need to go past L2.

"Snowflake has an MCP server and CoCo. Can't our agents just do this?"

They can read a lot. The managed MCP server is GA, its SQL tool is read-only by default, and sessions run under the user's default role. CoCo can explain a Trust Center finding and run the fix with your approval. That's the right design for one person asking for one change in one account.

Running access across an estate is a different shape of work. It needs a queue every agent shares, owners outside the Snowflake admin role, the same change applied in Unity Catalog and proposed for Snowflake, and a receipt your auditor can follow. MCP is the transport. The approval flow, the blast radius and the receipts are the product, and every Data Workers agent runs behind them. Your coding agent can call Snowflake's MCP server and Data Workers' agents side by side.

How it fits together

There's no migration. Connect Data Workers to Snowflake with a scoped role, then add your dbt project, your orchestrator and the other platforms where the same people need access. Horizon stays the enforcement point and nothing moves. Every agent starts observe-only, and the first things you see are the sensitive columns your pull requests add, the roles external engines use, and the access requests waiting in the queue. What stays the same: your roles, your policies, Trust Center and the way your security team reviews the account.

When Horizon Catalog alone is enough

Horizon Catalog can be enough if everything runs in Snowflake, a small admin team handles access requests comfortably, and no agent changes grants or policies. Everyone else, which is most teams with a Databricks workspace, outside engines on Iceberg tables or agents in production, chooses Data Workers, because they need one approval flow for every change and a receipt behind every grant.

FAQ

What is Snowflake Horizon Catalog? Snowflake Horizon Catalog is the built-in catalog and governance layer of every Snowflake account, and Data Workers is the control plane teams add around it. Horizon covers RBAC, masking and row-access policies, classification, lineage, access history, Trust Center and an Iceberg REST endpoint for outside engines.

Horizon Catalog vs Spellbook Data Catalog: which should I choose? Choose Spellbook if agents propose changes, if access spans Snowflake and another platform, or if you need a named approver and receipt behind every grant. Keep Horizon either way: it stays the enforcement point, and every approved change is applied through it.

What happened to Snowflake Open Catalog? Open Catalog is Snowflake's managed Apache Polaris service, and it's closed to new customers. Snowflake directs new Iceberg customers to Horizon Catalog. Data Workers reads the grants on Horizon-served Iceberg tables through Snowflake, and Polaris catalogs connect over their APIs today.

Does Data Workers bypass Snowflake RBAC? No. Data Workers reads with the role you grant and drafts approved grants and policies as Snowflake SQL. The owner runs them, and Horizon enforces them like any other change.

Can Data Workers handle Snowflake access requests? Yes. The Governance agent takes a request from the ticket, dry-runs the grant (effective privileges, sensitive columns, policy conflicts), routes it to the data owner in Spellbook, proposes the approved grant as Snowflake RBAC for the owner to apply, and records its expiry, with a receipt for each step.

Does Data Workers replace Trust Center or classification? No. Keep both. Data Workers adds privacy checks on pull requests across platforms and turns findings into proposals with owners, rollback paths and receipts.

How much does Data Workers cost? Data Workers' Apache 2.0 core is free. A pilot is $7,500 one-time, Scale starts at $1,000 a month and Enterprise at $3,000 a month, billed annually, with unlimited seats and no usage meter. See pricing.

Sources

Sources for Snowflake capabilities and statuses: Snowflake documentation and release notes current as of October 2, 2026, including Snowflake Horizon Catalog, Iceberg REST access for external engines (status, roles and billing), externally managed Iceberg tables through Horizon (Aug 18, 2026), Scan Plan API (Sep 10, 2026), inherited grants (Sep 10, 2026), Request Access in Workspaces (Aug 10, 2026), Trust Center remediation (Aug 14, 2026), Horizon Catalog Explorer (Sep 15, 2026), 2026 feature releases, Cortex-generated descriptions, Open Catalog overview, catalog-linked databases, managed MCP server, the Horizon Catalog Summit 2026 press release (Jun 2, 2026) and Apache Polaris releases (1.8.0, Sep 28, 2026). Product names and statuses change quickly; if we've got something wrong, tell us and we'll fix it.