Choose the platform that already holds the data, then decide which responsibilities you still have to design. Snowflake and Databricks can both host governed definitions and an agent experience. They do not remove your obligation to separate a business definition, a query, an access check, and a human review. This comparison does not pick a winner, and it does not execute a question on either platform.
The marketing pages for Snowflake and Databricks describe Orisdale’s reference roles. The trusted-platforms article explains why the estate you already run matters. This piece is the responsibility matrix those pages do not try to be.
Comparison of responsibilities. It does not rank a winner or execute a query.
Start with the estate
A new agent project that ignores where the tables, grants, and close process already live will invent a second set of definitions. If finance already publishes a metric in Snowflake, the first design question is how an agent will read that metric. If the same metric is a Unity Catalog object in Databricks, the first question is how an agent will read that object. Moving the metric only to suit a model is a separate decision, with its own cost.
Google Cloud remains a peer path when the data already lives there. This article does not expand into a three-platform scorecard. The architecture page keeps that pattern available.
Definitions
Snowflake documents semantic views as schema-level objects that describe business concepts, metrics, and relationships for Cortex Analyst. Cortex Analyst is a managed feature that turns a natural-language question into SQL and runs that SQL in the customer’s virtual warehouse. The documentation, checked on 9 October 2026, also says Snowflake recommends Cortex Agents as the newer surface that includes Cortex Analyst capabilities. See Cortex Analyst.
Databricks documents Unity Catalog metric views as a way to define measures separately from the fields used to group and filter them. The query engine generates the computation for the grouping the user asks for. Metric views can be queried from SQL, dashboards, and Genie Agents. See Unity Catalog metric views. The product name in that documentation is metric views, not “metric stores.”
A semantic view or a metric view does not, by itself, make every join valid. Constraints you have not declared are not enforced by the label “semantic.” Review the relationships you model. Do not treat the feature name as a guarantee.
Query generation and compute
On Snowflake, Cortex Analyst’s documented path generates SQL. That SQL then runs in a virtual warehouse. A design that says “no SQL is ever generated” contradicts the current Snowflake documentation. The design question is which semantic view the generation is bound to, which warehouse runs it, and which result the narrative is allowed to cite.
On Databricks, keep Unity Catalog governance separate from the SQL warehouse that executes a query. A metric view defines the measure. Compute is still a warehouse or another UC-compliant engine you select. Genie One, where you use it, is an interface. It is not the governance catalog and it is not the warehouse.
Access and policy
Snowflake’s Cortex Analyst documentation says generated queries follow role-based access control already configured in Snowflake. That is a platform statement about Snowflake’s own execution path. It does not mean a custom application outside Snowflake inherits those policies automatically, and it does not mean a copied result file remains under the same grant.
Databricks access for metric views is managed in Unity Catalog, including who can use the view. An agent runtime that holds a broader token than the reviewer should not be treated as if it had the reviewer’s grants. Identity in the agent and authorization on the platform are different controls.
Evaluation and model change
Snowflake publishes a separate evaluations topic for Cortex Analyst. Use it to test ambiguous questions against the semantic view you defined. A passing evaluation is evidence about that test set. It is not a general accuracy promise, and it is not a reason to skip review of a consequential number.
When the model behind an agent changes, the definitions should not have to move with it. Keep the metric in the platform object you already version. Treat the model as the component that proposes a question interpretation and a narrative. If a new model produces a different SQL shape, the semantic view, the grants, and the review rule are what you re-check. Do not assume a model swap preserves every answer.
A synthetic question, not an execution
Suppose a reviewer asks, “What was Field Operations variance in September 2026?” On a Snowflake path, the responsible design binds that question to a semantic view whose variance measure matches the approved contract, generates SQL through the documented Cortex path, and runs it in a warehouse the role can use. On a Databricks path, the same question binds to a metric view whose measure matches that contract, and a SQL warehouse runs the query under Unity Catalog grants.
This article does not run either query. The numbers in the Finance proof explorer were computed locally from published files. They are not a Snowflake result and not a Databricks result. Use them to see how a contract, a result, and a claim check fit together. Use the platform pages to see where those responsibilities would sit.
Questions before you choose
- Which system is already the source for the metric, and who owns the definition?
- Will the agent generate SQL, call a saved query, or both, and where is that choice written down?
- Which warehouse or SQL warehouse executes, and which grant is used?
- What happens to an ambiguous period or an unknown department?
- Which answers require a person, even when the query succeeds?
- What will you re-test when the model changes and the metric does not?
Limits
Low operational friction, full portability of policies, and automatic inheritance of every control into every agent runtime are not claims this article makes. Platform features change. Recheck the vendor pages above before you treat a detail as current. Orisdale’s partnership wording, where it appears on the platform pages, is registration or participation language already approved there. It is not an endorsement of this comparison.
Discuss the estate you have, not a blank-slate platform debate, from the contact page.
What stays in your design either way
The matrix above is a way to brief an architecture review. It is not a migration plan. A team that already runs Snowflake does not gain reliability by redrawing the same metric inside a new box called an abstraction layer. A team that already runs Databricks does not gain reliability by pasting Unity Catalog grants into a prompt. In both cases the durable objects are the definition, the grant, the execution engine, and the review rule.
Write the definition where the platform already versions schema objects. On Snowflake that may be a semantic view consumed by Cortex Analyst. On Databricks that may be a metric view in Unity Catalog. Point the narrative at the result of that object. If a reviewer cannot find the version that produced a number, the workspace is not ready for a consequential answer, regardless of which vendor badge sits on the diagram.
Keep a physical or logical execution path explicit. Cortex Analyst documentation says the generated SQL runs in your virtual warehouse. A Databricks metric view still needs a query engine; the existing Orisdale platform page keeps the SQL warehouse distinct from Unity Catalog so governance and compute are not collapsed into one label. If your estate uses a different supported warehouse, name it. Do not leave “the platform” as the compute story.
Finally, decide the human boundary before the first demo. A question about a definition can be answered by showing the semantic or metric view. A question about whether to accrue, pay, or file still needs a person. That split is the same on both platforms. The comparison is about where the controls live, not about which product removes them.