This release closes the loop between your catalog and your source systems — governed descriptions now push straight back to Snowflake — while the API and MCP server keep expanding for programmatic and agentic workflows. Plus a cleaner catalog landing page and faster governance triage. Here's everything new 👇
🔥 What's New?
❄️ Next-gen Snowflake Writeback for Descriptions & Comments (Governance Premium)
Descriptions curated and approved in your data.world catalog can now sync directly back to the source Snowflake database, schema, table, or column as a comment. It's built to handle real volume: sync updates at the database, schema, and table level for a push-once, update-all experience.
Why it matters: Today, keeping Snowflake and your catalog in sync usually means someone manually filing and tracking tickets, or copy-pasting from a spreadsheet — for every single approved change. That doesn't scale, and it creates real drift risk: the catalog says one thing, Snowflake says another, and nobody's sure which is current. With this new premium automation, stewards stop maintaining documentation twice, and everyone downstream can trust that what they see in Snowflake reflects the governed, current answer.
For more information on Snowflake Writeback, check out the documentation.
🧩 API & MCP Server: Account Fields Support
The data.world API and MCP server now fully support Account Fields. You can both fetch and update Account Fields on catalog resources programmatically. More on MCP in our documentation.
⚡ API & MCP Server: Trigger Premium Resource Automations
New endpoints and tools let the API and MCP server trigger existing automations on catalog resources — for any resource that supports and is enabled for Suggest Changes, Request Access, Databricks Writeback, or Snowflake Writeback. More on MCP in our documentation.
🔎 MCP Server: Fetch and Query Datasets
The MCP server now supports fetching datasets, as well as running both SQL and SPARQL queries against them. More on MCP in our documentation.
🗂️ Collected vs. Non-Collected Resources on Your Catalog Landing Page
The single "Resources" grid used to mix everything together — objects harvested by a metadata collector alongside resources built directly in the catalog. We've split that into two clearly labeled sections, so you can tell at a glance what came from a collector versus what was authored in-catalog. To enable this, sync your source modules and metadata profile.
Why it matters: As a catalog matures, it accumulates more resource types from more collectors, and a flat grid gets harder to scan every time you add one. Separating collected from non-collected resources gives anyone landing on the catalog — a new user orienting themselves, or an admin auditing collector coverage — an immediate, honest picture of how much of the catalog is automated ingestion versus hand-built.
✅ Filter Suggested Changes by Collection on the Governance Page
Approvers managing a high volume of suggested changes can now filter the Pending Changes view down to a specific collection, so you can find and act on the changes that are actually yours — instead of scrolling a flat, unsorted list. Claiming and approving changes in bulk is dramatically faster for large catalogs.
🕸️ A New, More Scalable Lineage Graph Explorer (Now in Beta with Opt-In End-User Preview)
We're bringing a new lineage graph explorer to data.world, rebuilt for scale and performance across even the largest lineage hierarchies. It also adds support for process nodes — like dbt models — as lineage root nodes, so you can trace impact starting from a transformation, not just a table or dataset.
Part of this includes the new Lineage Preview, live for all users, which uses the hexagonal aesthetic and user interface pioneered by our next-generation "Graph Explorer" capability.
But where the fun really happens is when you "Switch to Explorer (Beta)". This flips to the new user experience for the main lineage viewer. If at any time you want to switch back to the legacy view, click "Switch to legacy view".
For more info on the updated lineage capabilities, check out the documentation.
💫 Coming Soon
🏷️ Next-gen Snowflake Tag Writeback
The same next-gen governed writeback automation is being extended to sync tags back to Snowflake, not just descriptions — so classification and tagging decisions made in the catalog carry through to your source system too.
Why it matters: Descriptions are documentation, but tags are often load-bearing — sensitivity and PII classifications, in particular, frequently drive downstream access control or masking policies directly in Snowflake. Extending writeback to tags means a classification decision made once, in the catalog, is the decision that governs the data everywhere, not just in the catalog's own view of it.