What Snowflake gives you — and the practitioner layer it doesn’t capture

Snowflake gives you a lot. Centralized data, elastic compute, robust governance primitives, query history, fine-grained access controls. For most analytics teams, it’s the most operationally mature surface in their stack.

If you’re running dbt on top of Snowflake, you have even more: a strong dependency graph across your transformations, model descriptions, owner tags, lineage in the dbt docs site. The combination is genuinely powerful.

But there’s a layer above all of this that neither Snowflake nor dbt is designed to capture. It’s the practitioner layer — what each query and model is for, which business outcome it serves, who depends on it, how much it’s worth in measurable terms. The metadata in your warehouse tells you a query exists. The dbt graph tells you what it depends on. Neither tells you why it matters or what it produces.

That’s the gap MyDataWork is built to fill.

A scenario most Snowflake teams will recognize

Morgan Chen is the analytics engineering lead for a mid-market SaaS company’s Customer 360 platform. Her team owns the canonical query that unifies customer records across Salesforce, HubSpot, Stripe, and three product event streams. The query lives as customer_360_master.sql in her local clone of the analytics repository; the resulting view lives in Snowflake; the dbt project that materializes it shows up cleanly in dbt docs.

Morgan knows the technical surface inside out. She knows the column lineage, the upstream tables, the downstream models that depend on her work. Snowflake’s information schema and her dbt docs give her all of that.

What neither tells her:

• Why customer reconciliation tickets dropped from 40/month to 10/month after Q2, and which specific changes to the canonical query drove that reduction
• That Priya Raman, VP of Revenue Operations, is the primary stakeholder for this work and should be looped in on any breaking schema change
• That two team members have been independently building parallel customer attribution work, neither aware the other was doing it
• That her CFO will ask “what’s the value we’re getting from the Customer 360 investment” in next month’s planning meeting, and she has no portfolio-level answer ready

These aren’t technical gaps. They’re context gaps. And context lives one layer above the warehouse.

What MyDataWork adds

When Morgan connects MyDataWork to her workspace, the picture comes together across her actual stack:

• The Snowflake connector catalogs the tables and views in the schemas Morgan exposes — the customer_360_master view, downstream marts, the core operational tables her work touches
• The Windows Connector catalogs the SQL, Python notebooks, and Alteryx workflows in her local analytics repo and project folders
• MyDataWork parses SQL references in each cataloged file, cross-references them against the Snowflake catalog, and builds the lineage edges between them — the cross-tool picture that no single tool captures alone

The lineage view shows customer_360_master.sql at the center with upstream Python and Alteryx assets feeding it and downstream Power BI, Tableau, and Snowflake assets consuming it. The cross-tool picture lives one layer above what any single tool can show.

Then comes the layer the technical tools don’t reach:

Use case documentation. Morgan links the canonical Customer 360 query to a documented use case: Customer 360 reconciliation reduction. She sets the baseline (40 tickets/month), the current state (12 tickets/month), and the target (10 tickets/month or fewer). She notes the estimated value ($120K/year in support cost avoidance) and updates the realized value ($90K through Q3) as the work delivers.

Morgan’s “Customer 360 reconciliation reduction” use case documents the baseline (40 tickets/month), current state (12), and target (10), with realized value tracking the work as it delivers. Priya Raman is linked as the stakeholder for the team to coordinate with.

Stakeholder linking. Priya is added as the use case stakeholder. She becomes visible in the use case detail and on the lineage view, so anyone working on the underlying assets knows who depends on them. The Workspace Agent’s missing-stakeholder check adds a proactive layer — it flags any active use case that doesn’t have someone in Priya’s role assigned.

On-demand workspace review. Morgan runs the Workspace Agent from the Suggestions tab when she wants a structured review of her workspace. The agent surfaces patterns across six categories — duplicate parallel work, missing stakeholders, stale use cases, high-value-unrealized use cases, dependency breaks, and assets that have become hidden infrastructure. Once she’s documented the Customer 360 use case and the recent duplicate file is in her catalog, the agent catches the parallel customer attribution work the next time she runs Analyze.

Portfolio reporting. When the CFO asks about Customer 360 value next month, Morgan generates a portfolio export from MyDataWork. It shows the linked assets, the documented use case, the baseline-to-current improvement, and the value realized year-to-date. The conversation moves from “we built a thing” to “here’s what it produces.”

Where MyDataWork sits relative to your existing stack

MyDataWork is not an enterprise data catalog. Tools like Atlan, Alation, and Collibra serve a different need — top-down governance for organizations with mature data teams rolling out catalog discipline at scale. Those tools work, and they work at enterprise scale.

MyDataWork is built for the practitioner: the analytics engineering lead, the data analyst, the BI developer who’s building a working practice from the bottom up. It complements your existing investments rather than replacing them. Your dbt project keeps doing what it does. Your Snowflake governance stays in place. MyDataWork adds the work context layer above both — the documentation of why each piece of analytical work matters and what it produces.

That practitioner-first design is also what shapes the Explorer plan.

Try it on the work that matters most

MyDataWork’s Explorer plan is 90 days, free, no credit card. One user, your own workspace.

Explorer is intentionally focused: up to 30 user-added assets, one cloud source connection, 3 AI credits per day for AI-powered analysis (with 60 credits total across the trial), and 20 daily Workspace Agent runs that don’t count against credits.

For a Snowflake-heavy team, 30 assets means you’ll be focused — not every query and dashboard, but the 30 that matter most. The canonical Customer 360 query. The dashboards your CFO actually opens. The notebooks your stakeholders rely on. Build the documentation practice around those, link the stakeholders who care, set the outcome metrics that matter, and let the agent surface what you’d miss.

When you outgrow 30 assets — and if you’re serious about cataloging your full analytical surface, you will — Solo lifts the cap to 300 and Team to 2,000. Your work transfers; your data carries forward; the workspace you built becomes the foundation you expand from.

Where this matters now

Every organization is being asked to “do something with AI.” The agents your leadership is about to deploy will need to understand which queries serve which business outcomes, who depends on what, and how much each piece of work is worth. Your warehouse holds the technical infrastructure. dbt holds your transformation logic. MyDataWork holds the analytical practice that infrastructure and logic support.

For Snowflake teams specifically, the work context layer is what enables credible AI strategy on top of a mature data foundation. Without it, AI initiatives produce confident-sounding output disconnected from your actual analytical priorities. With it, the AI agents that arrive in the next 12 months have something real to work from.

Start here. Email only, no credit card. Connect your data and you’ll be cataloging your first assets within minutes.