Snowflake’s Databricks attack needs a citation audit before it becomes a buying guide

Snowflake published a blunt comparison of its platform with Databricks on September 3. The useful part is not its verdict. It is the list of operational claims a buyer can turn into tests—and the warning embedded in the page’s own citation hygiene.

The links need checking before the claims do

An inspection of the published page found 10 distinct documentation targets wrapped in Google Search URLs. They include references for auto-suspend, Iceberg, differential privacy, data sharing, replication and Polaris. The page also links once to Snowflake documentation with utm_source=chatgpt.com in the URL. That parameter is visible in the published HTML; it is not evidence that an AI system wrote the article. It is evidence that the final page retained a tracking-bearing link that editors should have normalized before publication. Snowflake’s comparison page is the primary source for both observations.

This matters because the article asks readers to accept broad conclusions—“true openness,” “true RBAC,” “zero egress” and “turnkey” disaster recovery—from a vendor evaluating its closest rival. A search redirect is not necessarily a dead source, but it inserts another resolution step between a claim and the documentation meant to support it. Procurement teams should replace every wrapped link with the canonical documentation URL, preserve the page version they reviewed and test the claimed behavior in their own accounts.

One example shows why primary docs beat the comparison

Snowflake characterizes Databricks role assumption as a retrofitted group mechanism. Databricks’ own documentation supplies the behavior that an agent operator actually needs to validate: assuming a role replaces rather than combines the identity’s accumulated permissions; only one role can be active; audit logs record both the person running the session and the assumed role; and assets created in that session are owned by the role. Databricks also says the capability must be enabled as a preview at both account and workspace level. Databricks RBAC documentation supports those details.

The same docs expose limits that a platform comparison can flatten. Databricks says an application can authorize as a role a connected user may assume, but an application service principal cannot yet assume a role for machine-to-machine access. It also lists partial support for lineage and no role support for creating Agent Bricks agents or Lakeflow pipelines. Databricks’ limitations page names those boundaries.

For an NL2SQL deployment, that turns a vendor argument into a concrete acceptance test: run the same query as the user, as the assumed role and as the service principal; verify the result set and denial behavior; then inspect audit attribution and asset ownership. The winner is not the page with the sharpest adjectives. It is the platform whose observed permission path matches the identity model your agent will actually use.