Snowflake vs MotherDuck

Agent ops

1. ai-native userMy agent can run governed SQL end to end — authenticate, discover schemas, query, and read results back through a CLI or API with no dashboard in the loop

   weight 3 · round drawn
   Snowflake✓fullprobed8/10

   Snowflake provides multiple governed, non-dashboard paths for an agent to run SQL end-to-end: the SQL API (REST) for authenticating and executing queries/managing objects, the Snowflake CLI for programmatic access, RBAC/access history for governance, and a Snowflake-managed MCP server that lets agents securely retrieve data and execute SQL as tools without deploying infrastructure. missing for 10: independent/hands-on third-party validation of the full agent workflow (auth→discover→query→read-results) via CLI/API/MCP, and explicit documentation of schema-discovery APIs (e.g., information_schema access) tied directly to the MCP/SQL API flow.

   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [claimed-docs] “You can use this API to develop custom applications and integrations that: Perform queries, Manage your deployment (e.g. provision users and…”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”
   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Access History in Snowflake refers to when the user query reads data and when the SQL statement performs a data write operation... The user …”
   • [probe] “official MCP server documented at https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp”
   • [probe] “official CLI documented at https://docs.snowflake.com/en/developer-guide/snowflake-cli/index”

   proof ↗⚑ flag

   MotherDuck✓fullprobed8/10

   MotherDuck ships official CLI/SDK/API access (docs-1, docs-2, docs-25), a documented auth flow with local credential caching (docs-8, docs-20), and both local and remote MCP servers that execute read-only/read-write SQL and support schema/context discovery via 'Guides' (docs-30, docs-49, docs-38), letting an agent authenticate, discover, query and read results with no dashboard involved. This is corroborated by runtime probes showing a real authenticated MCP handshake plus executed aggregate SQL query (motherduck-probe-rt-2) and a live OAuth-gated remote MCP endpoint (motherduck-probe-rt-3). Missing for 10: an end-to-end demonstration against an authenticated (non-keyless) MotherDuck cloud database showing schema discovery + query + result retrieval in one continuous agent session, and clearer documentation of a dedicated schema-listing API beyond Guides.

   • [claimed-docs] “Connect to MotherDuck using official drivers and APIs for various programming languages.”
   • [claimed-docs] “you can securely save your credentials locally”
   • [claimed-docs] “If you are using Python or CLI and don't want to authenticate every session, you can securely save your credentials locally.”
   • [claimed-docs] “Read and write Guides — markdown documents that capture your org's metric definitions, join conventions, and domain context, so agents produ…”
   • [claimed-docs] “To restrict your AI assistant to read-only access, see Restricting to read-only access”
   • [claimed-docs] “The remote MCP server exposes both read-only and read-write tools.”
   • [claimed-docs] “With the remote MCP server, your agent can: - Execute read-only and read-write SQL against your databases”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”
   • [probe] “official CLI documented at https://duckdb.org/docs/installation/”

   proof ↗⚑ flag

2. ai-native userA built-in AI assistant writes, fixes, and explains SQL against my schemas from natural language, inside the product

   weight 2 · round to MotherDuck
   Snowflake~partialclaimed7/10

   Cortex Analyst is a built-in, documented Snowflake feature that lets users ask questions in natural language and get answers 'without writing SQL,' implying it generates and runs SQL against the user's schema inside Snowsight; Cortex AI Functions and Notebooks further support SQL/Python assistance in-product. However, the evidence never explicitly shows the assistant 'fixing' or 'explaining' existing SQL (vs. generating it from scratch), and there's no independent/hands-on corroboration of accuracy or workflow beyond first-party docs. Missing for 10: explicit fix/explain-SQL capability documentation, and independent/community validation of the NL-to-SQL experience.

   • [claimed-docs] “With Cortex Analyst, business users can ask questions in natural language and receive direct answers without writing SQL.”
   • [claimed-docs] “business users can ask questions in natural language and receive direct answers without writing SQL”
   • [claimed-docs] “Use Cortex AI Functions in Snowflake to run unstructured analytics on text and images with industry-leading LLMs from OpenAI, Anthropic, Met…”
   • [claimed-docs] “Use Cortex AI Functions in Snowflake to run unstructured analytics on text and images with industry-leading LLMs”
   • [claimed-docs] “Write SQL or Python code and quickly compare results with cell-by-cell development and execution.”
   • [claimed-docs] “Snowflake Notebooks is a unified development interface in Snowsight that offers an interactive, cell-based programming environment for Pytho…”

   proof ↗⚑ flag

   MotherDuck✓fullprobed8/10

   MotherDuck ships both a remote MCP server and a Dives natural-language interface that write, execute, and iteratively refine SQL/visualizations against user schemas via conversational prompts (e.g., 'add a filter for US region', 'build a chart of top 10 products'), and runtime probes confirm the MCP handshake and real query execution work end-to-end. Guides let the assistant learn schema/metric context to produce accurate SQL without repetitive prompting, directly matching the story's 'against my schemas' requirement. missing for 10: independent hands-on evidence specifically of the assistant 'explaining' or fixing broken SQL (evidence focuses on generation/iteration, not debugging existing queries), and broader third-party corroboration beyond vendor docs.

   • [claimed-docs] “Analyze your data with natural language using the remote MCP Server”
   • [claimed-docs] “Build a Dive with a chart of our top 10 products by sales volume. Use MotherDuck's brand colors”
   • [claimed-docs] “you iterate conversationally ("add a filter for US region", "switch to a bar chart") and the Viewer updates in place.”
   • [claimed-docs] “The MotherDuck remote MCP Server lets you analyze your data using natural language and generate interactive visualizations, all without writ…”
   • [claimed-docs] “Read and write Guides — markdown documents that capture your org's metric definitions, join conventions, and domain context, so agents produ…”
   • [claimed-docs] “The remote MCP server exposes both read-only and read-write tools.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”

   proof ↗⚑ flag

3. ai-native userBusiness users can ask questions in natural language and get governed, semantically-grounded answers rather than hallucinated joins

   weight 1 · round to Snowflake
   Snowflake✓fullclaimed7/10

   Snowflake's Cortex Analyst is documented to let business users ask natural-language questions and get direct answers without writing SQL, and Snowflake Semantic Views let teams define business metrics/entities as governed semantic layer objects that Cortex Analyst can ground against, with RBAC controlling access to underlying data. This directly matches the story's ask for governed, semantically-grounded NL answers rather than raw hallucinated joins. missing for 10: independent/hands-on evidence validating accuracy or hallucination-reduction claims, and no detail on how Cortex Analyst explicitly enforces the semantic model to prevent bad joins (only first-party docs, no third-party corroboration).

   • [claimed-docs] “With Cortex Analyst, business users can ask questions in natural language and receive direct answers without writing SQL.”
   • [claimed-docs] “business users can ask questions in natural language and receive direct answers without writing SQL”
   • [claimed-docs] “You can store semantic business concepts directly in the database in a Semantic View, which is a schema-level object. You can define busines…”
   • [claimed-docs] “You can define business metrics and model business entities and their relationships.”
   • [claimed-docs] “You can store semantic business concepts directly in the database in a Semantic View ... define business metrics and model business entities…”
   • [claimed-docs] “You can store semantic business concepts directly in the database in a Semantic View, which is a schema-level object.”
   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users”

   proof ↗⚑ flag

   MotherDuck~partialprobed6/10

   MotherDuck ships concrete building blocks for this story: MCP-based natural-language querying (Dives, remote/local MCP servers) and 'Guides' — markdown docs capturing org metric definitions, join conventions, and domain context so agents produce accurate SQL without repetitive prompting, i.e. a governance/semantic-grounding mechanism directly aimed at preventing hallucinated joins. Governance controls (read-only restriction, SaaS Mode, role-based Shares) reinforce this for business users. Missing for 10: independent/hands-on evidence that Guides actually reduce hallucinated joins in practice, no case study or benchmark showing accuracy improvement, and the semantic layer relies on manually authored Guides rather than an automated governed semantic model.

   • [claimed-docs] “Read and write Guides — markdown documents that capture your org's metric definitions, join conventions, and domain context, so agents produ…”
   • [claimed-docs] “To restrict your AI assistant to read-only access, see Restricting to read-only access”
   • [claimed-docs] “The remote MCP server exposes both read-only and read-write tools.”
   • [claimed-docs] “With the remote MCP server, your agent can: - Execute read-only and read-write SQL against your databases”
   • [claimed-docs] “The MotherDuck remote MCP Server lets you analyze your data using natural language and generate interactive visualizations, all without writ…”
   • [claimed-docs] “Build a Dive with a chart of our top 10 products by sales volume. Use MotherDuck's brand colors”
   • [claimed-docs] “you iterate conversationally ("add a filter for US region", "switch to a bar chart") and the Viewer updates in place.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”

   proof ↗⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Snowflake✓fullprobed9/10

   Snowflake publishes a root llms.txt (confirmed via live probe, HTTP 200) summarizing the platform, plus dedicated llms.txt files for individual products like Snowpark, Streamlit, and Snowflake Postgres, giving agents a structured, agent-oriented entry point into the docs. missing for 10: independent/third-party confirmation that agents successfully consume these llms.txt files in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.snowflake.com/llms.txt # Snowflake Documentation > Snowflake is a cloud data platform providing da…”
   • [claimed-docs] “Snowpark API for Python, Java, and Scala — process data at scale inside Snowflake.”
   • [claimed-docs] “Build and deploy interactive Streamlit apps directly inside Snowflake.”
   • [claimed-docs] “Managed Postgres instances running directly inside Snowflake.”

   proof ↗⚑ flag

   MotherDuck✓fullprobed9/10

   MotherDuck publishes a working llms.txt (HTTP 200, verified content) and goes further with a first-class agent-discovery surface: an agentskills.io-conformant manifest at /.well-known/agent-skills/index.json, /.well-known/mcp.json, and an every-page-as-markdown convention, explicitly framed as agent-oriented docs. This directly matches the story of pointing an agent at llms.txt or agent docs. Missing for 10: independent/community confirmation that an agent successfully consumed these files in practice (only first-party probes cited).

   • [probe] “PROBE llms.txt: HTTP 200 at https://motherduck.com/llms.txt # MotherDuck MotherDuck is a modern serverless data warehouse built on DuckDB. …”
   • [probe] “PROBE runtime (recorded 2026-09-06): MotherDuck publishes an agentskills.io-conformant discovery manifest at /.well-known/agent-skills/index…”
   • [probe] “official MCP server documented at https://motherduck.com/docs/sql-reference/mcp/”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round drawn
   Snowflake✓fullprobed8/10

   Snowflake ships an official CLI for managing apps/workloads and REST APIs (SQL API and Resource Management API) explicitly designed for programmatic, non-interactive integration and automation, which are the standard mechanisms for running Snowflake operations headlessly in CI pipelines. missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions integration) and documentation of non-interactive auth flows (key-pair/OAuth) tailored for headless automation.

   • [claimed-docs] “With Snowflake CLI, developers can create, manage, update, and view apps running on Snowflake across workloads such as Streamlit in Snowflak…”
   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “You can use this API to develop custom applications and integrations that: Perform queries, Manage your deployment (e.g. provision users and…”
   • [probe] “official CLI documented at https://docs.snowflake.com/en/developer-guide/snowflake-cli/index”

   proof ↗⚑ flag

   MotherDuck✓fullprobed8/10

   MotherDuck supports headless/CI automation via CLI, Python SDKs, saved credentials for non-interactive sessions, and scheduled Python jobs for ingest/transformation; dbt integration and SaaS Mode further support scripted, non-interactive pipelines. Runtime probes confirm a keyless CLI roundtrip and a fully automatable MCP server flow, both consistent with CI usage. Missing for 10: an explicit CI/CD example (e.g., GitHub Actions workflow) or documented non-interactive auth token flow for pipelines.

   • [claimed-docs] “Run Python jobs on a schedule for ingest, transformation, and operational tasks”
   • [claimed-docs] “you can securely save your credentials locally”
   • [claimed-docs] “If you are using Python or CLI and don't want to authenticate every session, you can securely save your credentials locally.”
   • [claimed-docs] “You can limit MotherDuck's ability to interact with your local environment using SaaS Mode”
   • [claimed-docs] “dbt-duckdb is the adapter which allows dbt to use DuckDB and MotherDuck.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the engine under MotherDuck ran FULLY keyless on a laptop — `duckdb -c` built a 1,000,000-row table and…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Snowflake—none0/10

   Evidence documents Snowflake's own MCP server that exposes Snowflake's Cortex tools to external AI agents (server-side), but there is no evidence Snowflake can act as an MCP client consuming external MCP servers' tools to extend Cortex Agents or CoWork/CoCo's capabilities.

   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to”
   • [probe] “official MCP server documented at https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp”

   proof ↗⚑ flag

   MotherDuck—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

4. ai-native userConnect an agent via an official MCP server

   weight 3 · round drawn
   Snowflake✓fullprobed9/10

   Snowflake documents an official, Snowflake-managed MCP server (Cortex Agents MCP) that lets AI agents securely retrieve data without deploying separate infrastructure, and it can be configured to serve Cortex Analyst, Cortex Search, Cortex Agents, custom tools, and SQL execution as MCP tools. This is a first-party, GA-documented feature confirmed by a direct probe of the docs URL. Missing for 10: independent/hands-on third-party corroboration of real-world agent connections beyond vendor docs.

   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to”
   • [probe] “official MCP server documented at https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp”

   proof ↗⚑ flag

   MotherDuck✓fullprobed9/10

   MotherDuck ships both a remote hosted MCP server (api.motherduck.com/mcp, OAuth-secured) and an official local MCP server (mcp-server-motherduck), both well documented with read/write SQL tool access, and runtime probes confirm the local server completes a full stdio handshake and executes a real query, while the remote endpoint is live and speaks proper MCP OAuth. Missing for 10: no independent third-party hands-on report of the remote MCP server itself (only official docs and probes) and no community corroboration of production-grade reliability at scale.

   • [claimed-docs] “Analyze your data with natural language using the remote MCP Server”
   • [claimed-docs] “Local MCP server for DuckDB and MotherDuck”
   • [claimed-docs] “For local DuckDB databases, custom configurations, or self-hosted scenarios, use the local MCP server”
   • [claimed-docs] “use the **local MCP server** (mcp-server-motherduck)”
   • [claimed-docs] “The remote MCP server exposes both read-only and read-write tools.”
   • [claimed-docs] “With the remote MCP server, your agent can: - Execute read-only and read-write SQL against your databases”
   • [probe] “official MCP server documented at https://motherduck.com/docs/sql-reference/mcp/”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”

   proof ↗⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to Snowflake
   Snowflake✓fullprobed8/10

   Snowflake ships an official Snowflake CLI documented for creating, managing, updating, and viewing apps across Streamlit, Native Apps, Snowpark Container Services, and Snowpark, confirmed by a dedicated docs probe. It's a general developer CLI rather than one purpose-built for AI-native/agentic workflows specifically. Missing for 10: independent/hands-on corroboration of CLI usage, and explicit agentic-workflow-specific CLI features (vs. general app management).

   • [claimed-docs] “With Snowflake CLI, developers can create, manage, update, and view apps running on Snowflake across workloads such as Streamlit in Snowflak…”
   • [claimed-docs] “developers can create, manage, update, and view apps running on Snowflake across workloads”
   • [claimed-docs] “developers can create, manage, update, and view apps running on Snowflake across workloads such as Streamlit in Snowflake, the Snowflake Nat…”
   • [probe] “official CLI documented at https://docs.snowflake.com/en/developer-guide/snowflake-cli/index”

   proof ↗⚑ flag

   MotherDuck~partialprobed6/10

   MotherDuck relies on the DuckDB CLI (an official, third-party-maintained but DuckDB-branded CLI) to connect directly to MotherDuck, and docs describe CLI-based authentication/credential caching, but there is no MotherDuck-specific CLI (e.g., a 'motherduck' binary) with agentic/AI-native command features documented. missing for 10: a dedicated MotherDuck-branded CLI tool, evidence of AI-native/agentic command support within the CLI itself, and independent hands-on confirmation of CLI workflows beyond basic connection.

   • [claimed-docs] “Install the DuckDB CLI and connect directly to MotherDuck”
   • [claimed-docs] “you can securely save your credentials locally”
   • [claimed-docs] “If you are using Python or CLI and don't want to authenticate every session, you can securely save your credentials locally.”
   • [probe] “official CLI documented at https://duckdb.org/docs/installation/”

   proof ↗⚑ flag

6. ai-native userDrive the product through a documented public API

   weight 3 · round to MotherDuck
   Snowflake✓fullprobed8/10

   Snowflake documents a public REST API for resource management and a SQL API (both OpenAPI-compliant with an official spec repo and Postman collections) allowing programmatic querying, deployment management, and integration building, plus Snowpark APIs for Python/Java/Scala. This is well-documented first-party evidence of a documented public API surface usable by AI-native/automated clients. Missing for 10: independent hands-on developer corroboration of API robustness/limits, and a discoverable machine-readable openapi.json at the probed standard paths (probe returned 404s despite claims of OpenAPI compliance).

   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “You can use this API to develop custom applications and integrations that: Perform queries, Manage your deployment (e.g. provision users and…”
   • [claimed-docs] “Official snowflakedb/snowflake-rest-api-specs repo (specifications/ + collections/): "These REST APIs are compliant with the OpenAPI specifi…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.snowflake.com/openapi.json, https://docs.snowflake.com/swagger.json, https://docs.snowf…”

   proof ↗⚑ flag

   MotherDuck✓fullprobed9/10

   MotherDuck publishes a documented public API surface: official SDKs/drivers in multiple languages, a live OpenAPI spec (probe confirms HTTP 200 with 'openapi' key), and a documented SQL/MCP interface with both local and remote MCP servers verified working end-to-end at runtime. Machine-readable agent-skills and llms.txt manifests further support programmatic/AI-native access. missing for 10: no independent third-party API client review beyond MotherDuck's own docs/probes.

   • [probe] “PROBE openapi: HTTP 200 at https://motherduck.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Connect to MotherDuck using official drivers and APIs for various programming languages.”
   • [claimed-docs] “DuckDB SDKs: Python, Node.js, Go, Rust, R, Java”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”
   • [probe] “PROBE runtime (recorded 2026-09-06): MotherDuck publishes an agentskills.io-conformant discovery manifest at /.well-known/agent-skills/index…”
   • [claimed-docs] “With the remote MCP server, your agent can: - Execute read-only and read-write SQL against your databases”

   proof ↗⚑ flag

7. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to MotherDuck
   Snowflake~partialclaimed5/10

   Snowflake's RBAC system lets admins scope privileges to specific roles that can then be attached to service/API credentials, and its REST APIs plus the Cortex Agents MCP server explicitly support secure, credential-based programmatic access for AI agents. However, no evidence directly documents an agent-specific credential-issuance workflow (e.g., short-lived scoped tokens purpose-built for agent identities) — the story is inferred from general RBAC/API docs rather than an agent-specific credentialing feature. Missing for 10: explicit documentation of issuing least-privilege, agent-scoped API keys/tokens (vs. general RBAC/roles), and any hands-on/independent confirmation of this workflow.

   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users”
   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to”

   proof ↗⚑ flag

   MotherDuck~partialprobed6/10

   MotherDuck documents concrete least-privilege options for agent access: restricting an AI assistant/MCP client to read-only SQL access, SaaS Mode to limit local environment interaction, and role/account-scoped Shares for multi-tenant isolation, plus a probed OAuth-protected resource flow on the hosted remote MCP endpoint (401 + WWW-Authenticate Bearer) confirming a real scoped-auth mechanism. However, there is no documented ability to mint a distinct, narrowly-scoped API key/token per agent (e.g. table- or query-level permission grants beyond read/write toggle), so it's read-only-vs-read-write plus share-based isolation rather than fine-grained credential issuance. Missing for 10: granular per-resource API key scoping beyond binary read-only/read-write, first-class 'create scoped credential for agent X' workflow, independent verification of the read-only restriction in practice.

   • [claimed-docs] “To restrict your AI assistant to read-only access, see Restricting to read-only access”
   • [claimed-docs] “The remote MCP server exposes both read-only and read-write tools.”
   • [claimed-docs] “With the remote MCP server, your agent can: - Execute read-only and read-write SQL against your databases”
   • [claimed-docs] “You can limit MotherDuck's ability to interact with your local environment using SaaS Mode”
   • [claimed-docs] “Sharing data with specific preset roles or accounts in your organization. This is popular with data application builders that need to isolat…”
   • [claimed-docs] “Secrets are scoped to your user account and are not shared with other users in your organization.”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”

   proof ↗⚑ flag

8. ai-native userBuild against official SDKs

   weight 2 · round to MotherDuck
   Snowflake✓fullprobed7/10

   Snowflake documents multiple official SDKs/APIs for developers—Snowpark API for Python, Java, and Scala, the Snowflake SQL API, and REST APIs for resource management with OpenAPI specifications hosted in an official GitHub repo—plus a managed MCP server letting AI agents interact with Snowflake without custom infrastructure, directly supporting AI-native build patterns. Missing for 10: independent/hands-on developer corroboration of SDK quality/ergonomics and more explicit agent-framework integration examples beyond MCP.

   • [claimed-docs] “Snowpark API for Python, Java, and Scala — process data at scale inside Snowflake.”
   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “You can use this API to develop custom applications and integrations that: Perform queries, Manage your deployment (e.g. provision users and…”
   • [claimed-docs] “Official snowflakedb/snowflake-rest-api-specs repo (specifications/ + collections/): "These REST APIs are compliant with the OpenAPI specifi…”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”
   • [probe] “official MCP server documented at https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-agents-mcp”

   proof ↗⚑ flag

   MotherDuck✓fullprobed8/10

   MotherDuck documents official SDKs across multiple languages (Python, Node.js, Go, Rust, R, Java) built on DuckDB, plus an official CLI, MCP servers (local and remote), and an OpenAPI spec confirmed by probes. This directly supports AI-native/agentic developers building against official interfaces, with runtime probes confirming keyless SDK, CLI, and MCP functionality. Missing for 10: independent third-party benchmarking or reviews of SDK completeness/quality beyond vendor docs.

   • [claimed-docs] “DuckDB SDKs: Python, Node.js, Go, Rust, R, Java”
   • [claimed-docs] “Connect to MotherDuck using official drivers and APIs for various programming languages.”
   • [probe] “PROBE openapi: HTTP 200 at https://motherduck.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://motherduck.com/docs/sql-reference/mcp/”
   • [probe] “official CLI documented at https://duckdb.org/docs/installation/”
   • [probe] “PROBE runtime (recorded 2026-09-06): the engine under MotherDuck ran FULLY keyless on a laptop — `duckdb -c` built a 1,000,000-row table and…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”

   proof ↗⚑ flag

9. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Snowflake—none0/10

   Evidence shows Snowflake supports streams for CDC (polled) and notification integrations for cost alerts, but there is no documentation of a general-purpose webhook subscription mechanism that lets an AI-native user subscribe to events pushed via webhooks. Absence of evidence for this applicable capability yields 'none'.

   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables, including inserts (including COPY INTO), updates, and delet…”
   • [claimed-docs] “Notification integrations for cost anomaly alerts (General availability)”
   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables... so that actions can be taken using the changed data”

   proof ↗⚑ flag

   MotherDuck—none0/10

   MotherDuck offers MCP servers, scheduled jobs, and data sharing, but nothing in the evidence describes a webhook subscription mechanism for event notifications. Missing for 10: any webhook endpoint registration, event-driven push notification system, or documentation of subscribable events.

   ⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round drawn
   Snowflake✓fullclaimed8/10

   Snowflake ships Cortex AI Functions for LLM-powered unstructured analytics on data in-place, and Cortex Analyst lets business users ask natural-language questions and get direct answers without SQL, plus semantic views to ground these insights in business context — all inside the product. missing for 10: independent/hands-on validation of insight quality and no evidence of proactive/automated suggestion surfacing (e.g., anomaly-based recommendations) beyond query-driven Q&A.

   • [claimed-docs] “Use Cortex AI Functions in Snowflake to run unstructured analytics on text and images with industry-leading LLMs from OpenAI, Anthropic, Met…”
   • [claimed-docs] “With Cortex Analyst, business users can ask questions in natural language and receive direct answers without writing SQL.”
   • [claimed-docs] “business users can ask questions in natural language and receive direct answers without writing SQL”
   • [claimed-docs] “Use Cortex AI Functions in Snowflake to run unstructured analytics on text and images with industry-leading LLMs”
   • [claimed-docs] “You can store semantic business concepts directly in the database in a Semantic View, which is a schema-level object. You can define busines…”
   • [claimed-docs] “You can store semantic business concepts directly in the database in a Semantic View ... define business metrics and model business entities…”

   proof ↗⚑ flag

   MotherDuck✓fullprobed8/10

   MotherDuck's 'Dives' feature and MCP integration let users generate charts, dashboards, and insights via natural language prompts ('build a Dive with a chart of top 10 products', 'add a filter for US region'), with conversational iteration and no SQL required, confirmed by both docs and a runtime probe showing a working MCP tool call returning real query results. Missing for 10: independent/community hands-on validation specifically of the Dives/insights UX (community evidence covers MCP and SQL editor features but not Dives directly), and no evidence of proactive/unprompted AI-generated suggestions (all examples are user-initiated prompts).

   • [claimed-docs] “Generate interactive, shareable dashboards from natural language prompts”
   • [claimed-docs] “Build a Dive with a chart of our top 10 products by sales volume. Use MotherDuck's brand colors”
   • [claimed-docs] “Add a filter for the US region only”
   • [claimed-docs] “you iterate conversationally ("add a filter for US region", "switch to a bar chart") and the Viewer updates in place.”
   • [claimed-docs] “The MotherDuck remote MCP Server lets you analyze your data using natural language and generate interactive visualizations, all without writ…”
   • [claimed-docs] “you can refine it through conversation: "Add a filter for the US region only"”
   • [claimed-docs] “You iterate conversationally (_"add a filter for US region"_, _"switch to a bar chart"_) and the Viewer updates in place.”
   • [claimed-docs] “Change the chart to a stacked bar chart”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Snowflake~partialclaimed5/10

   Snowflake documents several building blocks for background automation — Snowpipe auto-ingests files without manual scheduling, Dynamic Tables (GA) auto-refresh on a target lag, Streams capture DML changes to trigger downstream actions, and dbt Projects on Snowflake supports full orchestration of pipelines inside the platform. Cortex Agents plus the managed MCP server let AI agents query Snowflake data, but the evidence shows MCP as a request/response tool-serving interface rather than a documented mechanism for an AI-native user to schedule agents that run continuously and autonomously in the background. Missing for 10: explicit documentation of a Tasks/scheduler feature for autonomous job execution, evidence of agent-triggered/looping automations (not just query-based interactions), and independent/hands-on confirmation that these pieces compose into unattended AI-driven automation.

   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “CREATE OR ALTER DYNAMIC TABLE (General availability)”
   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables, including inserts (including COPY INTO), updates, and delet…”
   • [claimed-docs] “dbt Projects on Snowflake brings the full dbt lifecycle into Snowflake: develop, deploy, orchestrate, and observe your transformations”
   • [claimed-docs] “No infrastructure to manage: Snowflake provides managed dbt Core and dbt Fusion runtimes.”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”

   proof ↗⚑ flag

   MotherDuck~partialclaimed5/10

   MotherDuck documents scheduling Python jobs for ingest/transformation/operational tasks (docs-3), which supports background automations, but there is no evidence of a broader autonomous agent-scheduling framework, triggers, or orchestration for AI-driven background workflows beyond scheduled jobs. Missing for 10: evidence of autonomous agent-initiated scheduling/triggers, monitoring/retry of automated jobs, and independent confirmation of reliability of scheduled runs.

   • [claimed-docs] “Run Python jobs on a schedule for ingest, transformation, and operational tasks”
   • [claimed-docs] “Read and write Guides — markdown documents that capture your org's metric definitions, join conventions, and domain context, so agents produ…”
   • [claimed-docs] “With the remote MCP server, your agent can: - Execute read-only and read-write SQL against your databases”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to MotherDuck
   Snowflake~partialclaimed4/10

   Snowflake's homepage advertises 'Snowflake CoWork' ('Ask anything') and 'Snowflake CoCo' ('Build anything') as built-in enterprise AI assistants, and Cortex Analyst lets business users get natural-language answers without SQL — both suggest task delegation to an in-product assistant. However, the evidence pack has no dedicated docs page, feature list, or independent/hands-on account of CoWork/CoCo's actual task-delegation capabilities, so the claim rests on thin marketing taglines rather than substantiated documentation. Missing for 10: dedicated CoWork/CoCo documentation detailing task-delegation scope, hands-on or independent corroboration of the assistant performing multi-step tasks, and clarity on how it differs from Cortex Analyst's NL query feature.

   • [claimed-docs] “Ask anything with Snowflake CoWork. Build anything with Snowflake CoCo. Welcome to your one-stop shop for everyone in the enterprise.”
   • [claimed-docs] “Build anything with Snowflake CoCo.”
   • [claimed-docs] “With Cortex Analyst, business users can ask questions in natural language and receive direct answers without writing SQL.”
   • [claimed-docs] “business users can ask questions in natural language and receive direct answers without writing SQL”

   proof ↗⚑ flag

   MotherDuck~partialclaimed7/10

   MotherDuck ships 'Dives,' a native feature that lets users build and iteratively refine dashboards via natural-language prompts ('add a filter for US region', 'switch to a bar chart') directly inside the product, and it also exposes a remote MCP server for natural-language SQL and visualization generation. This is real built-in agentic behavior, but the natural-language SQL/agent capability is delivered mainly via MCP, which requires an external AI client (e.g., Claude) rather than a self-contained chat assistant, and there's no independent/hands-on corroboration of the Dives assistant experience. Missing for 10: independent hands-on validation of Dives as a true in-product chat assistant, and clarity on whether any AI runs natively without an external MCP-connected LLM client.

   • [claimed-docs] “Generate interactive, shareable dashboards from natural language prompts”
   • [claimed-docs] “Build a Dive with a chart of our top 10 products by sales volume. Use MotherDuck's brand colors”
   • [claimed-docs] “Add a filter for the US region only”
   • [claimed-docs] “you iterate conversationally ("add a filter for US region", "switch to a bar chart") and the Viewer updates in place.”
   • [claimed-docs] “you can refine it through conversation: "Add a filter for the US region only"”
   • [claimed-docs] “You iterate conversationally (_"add a filter for US region"_, _"switch to a bar chart"_) and the Viewer updates in place.”
   • [claimed-docs] “The MotherDuck remote MCP Server lets you analyze your data using natural language and generate interactive visualizations, all without writ…”
   • [claimed-docs] “Analyze your data with natural language using the remote MCP Server”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to MotherDuck
   Snowflake~partialclaimed7/10

   Snowflake documents genuine natural-language operation via Cortex Analyst (ask business questions in NL, get answers without writing SQL) and Cortex AI Functions for NL-driven analytics on text/images, plus a marketed 'CoWork'/'CoCo' NL agent interface and an MCP server exposing these NL/agent capabilities to external AI agents. This is solid support for AI-native NL interaction, but most of it is scoped to querying/analytics rather than full product administration (warehouses, security, pipelines) via natural language, and CoWork/CoCo are only marketing taglines with no detailed docs in the pack. Missing for 10: independent/hands-on validation of NL breadth, detailed CoWork/CoCo documentation, and evidence that operational/admin tasks (not just analytics) can be driven by natural language.

   • [claimed-docs] “With Cortex Analyst, business users can ask questions in natural language and receive direct answers without writing SQL.”
   • [claimed-docs] “business users can ask questions in natural language and receive direct answers without writing SQL”
   • [claimed-docs] “Use Cortex AI Functions in Snowflake to run unstructured analytics on text and images with industry-leading LLMs from OpenAI, Anthropic, Met…”
   • [claimed-docs] “Use Cortex AI Functions in Snowflake to run unstructured analytics on text and images with industry-leading LLMs”
   • [claimed-docs] “Ask anything with Snowflake CoWork. Build anything with Snowflake CoCo. Welcome to your one-stop shop for everyone in the enterprise.”
   • [claimed-docs] “Build anything with Snowflake CoCo.”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”

   proof ↗⚑ flag

   MotherDuck✓fullprobed8/10

   MotherDuck ships natural-language interaction via 'Dives' (NL-to-dashboard generation with conversational refinement like 'add a filter for US region') and both local and remote MCP servers that let AI agents run SQL from natural-language prompts without writing SQL themselves; runtime probes confirm the MCP server actually executes real analytical queries end-to-end. missing for 10: independent/community validation specifically of the natural-language accuracy (only vendor docs and technical probes, no hands-on user review of NL command quality).

   • [claimed-docs] “Generate interactive, shareable dashboards from natural language prompts”
   • [claimed-docs] “Analyze your data with natural language using the remote MCP Server”
   • [claimed-docs] “Build a Dive with a chart of our top 10 products by sales volume. Use MotherDuck's brand colors”
   • [claimed-docs] “you iterate conversationally ("add a filter for US region", "switch to a bar chart") and the Viewer updates in place.”
   • [claimed-docs] “The MotherDuck remote MCP Server lets you analyze your data using natural language and generate interactive visualizations, all without writ…”
   • [claimed-docs] “you can refine it through conversation: "Add a filter for the US region only"”
   • [claimed-docs] “You iterate conversationally (_"add a filter for US region"_, _"switch to a bar chart"_) and the Viewer updates in place.”
   • [claimed-docs] “Change the chart to a stacked bar chart”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”
   • [probe] “PROBE runtime (recorded 2026-09-06): MotherDuck publishes an agentskills.io-conformant discovery manifest at /.well-known/agent-skills/index…”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Snowflake
   Snowflake~partialprobed3/10

   Snowflake publishes OpenAPI-compliant spec files and importable Postman collections for its REST/SQL APIs, which gives developers a way to run example requests, but there is no evidence of an embedded, interactive 'try-it' API reference on the docs site itself — a direct probe for openapi.json/swagger endpoints returned 404s. Missing for 10: an in-browser interactive API explorer (e.g., Swagger/Redoc UI) hosted by Snowflake, and any independent confirmation that the Postman-based workflow is commonly used as a live API reference.

   • [claimed-docs] “Official snowflakedb/snowflake-rest-api-specs repo (specifications/ + collections/): "These REST APIs are compliant with the OpenAPI specifi…”
   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “You can use this API to develop custom applications and integrations that: Perform queries, Manage your deployment (e.g. provision users and…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.snowflake.com/openapi.json, https://docs.snowflake.com/swagger.json, https://docs.snowf…”

   proof ↗⚑ flag

   MotherDuck—none0/10

   The evidence shows an OpenAPI spec exists at /openapi.json (a machine-readable schema) and various driver/API docs, but there is no evidence of an actual interactive reference UI (e.g., Swagger-style 'try it' console) or runnable in-browser examples tied to that spec. missing for 10: an interactive API explorer page, runnable/live code examples, and any confirmation the OpenAPI spec is surfaced as a browsable interactive reference.

   • [probe] “PROBE openapi: HTTP 200 at https://motherduck.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Connect to MotherDuck using official drivers and APIs for various programming languages.”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to MotherDuck
   Snowflake✓fullprobed8/10

   Snowflake publishes an official, first-party GitHub repository (snowflakedb/snowflake-rest-api-specs) containing downloadable OpenAPI-compliant spec files plus Postman collections for its REST APIs, and its own docs explicitly state the REST APIs are 'compliant with the OpenAPI specification' and enable building integrations 'using the openAPI specifications.' Missing for 10: a directly hosted /openapi.json or /swagger.json endpoint on the docs site itself (probe found 404s there), so the machine-readable spec must be fetched from the separate GitHub repo rather than a single canonical URL.

   • [claimed-docs] “Official snowflakedb/snowflake-rest-api-specs repo (specifications/ + collections/): "These REST APIs are compliant with the OpenAPI specifi…”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.snowflake.com/openapi.json, https://docs.snowflake.com/swagger.json, https://docs.snowf…”

   proof ↗⚑ flag

   MotherDuck✓fullprobed9/10

   A live OpenAPI JSON spec is confirmed at https://motherduck.com/openapi.json (HTTP 200, contains 'openapi' key), directly satisfying the machine-readable API spec requirement; MotherDuck also publishes additional machine-readable discovery surfaces (llms.txt, agent-skills manifest, mcp.json). Missing for 10: independent third-party confirmation/discussion of the OpenAPI spec's completeness or usage in the community evidence.

   • [probe] “PROBE openapi: HTTP 200 at https://motherduck.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE runtime (recorded 2026-09-06): MotherDuck publishes an agentskills.io-conformant discovery manifest at /.well-known/agent-skills/index…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://motherduck.com/llms.txt # MotherDuck MotherDuck is a modern serverless data warehouse built on DuckDB. …”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round drawn
   Snowflake~partialclaimed5/10

   Snowflake's zero-copy cloning (object-clone) lets users create full database/schema clones inheriting privileges without duplicating or altering production data, which supports building an isolated sandbox for testing, and RBAC plus resource monitors help isolate/limit that environment. However, the evidence never frames this explicitly as an 'AI-native sandbox' workflow or ties cloning to agentic/AI testing use cases. missing for 10: explicit sandbox/dev-test documentation framed for AI-native or agent workflows, guidance on isolating agent test runs from prod data, and independent corroboration of clone-based sandboxing in practice.

   • [claimed-docs] “the clone inherits all granted privileges on the clones of all child objects contained in the source object”
   • [claimed-docs] “If the source object is a database or schema, the clone inherits all granted privileges on the clones of all child objects contained in the …”
   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users”

   proof ↗⚑ flag

   MotherDuck~partialprobed5/10

   MotherDuck supports local/in-memory DuckDB development (via CLI or local MCP server) that lets an agent run real analytical queries with zero MotherDuck account or production data touched, and offers read-only restriction and SaaS Mode to limit AI/agent access to local environment before syncing to cloud (docs-18, docs-31, docs-9, probe-rt-2). However, there is no dedicated 'sandbox' or database-branching feature that clones or isolates production data for testing—developers must manually use local files or in-memory DBs instead. Missing for 10: an explicit sandbox/branch/clone-of-production feature, first-party guidance framing this as a test-vs-prod workflow, and independent confirmation of safe isolation from prod data.

   • [claimed-docs] “Develop and iterate locally, then share and scale in the cloud when you need it.”
   • [claimed-docs] “You can limit MotherDuck's ability to interact with your local environment using SaaS Mode”
   • [claimed-docs] “To restrict your AI assistant to read-only access, see Restricting to read-only access”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [claimed-docs] “You can limit MotherDuck's ability to interact with your local environment using \`SaaS Mode\`”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round to Snowflake
   Snowflake~partialclaimed6/10

   Snowflake documents official REST APIs (SQL API, resource-management API) built on OpenAPI specs, and maintains a dedicated 'Behavior change announcements' page describing dated bundles of changes meant to minimize disruption — functioning as a de facto deprecation/change policy. However, there's no explicit documentation of API version numbers (v1/v2) or formal deprecation timelines/sunset dates for the APIs themselves. Missing for 10: explicit API versioning scheme documentation, formal deprecation timeline/sunset policy tied to specific API versions, independent corroboration of API stability guarantees.

   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [claimed-docs] “Official snowflakedb/snowflake-rest-api-specs repo (specifications/ + collections/): "These REST APIs are compliant with the OpenAPI specifi…”
   • [claimed-docs] “Docs, "Behavior change announcements": "To help you manage your operations and minimize disruption to your Snowflake service, we document be…”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “You can use this API to develop custom applications and integrations that: Perform queries, Manage your deployment (e.g. provision users and…”

   proof ↗⚑ flag

   MotherDuck—none0/10

   While MotherDuck exposes an OpenAPI spec and various SDKs/drivers, the evidence pack contains no mention of API versioning scheme or a documented deprecation policy for its APIs, drivers, or MCP servers. Missing for 10: any docs describing API version numbers, backward-compatibility guarantees, or a deprecation/sunset policy.

   • [probe] “PROBE openapi: HTTP 200 at https://motherduck.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Snowflake~partialclaimed6/10

   Snowflake supports bulk/batch operations via SQL (COPY INTO, Snowpipe micro-batches), Snowpark for programmatic bulk data processing, REST/SQL APIs for scripted batch operations, and CLI/dbt for orchestrating multi-object workflows, but these are general data-platform bulk operations rather than an AI-native agent-oriented bulk-action capability explicitly designed for AI agents to invoke across many items at once. The MCP server (Cortex Agents MCP) exposes tools for agents but evidence doesn't show explicit bulk/batch operation support through that interface. missing for 10: explicit documentation of AI-agent-initiated bulk operations (e.g., MCP server batch tool calls across many items), hands-on/independent evidence of AI-native bulk workflows succeeding at scale, and any agent-specific bulk-action API beyond generic SQL/REST batch capabilities.

   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables, including inserts (including COPY INTO), updates, and delet…”
   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [claimed-docs] “Snowpark API for Python, Java, and Scala — process data at scale inside Snowflake.”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”

   proof ↗⚑ flag

   MotherDuck~partialprobed6/10

   SQL is inherently set-based, and MotherDuck documents bulk data loading (from Postgres/MySQL, S3, DuckDB files) and read-write SQL execution via both local and remote MCP servers, which lets an AI agent issue bulk INSERT/UPDATE/COPY operations across many rows or tables in one call. However, there's no explicit documentation of an AI-native 'bulk operations across many items' primitive (e.g., batch MCP tool calls, bulk-apply-to-many-objects UX) — the evidence shows general bulk data movement/SQL rather than an agent-oriented batch-processing feature. Missing for 10: explicit agent-facing batch/bulk-operation tooling or examples, and independent confirmation of large-scale bulk SQL runs via MCP.

   • [claimed-docs] “Load your data from other databases and object storage”
   • [claimed-docs] “Execute read-only and read-write SQL against your databases”
   • [claimed-docs] “Load a DuckDB database into MotherDuck: Upload a local DuckDB database file to MotherDuck cloud storage.”
   • [claimed-docs] “Learn to load a table from your PostgreSQL or MySQL database into MotherDuck.”
   • [claimed-docs] “You can safely store your Amazon S3 credentials in MotherDuck for convenience by creating a SECRET object”
   • [claimed-docs] “With the remote MCP server, your agent can: - Execute read-only and read-write SQL against your databases”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Snowflake
   Snowflake~partialclaimed6/10

   Snowflake offers building blocks that support event-driven automation — Streams capture DML changes for downstream actions, Snowpipe auto-ingests new files, resource monitors can auto-suspend warehouses on cost thresholds, and anomaly monitors trigger notification alerts — but there is no single unified 'rules engine' or declarative trigger-action framework exposed as one product for AI-native users to define arbitrary event-condition-action automations. missing for 10: a first-class, general-purpose rules/trigger-action framework (e.g., 'if X event then do Y') rather than disparate feature-specific mechanisms (streams+tasks, Snowpipe, resource monitors), and independent/hands-on evidence of composing these into end-to-end automated workflows.

   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables, including inserts (including COPY INTO), updates, and delet…”
   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables... so that actions can be taken using the changed data”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they’re available in a stage”
   • [claimed-docs] “You can use a resource monitor to monitor credit usage by virtual warehouses ... You can also set up a resource monitor to suspend a standar…”
   • [claimed-docs] “you can set up a resource monitor to suspend a standard virtual warehouse or disable an Adaptive Warehouse when it reaches a credit limit”
   • [claimed-docs] “Anomaly monitors for cost anomalies (Preview)”
   • [claimed-docs] “Notification integrations for cost anomaly alerts (General availability)”

   proof ↗⚑ flag

   MotherDuck—none0/10

   Evidence shows scheduled Python jobs (time-based cron-style automation) but no capability for defining rules that trigger actions automatically on data or system events (e.g., event-driven triggers, alerts, webhooks on conditions). This is a fair axis for a data platform, but no evidence supports event-driven rule automation.

   • [claimed-docs] “Run Python jobs on a schedule for ingest, transformation, and operational tasks”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Snowflake~partialclaimed4/10

   Evidence shows dbt Projects on Snowflake can 'orchestrate' transformations with a managed runtime, implying some recurring-job scheduling capability, but the pack contains no direct documentation of Snowflake's native TASK/scheduler object or agent-triggered recurring workflows for AI-native users. Missing for 10: explicit docs on Snowflake Tasks or a scheduler API, evidence of AI agents creating/managing recurring jobs via MCP or CLI, and independent/hands-on confirmation of scheduling reliability.

   • [claimed-docs] “dbt Projects on Snowflake brings the full dbt lifecycle into Snowflake: develop, deploy, orchestrate, and observe your transformations in th…”
   • [claimed-docs] “dbt Projects on Snowflake brings the full dbt lifecycle into Snowflake: develop, deploy, orchestrate, and observe your transformations”
   • [claimed-docs] “No infrastructure to manage: Snowflake provides managed dbt Core and dbt Fusion runtimes.”

   proof ↗⚑ flag

   MotherDuck~partialclaimed4/10

   Docs mention running Python jobs 'on a schedule for ingest, transformation, and operational tasks' (motherduck-docs-3), indicating some support for recurring automation, but there is no detail on how scheduling is configured (cron syntax, UI, triggers) nor independent verification of this capability. Missing for 10: documented scheduling mechanism/UI, examples of workflow definitions, and independent or hands-on confirmation that recurring jobs actually run reliably.

   • [claimed-docs] “Run Python jobs on a schedule for ingest, transformation, and operational tasks”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Snowflake
   Snowflake~partialclaimed4/10

   Snowflake docs show building blocks that touch pieces of this story — dbt Projects on Snowflake covers the 'develop, deploy, orchestrate, observe' lifecycle (implying dbt's git-based versioning) [snowflake-docs-2][snowflake-docs-55], Time Travel lets you restore/rollback objects and query past states [snowflake-docs-5][snowflake-docs-24][snowflake-docs-35], and object cloning/behavior-change bundles give some notion of state snapshots and change tracking [snowflake-docs-67][snowflake-supp-behavior-changes]. However there is no dedicated, documented capability for versioning, reviewing, and rolling back 'automations' (e.g., Tasks, Dynamic Tables pipelines, agent workflows) as a first-class AI-native feature — the evidence is inferential rather than a direct product answer to this story. Missing for 10: explicit versioning/review/rollback tooling for Tasks/Dynamic Tables/agent pipelines, a documented approval/review workflow for automation changes, and independent/hands-on confirmation of rollback working for automations specifically.

   • [claimed-docs] “dbt Projects on Snowflake brings the full dbt lifecycle into Snowflake: develop, deploy, orchestrate, and observe your transformations in th…”
   • [claimed-docs] “dbt Projects on Snowflake brings the full dbt lifecycle into Snowflake: develop, deploy, orchestrate, and observe your transformations”
   • [claimed-docs] “Using Time Travel, you can perform the following actions within a defined period of time: Query data in the past that has since been updated…”
   • [claimed-docs] “Restoring objects that might have been accidentally or intentionally deleted.”
   • [claimed-docs] “Restoring objects that might have been accidentally or intentionally deleted. You can restore individual objects, such as tables, or restore…”
   • [claimed-docs] “the clone inherits all granted privileges on the clones of all child objects contained in the source object”
   • [claimed-docs] “Docs, "Behavior change announcements": "To help you manage your operations and minimize disruption to your Snowflake service, we document be…”

   proof ↗⚑ flag

   MotherDuck—none0/10

   MotherDuck documents scheduled Python jobs and AI-generated Dives, but nothing in the evidence describes versioning, reviewing, or rolling back these automations/schedules — no changelog, diff, approval, or rollback mechanism is mentioned anywhere in the docs or community evidence.

   ⚑ flag

Pricing

1. platform-engineerThe pricing model is documented clearly enough that I can estimate a monthly bill for my workload before committing

   weight 3 · round to MotherDuck
   Snowflake!disputedcontradicted5/10

   Snowflake docs explain the underlying cost model (credit-consuming virtual warehouses, resizing, resource monitors, cost-anomaly alerts, and a general pricing-tier page) which gives a platform engineer the mechanics needed to model cost, but there is no concrete rate card or calculator evidenced. Community reports concretely contradict the 'estimate before committing' claim: users note costs 'balloon pretty fast', warehouse credit consumption 'doubles each size up', there is 'no query level attribution of costs and no in-built features for monitoring', and it's 'easy... to get to $100k/year bills without massive data' — indicating the documented model is hard to translate into an accurate upfront estimate in practice. missing for 10: a transparent unit-price/rate table, a first-party cost calculator, and independent confirmation that engineers can reliably forecast bills from the docs alone.

   • [claimed-docs] “Virtual warehouses consume credits as they execute queries, load data and perform other DML operations. Virtual Warehouses are user-managed,…”
   • [claimed-docs] “Virtual Warehouses are user-managed, which means you can directly control credit consumption of these resources.”
   • [claimed-docs] “You can use a resource monitor to monitor credit usage by virtual warehouses ... You can also set up a resource monitor to suspend a standar…”
   • [claimed-docs] “you can set up a resource monitor to suspend a standard virtual warehouse or disable an Adaptive Warehouse when it reaches a credit limit”
   • [claimed-docs] “An entry-level, introductory offering providing access to core functionality.”
   • [claimed-docs] “Standard: An entry-level, introductory offering providing access to core functionality. ... Security with automatic encryption of all data, …”
   • [community] “Since the beginning of my trial, I have used 9 credits and 40GB of storage... about $19.60 worth of resources. Snowflake costs could balloon…”
   • [community] “The problem with Snowflake is particularly worse due to its lack of query level attribution of costs and no in-built features for monitoring…”
   • [community] “I have no Snowflake experience, but some limited BigQuery experience. And it's very easy for a small company to get to $100k/year bills with…”

   proof ↗⚑ flag

   MotherDuck~partialclaimed6/10

   MotherDuck documents billing mechanics well—per-second billing, sized instances (Pulse–Giga), a free Lite tier, and a billing dashboard with SQL views to monitor consumption and identify savings—giving a platform engineer real levers to reason about cost drivers. However, the evidence pack never surfaces an actual price list or $/instance-hour rate card needed to project a concrete monthly bill before signing up. Missing for 10: published per-instance-size dollar rates, a documented cost-estimation worksheet/example calculation, and independent confirmation that the dashboard estimates match real invoices.

   • [claimed-docs] “Size each instance to its job, Pulse through Giga.”
   • [claimed-docs] “Size each instance to its job, Pulse through Giga. Backfill on a Mega instance, run dbt workloads on a Standard, let end users query a fleet…”
   • [claimed-docs] “Moving to MotherDuck, a billed by-the-second cloud offering is a no-brainer for us, considering the elegance and efficiency of a single node…”
   • [claimed-docs] “MotherDuck provides SQL views and a billing dashboard to help you understand your compute and storage consumption.”
   • [claimed-docs] “Pricing docs: "New users who sign up for MotherDuck and create an organization automatically get access to a 7-day Free Trial without enteri…”
   • [claimed-docs] “Billing docs, "Monitoring usage and costs": "MotherDuck provides SQL views and a billing dashboard to help you understand your compute and s…”

   proof ↗⚑ flag

2. platform-engineerBudgets, resource monitors, or auto-suspend stop a runaway query or idle compute from burning money overnight

   weight 2 · round to Snowflake
   Snowflake✓fullcommunity8/10

   Snowflake ships resource monitors that track credit usage and can auto-suspend a virtual warehouse (or disable an Adaptive Warehouse) when a threshold is hit, plus GA cost-anomaly monitors, per-user quotas, and notification integrations for cost alerts, directly matching the platform-engineer need to stop runaway spend. Community commentary independently corroborates this as standard practice (setting up resource monitors and using small warehouses to control cost), and warehouses can also be manually started, stopped, and resized to control burn. Missing for 10: independent hands-on confirmation that resource monitors reliably kill an in-flight runaway query versus only suspending future warehouse starts, and detail on statement-level timeout controls.

   • [claimed-docs] “You can use a resource monitor to monitor credit usage by virtual warehouses ... You can also set up a resource monitor to suspend a standar…”
   • [claimed-docs] “you can set up a resource monitor to suspend a standard virtual warehouse or disable an Adaptive Warehouse when it reaches a credit limit”
   • [claimed-docs] “You can also set up a resource monitor to suspend a standard virtual warehouse or disable an Adaptive Warehouse when it reaches a credit lim…”
   • [claimed-docs] “Per-user quotas (General availability)”
   • [claimed-docs] “Anomaly monitors for cost anomalies (Preview)”
   • [claimed-docs] “Notification integrations for cost anomaly alerts (General availability)”
   • [claimed-docs] “Virtual warehouses consume credits as they execute queries, load data and perform other DML operations. Virtual Warehouses are user-managed,…”
   • [claimed-docs] “Warehouses can be started and stopped at any time. They can also be resized at any time, even while running, to accommodate the need for mor…”
   • [community] “Since the beginning of my trial, I have used 9 credits and 40GB of storage... about $19.60 worth of resources. Snowflake costs could balloon…”

   proof ↗⚑ flag

   MotherDuck~partialclaimed5/10

   MotherDuck docs confirm auto-suspend behavior ('idle instances shut down automatically, zero idle cost') and a billing dashboard/SQL views for monitoring compute and storage consumption, addressing the 'idle compute burning money' half of the story. However there is no evidence of configurable budgets, spend alerts/caps, or resource monitors that can kill a runaway query in progress — missing for 10: budget/spend-limit enforcement, automatic query cancellation on runaway cost, alerting thresholds tied to actions.

   • [claimed-docs] “Billing docs, "Monitoring usage and costs": "MotherDuck provides SQL views and a billing dashboard to help you understand your compute and s…”
   • [claimed-docs] “MotherDuck provides SQL views and a billing dashboard to help you understand your compute and storage consumption.”

   proof ↗⚑ flag

Trial

1. analystEvaluate with a free tier or trial — real queries on real data without a credit card or a sales call

   weight 1 · round to MotherDuck
   Snowflake~partialcommunity5/10

   Community evidence confirms a real, usable free trial exists (a user ran actual queries burning real credits and storage over the trial period), showing the trial supports real queries on real data — but there is no first-party documentation in the pack describing signup requirements (credit card, sales contact) for that trial, and pricing docs only describe a paid 'Standard' entry tier rather than a no-card free trial. missing for 10: official docs confirming no-credit-card signup, no sales-call requirement, and trial credit/duration terms.

   • [community] “Since the beginning of my trial, I have used 9 credits and 40GB of storage... about $19.60 worth of resources. Snowflake costs could balloon…”
   • [claimed-docs] “An entry-level, introductory offering providing access to core functionality.”
   • [claimed-docs] “Standard: An entry-level, introductory offering providing access to core functionality. ... Security with automatic encryption of all data, …”

   proof ↗⚑ flag

   MotherDuck✓fullprobed9/10

   Docs explicitly confirm a 7-day free trial with no credit card, followed by a free Lite plan (no credit card, 10GB storage, free monthly compute), and billing/monitoring tools let analysts run real queries on real data without a sales call. Runtime probes further show real analytical queries executing without any account at all via local DuckDB/MCP. Missing for 10: independent third-party confirmation of the no-CC signup flow beyond vendor docs.

   • [claimed-docs] “Pricing docs: "New users who sign up for MotherDuck and create an organization automatically get access to a 7-day Free Trial without enteri…”
   • [claimed-docs] “Billing docs, "Monitoring usage and costs": "MotherDuck provides SQL views and a billing dashboard to help you understand your compute and s…”
   • [claimed-docs] “MotherDuck provides SQL views and a billing dashboard to help you understand your compute and storage consumption.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the engine under MotherDuck ran FULLY keyless on a laptop — `duckdb -c` built a 1,000,000-row table and…”

   proof ↗⚑ flag

Bi

1. analystStandard drivers (JDBC/ODBC) and documented BI-tool integrations connect my dashboards without custom glue

   weight 1 · round to MotherDuck
   Snowflake—none0/10

   The evidence pack contains no specific mention of JDBC/ODBC drivers or documented BI-tool integrations (e.g., Tableau, Power BI, Looker) for Snowflake; only a generic reference to 'applications and tools you can use to access Snowflake' (snowflake-docs-27) without detail on standard drivers or BI connectors. This is an axis that clearly applies to a data warehouse product, but no concrete evidence demonstrates the capability.

   ⚑ flag

   MotherDuck~partialclaimed4/10

   Docs claim Postgres wire-protocol compatibility ('Use any Postgres-compatible tool, no DuckDB install needed') which implies some BI tools could connect without custom glue, and DuckDB SDKs exist for several languages, but there is no explicit mention of JDBC/ODBC drivers or named, documented BI-tool integrations (e.g., Tableau, Power BI, Looker) in the evidence pack. Missing for 10: explicit JDBC/ODBC driver documentation, named/certified BI-tool integration guides, and any hands-on confirmation that dashboards connect without custom glue.

   • [claimed-docs] “Use any Postgres-compatible tool, no DuckDB install needed”
   • [claimed-docs] “DuckDB SDKs: Python, Node.js, Go, Rust, R, Java”

   proof ↗⚑ flag

Dev loop

1. data-engineerI get a fast local or free dev loop — a local engine, emulator, or sandbox — to develop transformations before touching production compute

   weight 2 · round to MotherDuck
   Snowflake—none0/10

   Snowflake's evidence pack covers cloud compute (warehouses, Snowpipe, notebooks, dbt-in-Snowflake, Snowpark) but nothing about a local engine, emulator, or free sandbox for developing transformations before touching production compute — everything described runs against live Snowflake compute/credits. Community evidence even notes trial credits get consumed quickly (~$19.60 in credits within days), reinforcing that there's no cost-free local dev loop. Missing for 10: any local engine/emulator, offline dev mode, or a genuinely free (non-credit-consuming) sandbox tier.

   • [community] “Since the beginning of my trial, I have used 9 credits and 40GB of storage... about $19.60 worth of resources. Snowflake costs could balloon…”
   • [claimed-docs] “An entry-level, introductory offering providing access to core functionality.”
   • [claimed-docs] “Standard: An entry-level, introductory offering providing access to core functionality. ... Security with automatic encryption of all data, …”
   • [claimed-docs] “Virtual warehouses consume credits as they execute queries, load data and perform other DML operations. Virtual Warehouses are user-managed,…”

   proof ↗⚑ flag

   MotherDuck✓fullprobed8/10

   MotherDuck is built on DuckDB, which runs fully local/embedded (confirmed by runtime probe showing a keyless local DuckDB engine executing real analytical queries with zero accounts or config), and docs explicitly describe a 'develop and iterate locally, then share and scale in the cloud when you need it' workflow plus a free Lite plan/trial with no credit card for early dev use. This gives data engineers a genuine free/local dev loop before touching production compute. Missing for 10: no first-party 'emulator' or sandbox mode specific to MotherDuck's cloud extensions (e.g., DuckLake, MotherDuck-specific SQL features) that fully mirrors production compute locally, and no independent case study explicitly describing a local-dev-then-promote-to-prod workflow.

   • [claimed-docs] “Develop and iterate locally, then share and scale in the cloud when you need it.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the engine under MotherDuck ran FULLY keyless on a laptop — `duckdb -c` built a 1,000,000-row table and…”
   • [claimed-docs] “Pricing docs: "New users who sign up for MotherDuck and create an organization automatically get access to a 7-day Free Trial without enteri…”
   • [claimed-docs] “Upload a local DuckDB database file to MotherDuck cloud storage.”

   proof ↗⚑ flag

Transformation

1. data-engineerDbt is a first-class citizen — a documented adapter or native dbt project support with vendor docs to match

   weight 2 · round drawn
   Snowflake✓fullcommunity8/10

   Snowflake has a dedicated first-party feature, 'dbt Projects on Snowflake,' with vendor docs describing native support for the full dbt lifecycle (develop, deploy, orchestrate, observe), managed dbt Core/Fusion runtimes, and a documented migration path from dbt Core. This goes beyond a community adapter — it's native, vendor-documented dbt support. missing for 10: independent/hands-on validation of dbt Projects on Snowflake in production, and more detail on parity/limitations vs dbt Core for advanced use cases.

   • [claimed-docs] “dbt Projects on Snowflake brings the full dbt lifecycle into Snowflake: develop, deploy, orchestrate, and observe your transformations in th…”
   • [claimed-docs] “Migrating an existing dbt Core project? See the Migrate from dbt Core to dbt Projects on Snowflake.”
   • [claimed-docs] “dbt Projects on Snowflake brings the full dbt lifecycle into Snowflake: develop, deploy, orchestrate, and observe your transformations”
   • [claimed-docs] “No infrastructure to manage: Snowflake provides managed dbt Core and dbt Fusion runtimes.”
   • [community] “The issue with dbt models in Snowflake is that if you perform a full-refresh and don't sort it, you ruin any natural clustering from an incr…”

   proof ↗⚑ flag

   MotherDuck✓fullclaimed8/10

   MotherDuck's docs explicitly document dbt integration via the dbt-duckdb adapter, noting the only change needed is the `path:` setting for MotherDuck, and evidence shows dbt workloads sized to specific instances (e.g. 'run dbt workloads on a Standard'), indicating dbt is a recognized first-class workflow. missing for 10: no independent/hands-on report of a real dbt run against MotherDuck, and no dedicated MotherDuck-branded dbt adapter (relies on community dbt-duckdb rather than a vendor-authored adapter).

   • [claimed-docs] “The only change needed for motherduck is the path: setting.”
   • [claimed-docs] “dbt-duckdb is the adapter which allows dbt to use DuckDB and MotherDuck.”
   • [claimed-docs] “The only change needed for motherduck is the `path:` setting.”
   • [claimed-docs] “Size each instance to its job, Pulse through Giga. Backfill on a Mega instance, run dbt workloads on a Standard, let end users query a fleet…”

   proof ↗⚑ flag

Access

1. platform-engineerAccess control reaches tables, columns, and rows — roles plus masking policies — so one warehouse can serve many teams safely

   weight 3 · round to Snowflake
   Snowflake~partialclaimed5/10

   Docs confirm Snowflake's core RBAC model (privileges assigned to roles, roles to users) and Access History views tracking table/column-level query and write activity, which supports auditing at the object level. However, the evidence pack contains no mention of dynamic data masking policies or row access policies (row-level security), which are the specific mechanisms the story calls out for column- and row-level control — missing for 10: masking policy documentation, row access policy documentation, and any independent/hands-on confirmation these work as described.

   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users”
   • [claimed-docs] “Access History in Snowflake refers to when the user query reads data and when the SQL statement performs a data write operation... The user …”
   • [claimed-docs] “The records in these views facilitate regulatory compliance auditing and provide insights on popular and frequently accessed tables and colu…”
   • [claimed-docs] “facilitate regulatory compliance auditing and provide insights on popular and frequently accessed tables and columns”
   • [claimed-docs] “The user access history can be found by querying the ACCESS_HISTORY view in the ACCOUNT_USAGE and ORGANIZATION_USAGE schemas.”

   proof ↗⚑ flag

   MotherDuck~partialclaimed4/10

   MotherDuck documents role-based Shares that grant read access to users/roles and can restrict exposure to specific tables/views via include patterns, plus preset roles for tenant isolation — covering table-level RBAC for multi-tenant use. However, there is no evidence of column-level masking policies or row-level security filters, which the story explicitly requires. Missing for 10: column masking policies, row-level security/filtering, unified role hierarchy spanning column+row+table grants.

   • [claimed-docs] “Grant read access to users or roles for multi-tenant applications and collaboration.”
   • [claimed-docs] “Limit which tables and views a Share exposes with an include pattern.”
   • [claimed-docs] “Sharing data with specific preset roles or accounts in your organization. This is popular with data application builders that need to isolat…”
   • [claimed-docs] “You can securely share data in MotherDuck.”

   proof ↗⚑ flag

Governance

1. platform-engineerI get audit logs of who ran what and column-level lineage of where data came from

   weight 2 · round to Snowflake
   Snowflake~partialclaimed6/10

   Snowflake provides strong audit-log coverage via Query History (who ran what queries) and Access History (ACCESS_HISTORY view tracking reads/writes for compliance auditing, including per-column access insights), which addresses the 'who ran what' half of the story well. However, the evidence pack does not document an explicit column-level lineage graph/feature (e.g., Snowflake's Horizon/lineage explorer) showing upstream data provenance — only that Access History surfaces 'popular and frequently accessed tables and columns,' which is usage insight, not full lineage tracing. Missing for 10: explicit column-level lineage/graph documentation, independent validation of lineage accuracy across transformations.

   • [claimed-docs] “With the Query History page in Snowsight, you can do the following: Monitor individual or grouped queries that are executed by users in your…”
   • [claimed-docs] “The Query History page lets you explore queries executed in your Snowflake account over the last 14 days.”
   • [claimed-docs] “Access History in Snowflake refers to when the user query reads data and when the SQL statement performs a data write operation... The user …”
   • [claimed-docs] “The records in these views facilitate regulatory compliance auditing and provide insights on popular and frequently accessed tables and colu…”
   • [claimed-docs] “The user access history can be found by querying the ACCESS_HISTORY view in the ACCOUNT_USAGE and ORGANIZATION_USAGE schemas.”
   • [claimed-docs] “facilitate regulatory compliance auditing and provide insights on popular and frequently accessed tables and columns”

   proof ↗⚑ flag

   MotherDuck—none0/10

   Evidence shows billing/usage dashboards (docs-44) and secret scoping/sharing permissions (docs-43, docs-47) but nothing describing query-level audit logs tied to user identity or column-level data lineage tracking. missing for 10: audit log documentation (who ran what query, when), column-level lineage tracking or metadata catalog, any independent verification of these governance features.

   • [claimed-docs] “MotherDuck provides SQL views and a billing dashboard to help you understand your compute and storage consumption.”
   • [claimed-docs] “Secrets are scoped to your user account and are not shared with other users in your organization.”
   • [claimed-docs] “Sharing data with specific preset roles or accounts in your organization. This is popular with data application builders that need to isolat…”

   proof ↗⚑ flag

2. platform-engineerCompliance attestations (SOC 2, HIPAA, PCI) are documented so security review does not stall the rollout

   weight 1 · round to Snowflake
   Snowflake✓fullclaimed8/10

   Snowflake's dedicated Regulatory Compliance documentation explicitly lists per-certification pages for SOC 1 Type II, SOC 2 Type II, PCI DSS, and FedRAMP (a HIPAA-relevant standard), directly addressing the security-review documentation need. This is supported by first-party docs with named certifications, giving platform-engineers concrete attestation references. Missing for 10: an explicit named HIPAA compliance page/BAA reference and independent third-party corroboration of audit currency.

   • [claimed-docs] “Docs, "Regulatory compliance": "Snowflake is committed to meeting industry-standard regulatory compliance requirements", with per-certificat…”

   proof ↗⚑ flag

   MotherDuck—none0/10

   No evidence pack entry references SOC 2, HIPAA, PCI, or any formal compliance/attestation program, trust center, or security review documentation; the pack covers connectivity, MCP, sharing, and billing but not compliance certifications. missing for 10: SOC 2 report/attestation, HIPAA compliance statement, PCI attestation, trust center or security whitepaper, audit/certification documentation.

   ⚑ flag

Connectors

1. data-engineerFirst-party and partner connectors cover my sources — SaaS apps, databases, and ETL/ELT tools — with documented setup

   weight 2 · round to MotherDuck
   Snowflake~partialclaimed4/10

   The pack shows Snowflake integrates with ETL/ELT tooling (dbt Projects on Snowflake, managed dbt runtimes) and general data-loading mechanisms (Snowpipe, COPY INTO, Iceberg tables for external lakes) with documented setup, but it never documents a first-party/partner connector catalog for specific SaaS apps (e.g., Salesforce, HubSpot) or databases (e.g., Postgres, MySQL) — no Partner Connect, native connectors gallery, or marketplace connector docs are cited. Missing for 10: documented SaaS-app connector catalog, database-source connector docs, partner ETL/ELT integration listings beyond dbt.

   • [claimed-docs] “dbt Projects on Snowflake brings the full dbt lifecycle into Snowflake: develop, deploy, orchestrate, and observe your transformations in th…”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “Apache Iceberg™ tables for Snowflake combine the performance and query semantics of typical Snowflake tables with external cloud storage tha…”
   • [claimed-docs] “No infrastructure to manage: Snowflake provides managed dbt Core and dbt Fusion runtimes.”

   proof ↗⚑ flag

   MotherDuck~partialclaimed5/10

   MotherDuck documents loading from other databases (Postgres/MySQL) and object storage (S3), plus dbt as an ETL/transformation integration point, all with setup docs — covering the 'databases' and 'ETL/ELT tools' parts of the story. However there is no evidence of a broad partner/connector catalog for SaaS apps (e.g., Salesforce, Stripe, HubSpot) or a marketplace of pre-built connectors comparable to dedicated ETL platforms. Missing for 10: documented SaaS-app connectors, a partner connector directory/marketplace, and coverage beyond Postgres/MySQL/S3/dbt.

   • [claimed-docs] “Load your data from other databases and object storage”
   • [claimed-docs] “Learn to load a table from your PostgreSQL or MySQL database into MotherDuck.”
   • [claimed-docs] “You can safely store your Amazon S3 credentials in MotherDuck for convenience by creating a SECRET object”
   • [claimed-docs] “dbt-duckdb is the adapter which allows dbt to use DuckDB and MotherDuck.”
   • [claimed-docs] “The only change needed for motherduck is the path: setting.”
   • [claimed-docs] “Load a DuckDB database into MotherDuck: Upload a local DuckDB database file to MotherDuck cloud storage.”

   proof ↗⚑ flag

Loading

1. data-engineerBulk-load CSV, JSON, and Parquet from cloud object storage with a single documented command

   weight 3 · round drawn
   Snowflake~partialcommunity5/10

   Evidence confirms Snowflake's COPY INTO/Snowpipe ingestion path from cloud stages (referenced via stream and Snowpipe docs, plus a community mention of COPY skipping already-loaded files and JSON Lines usage) and separate support for semi-structured JSON data types, but the pack never explicitly documents a single COPY INTO command example covering CSV, JSON, and Parquet together. missing for 10: explicit doc snippet naming CSV/Parquet file format support in COPY INTO, and a concrete single-command example spanning all three formats.

   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables, including inserts (including COPY INTO), updates, and delet…”
   • [claimed-docs] “SQL reference, "Semi-structured data types" (VARIANT/OBJECT/ARRAY) with guides "Introduction to loading semi-structured data", "Querying Sem…”
   • [community] “Regarding combining to a single file for loading: not necessary... Just make them JSON Lines. The COPY command will even skip files it has a…”

   proof ↗⚑ flag

   MotherDuck~partialclaimed5/10

   MotherDuck's docs reference loading data from object storage and databases, and support S3 credential/secret management for cloud storage access, implying use of DuckDB's native read_csv/read_parquet/read_json functions against S3 paths. However, the evidence pack never shows an explicit single documented command example bulk-loading CSV, JSON, and Parquet uniformly from cloud storage. Missing for 10: explicit command syntax/example for each format (CSV, JSON, Parquet) from S3/GCS, and any independent hands-on confirmation of a single-command bulk load.

   • [claimed-docs] “Load your data from other databases and object storage”
   • [claimed-docs] “Secrets are scoped to your user account and are not shared with other users in your organization.”
   • [claimed-docs] “You can safely store your Amazon S3 credentials in MotherDuck for convenience by creating a SECRET object”
   • [claimed-docs] “Load a DuckDB database into MotherDuck: Upload a local DuckDB database file to MotherDuck cloud storage.”
   • [claimed-docs] “Learn to load a table from your PostgreSQL or MySQL database into MotherDuck.”

   proof ↗⚑ flag

2. data-engineerA managed service continuously ingests new files or events as they arrive, without me running my own pipeline infrastructure

   weight 2 · round to Snowflake
   Snowflake✓fullcommunity8/10

   Snowpipe is a first-party managed service that automatically loads files from a stage as soon as they arrive, in micro-batches within minutes, without manual COPY scheduling or customer-run pipeline infrastructure (snowflake-docs-6/20/29/34/44/76). Community evidence corroborates continuous file-based loading behavior (COPY skipping already-loaded files) consistent with this pattern (snowflake-comm-4). Missing for 10: explicit documentation of event-driven/streaming ingestion (e.g., Snowpipe Streaming API or Kafka connector) and independent hands-on validation of the 'no pipeline infra' claim beyond vendor docs.

   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they’re available in a stage”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage.”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they’re available in a stage.”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they’re available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches”
   • [community] “Regarding combining to a single file for loading: not necessary... Just make them JSON Lines. The COPY command will even skip files it has a…”

   proof ↗⚑ flag

   MotherDuck~partialclaimed4/10

   MotherDuck documents scheduled Python jobs for ingest/transformation and connectors for loading data from other databases and object storage (S3, Postgres, MySQL) without managing your own infra, which reduces pipeline-ops burden. However, this is scheduled/batch-oriented rather than a managed continuous/event-driven ingestion service that automatically picks up new files or streaming events as they arrive — there's no CDC, file-watcher, or event-trigger ingestion documented. Missing for 10: evidence of true event-driven/streaming ingestion (e.g., auto-detecting new files in a bucket, Kafka/CDC connectors, or push-based triggers) rather than cron-style scheduled jobs.

   • [claimed-docs] “Run Python jobs on a schedule for ingest, transformation, and operational tasks”
   • [claimed-docs] “Load your data from other databases and object storage”
   • [claimed-docs] “Learn to load a table from your PostgreSQL or MySQL database into MotherDuck.”
   • [claimed-docs] “You can safely store your Amazon S3 credentials in MotherDuck for convenience by creating a SECRET object”
   • [claimed-docs] “Spin up a fully managed lakehouse with MotherDuck handling both metadata and storage, or bring your own cloud object storage.”
   • [claimed-docs] “Use DuckLake to build a data lake on top of your own files”

   proof ↗⚑ flag

Notebooks

1. analystFirst-party notebooks let me mix SQL and Python against warehouse data, with results and charts inline

   weight 2 · round to Snowflake
   Snowflake✓fullcommunity8/10

   Snowflake Notebooks is a first-party, cell-based Snowsight interface supporting Python, SQL, and Markdown in the same notebook with cell-by-cell execution and result comparison, directly matching the story. Missing for 10: explicit documentation/screenshots of inline chart rendering within notebooks and independent/hands-on user corroboration beyond vendor docs.

   • [claimed-docs] “Write SQL or Python code and quickly compare results with cell-by-cell development and execution.”
   • [claimed-docs] “Snowflake Notebooks is a unified development interface in Snowsight that offers an interactive, cell-based programming environment for Pytho…”
   • [claimed-docs] “you can leverage your Snowflake data to perform exploratory data analysis, develop machine learning models, and perform other data science a…”
   • [community] “Snowflake's preview app called Snowsight provides a way to both query and visualize the data.”

   proof ↗⚑ flag

   MotherDuck~partialcommunity4/10

   MotherDuck's UI supports SQL notebooks with inline results and AI-generated charts (Instant SQL, Dives with GROUP BY visualizations, conversational chart edits), and Python is supported as a first-class SDK/scheduled-job language, but there is no evidence of a single first-party notebook interface that mixes SQL and Python cells together with inline charts as the story describes. missing for 10: evidence of Python cells inline within the same notebook/workspace as SQL cells, evidence of mixed-language notebook execution rather than separate SQL editor vs Python SDK/job usage.

   • [claimed-docs] “Run Python jobs on a schedule for ingest, transformation, and operational tasks”
   • [claimed-docs] “Generate interactive, shareable dashboards from natural language prompts”
   • [claimed-docs] “Build a Dive with a chart of our top 10 products by sales volume. Use MotherDuck's brand colors”
   • [claimed-docs] “you iterate conversationally ("add a filter for US region", "switch to a bar chart") and the Viewer updates in place.”
   • [community] “Praise for MotherDuck's CTE inspection feature in Instant SQL: "CTE inspection is amazing. I spend too much time doing that manually."”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Snowflake~partialprobed6/10

   Snowflake exposes broad programmatic surfaces — the SQL API and REST APIs for resource management (queries, provisioning users/roles, tables), Snowpark APIs, Snowflake CLI for managing apps/workloads, and OpenAPI-compliant specs published on GitHub — indicating strong API/UI parity ambitions for developers and AI agents (docs-65, docs-66, docs-72, docs-73, snowflake-supp-openapi-specs, docs-1). However there is no explicit vendor claim or independent verification of full 1:1 parity between every Snowsight UI feature (e.g., notebooks cell UI, query profile visualizations, Cortex Analyst chat UI) and API equivalents, and a live probe found no discoverable openapi.json at conventional doc paths. Missing for 10: an explicit parity statement or audit confirming every UI action has an API/CLI equivalent, and independent/hands-on confirmation that AI-native workflows can fully replace UI usage.

   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [claimed-docs] “Snowflake REST APIs enable developers and partners to use the language of their choice to build integrations with Snowflake using the openAP…”
   • [claimed-docs] “You can use this API to develop custom applications and integrations that: Perform queries, Manage your deployment (e.g. provision users and…”
   • [claimed-docs] “Official snowflakedb/snowflake-rest-api-specs repo (specifications/ + collections/): "These REST APIs are compliant with the OpenAPI specifi…”
   • [claimed-docs] “With Snowflake CLI, developers can create, manage, update, and view apps running on Snowflake across workloads such as Streamlit in Snowflak…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.snowflake.com/openapi.json, https://docs.snowflake.com/swagger.json, https://docs.snowf…”

   proof ↗⚑ flag

   MotherDuck~partialprobed6/10

   MotherDuck exposes a broad API surface (SDKs in Python/Node/Go/Rust/R/Java, a documented OpenAPI spec, SQL access, and both local/remote MCP servers that can execute read/write SQL and even generate visualizations conversationally), giving AI-native users substantial parity with UI capabilities like Dives and querying. However, several UI-only surfaces (billing dashboard, org/user management console, Instant SQL editor features) have no documented API/MCP equivalent, and no evidence explicitly confirms full feature parity across the board. Missing for 10: explicit documentation or confirmation that admin/billing/org-management UI actions are also API-accessible, and independent verification of full parity beyond query/visualization workflows.

   • [claimed-docs] “Connect to MotherDuck using official drivers and APIs for various programming languages.”
   • [claimed-docs] “DuckDB SDKs: Python, Node.js, Go, Rust, R, Java”
   • [claimed-docs] “The MotherDuck remote MCP Server lets you analyze your data using natural language and generate interactive visualizations, all without writ…”
   • [claimed-docs] “With the remote MCP server, your agent can: - Execute read-only and read-write SQL against your databases”
   • [probe] “PROBE openapi: HTTP 200 at https://motherduck.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official mcp-server-motherduck (pypi, via uvx) completed a FULL keyless stdio initialize handshake …”
   • [probe] “PROBE runtime (recorded 2026-09-06): a keyless JSON-RPC initialize POST to the hosted remote MCP server https://api.motherduck.com/mcp retur…”
   • [claimed-docs] “MotherDuck provides SQL views and a billing dashboard to help you understand your compute and storage consumption.”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Snowflake~partialcommunity5/10

   Snowflake supports Apache Iceberg tables backed by open, customer-managed cloud storage, which is a genuine open-format, portable-data path, and it exposes SQL/REST APIs for programmatic data extraction. However, there is no direct documentation in the evidence pack of a comprehensive 'export all your data and leave' workflow (e.g., bulk UNLOAD/COPY INTO to open formats for all tables, migration tooling, or explicit anti-lock-in guidance), and community commentary even frames Snowflake's stickiness/lock-in as a concern rather than confirming easy full data egress. Missing for 10: documented bulk export/unload feature for all data, first-party migration/exit tooling, and independent confirmation that a full data exit is straightforward.

   • [claimed-docs] “Apache Iceberg™ tables for Snowflake combine the performance and query semantics of typical Snowflake tables with external cloud storage tha…”
   • [claimed-docs] “They are ideal for existing data lakes that you cannot, or choose not to, store in Snowflake.”
   • [claimed-docs] “Snowflake REST APIs for resource management provide a set of endpoints that lets users programmatically interact with and control various re…”
   • [claimed-docs] “The Snowflake SQL API is a REST API that you can use to access and update data in a Snowflake database.”
   • [community] “I predict we'll see more people choosing Clickhouse over Snowflake in the next 5 years... and give people a better escape hatch if they want…”

   proof ↗⚑ flag

   MotherDuck~partialprobed5/10

   MotherDuck is built on DuckDB and documents local-first workflows (upload/download DuckDB files, local CLI/SDKs in Python/Node/Go/Rust/R/Java), implying data can move between local open DuckDB files and the cloud service, but there is no explicit documentation of a bulk 'export all your data to open formats (Parquet/CSV) and migrate away' workflow or data-portability guarantee. missing for 10: an explicit export-all-data/backup feature or migration guide, independent confirmation that a full account's data can be extracted losslessly, and any statement addressing vendor lock-in/exit.

   • [claimed-docs] “Upload a local DuckDB database file to MotherDuck cloud storage.”
   • [claimed-docs] “Develop and iterate locally, then share and scale in the cloud when you need it.”
   • [claimed-docs] “DuckDB SDKs: Python, Node.js, Go, Rust, R, Java”
   • [claimed-docs] “Load your data from other databases and object storage”
   • [probe] “PROBE runtime (recorded 2026-09-06): the engine under MotherDuck ran FULLY keyless on a laptop — `duckdb -c` built a 1,000,000-row table and…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Snowflake—none0/10

   The evidence pack includes compliance certifications (SOC 2, ISO, FedRAMP, PCI DSS) but contains no mention of region selection, data residency controls, or ability to choose a storage location/cloud region for an account or database. No documentation cited addresses this specific capability.

   ⚑ flag

   MotherDuck—none0/10

   No evidence pack material addresses data region/residency selection, geographic data center choice, or compliance certifications tied to storage location; the pack covers connectivity, sharing, MCP, and billing but nothing about where data physically resides. missing for 10: region selection options, data residency documentation, compliance/geo controls, any mention of storage location choice.

   ⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Snowflake—none0/10

   The axis applies since Snowflake offers AI/Cortex features built on third-party LLMs, making data-use-for-training a fair privacy concern, but no evidence pack item documents an opt-out control, data-processing agreement, or explicit statement that customer data is excluded from model training. Compliance certifications and RBAC/access-history items are about general security/governance, not AI-training data use.

   ⚑ flag

   MotherDuck—none0/10

   The evidence pack contains no statement about whether MotherDuck uses customer data to train AI models, nor any opt-out/data-training policy control; this is a fair question given MotherDuck's AI features (Dives, natural language MCP querying) but no documentation addresses it.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Snowflake
   Snowflake~partialclaimed5/10

   Snowflake's Time Travel docs show a defined retention window for querying/restoring changed or deleted data, and RBAC plus compliance certifications provide governance context, giving an AI-native user some levers over data lifecycle and access. Missing for 10: explicit documentation of configuring the retention period (e.g., DATA_RETENTION_TIME_IN_DAYS parameter), explicit purge/permanent-delete commands, and any GDPR/right-to-erasure specific deletion guarantees.

   • [claimed-docs] “Using Time Travel, you can perform the following actions within a defined period of time: Query data in the past that has since been updated…”
   • [claimed-docs] “Restoring objects that might have been accidentally or intentionally deleted.”
   • [claimed-docs] “Restoring objects that might have been accidentally or intentionally deleted. You can restore individual objects, such as tables, or restore…”
   • [claimed-docs] “Snowflake Time Travel enables accessing historical data (that is, data that has been changed or deleted) at any point within a defined perio…”
   • [claimed-docs] “Role-based Access Control (RBAC): Access privileges are assigned to roles, which are in turn assigned to users.”
   • [claimed-docs] “Docs, "Regulatory compliance": "Snowflake is committed to meeting industry-standard regulatory compliance requirements", with per-certificat…”

   proof ↗⚑ flag

   MotherDuck—none0/10

   The evidence pack covers authentication, sharing, secrets scoping, and MCP access controls but contains no documentation of data retention periods, deletion APIs, or purge/right-to-be-forgotten mechanisms for a MotherDuck-hosted database. As a cloud data warehouse, retention/deletion controls are a fair and expected axis, but no citation here shows explicit user-facing retention or deletion controls beyond generic DROP TABLE-type SQL implied by being a database.

   ⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Snowflake—none0/10

   No evidence pack item mentions telemetry, usage tracking, or an opt-out mechanism for Snowflake's own product telemetry; only compliance certifications and access-history/audit features are documented, which don't address user-facing telemetry opt-out. This axis is applicable to any AI-native SaaS product, so absence of evidence yields 'none'. Missing for 10: any documentation of a telemetry/usage-data collection policy or an opt-out/opt-in control for such tracking.

   ⚑ flag

   MotherDuck—none0/10

   The evidence pack covers SaaS Mode (limiting local environment interaction), secret scoping, and billing/usage dashboards, but none of it addresses telemetry or product usage tracking opt-out specifically — these are different concerns (environment access control and cost monitoring, not telemetry collection).

   ⚑ flag

Semantics

1. analystDefine a governed semantic model — metrics, dimensions, and joins declared once — that queries and AI tools answer against consistently

   weight 2 · round to Snowflake
   Snowflake✓fullclaimed7/10

   Snowflake's Semantic Views let analysts declare business metrics, entities, and relationships once as schema-level objects, and Cortex Analyst answers natural-language questions against this same semantic layer without writing SQL, while Cortex Agents/MCP expose it to AI tools — directly matching the story of a governed semantic model queried consistently by both SQL and AI. missing for 10: no independent/community corroboration of Semantic Views in practice, and no detail on how BI/SQL query tools (beyond Cortex Analyst) consistently reuse the same semantic definitions.

   • [claimed-docs] “You can store semantic business concepts directly in the database in a Semantic View, which is a schema-level object. You can define busines…”
   • [claimed-docs] “You can define business metrics and model business entities and their relationships.”
   • [claimed-docs] “You can store semantic business concepts directly in the database in a Semantic View ... define business metrics and model business entities…”
   • [claimed-docs] “You can store semantic business concepts directly in the database in a Semantic View, which is a schema-level object.”
   • [claimed-docs] “With Cortex Analyst, business users can ask questions in natural language and receive direct answers without writing SQL.”
   • [claimed-docs] “business users can ask questions in natural language and receive direct answers without writing SQL”
   • [claimed-docs] “The Snowflake-managed MCP server lets AI agents securely retrieve data from Snowflake accounts without needing to deploy separate infrastruc…”
   • [claimed-docs] “You can configure the MCP server to serve Cortex Analyst, Cortex Search, and Cortex Agents as tools, along with custom tools and SQL executi…”

   proof ↗⚑ flag

   MotherDuck~partialclaimed4/10

   MotherDuck documents "Guides" — markdown documents capturing metric definitions, join conventions, and domain context so AI agents produce consistent SQL without repetitive prompting — which is a lightweight step toward a governed semantic layer for AI consumers via MCP. However, this is informal markdown context rather than a structured semantic model with declared metrics/dimensions objects enforced across all query paths (SQL, BI tools, dashboards), and there's no evidence of validation, versioning, or joins-as-schema enforcement outside the AI/MCP context. Missing for 10: a structured metric/dimension definition schema (not just markdown guides), enforcement of consistency across non-AI query paths (BI/dashboard tools), and independent verification that guides actually produce consistent results across different AI tools.

   • [claimed-docs] “Read and write Guides — markdown documents that capture your org's metric definitions, join conventions, and domain context, so agents produ…”

   proof ↗⚑ flag

Sharing

1. analystA marketplace of third-party datasets lets me enrich my own data directly inside the platform

   weight 1 · round drawn
   Snowflake—none0/10

   The evidence pack only documents Secure Data Sharing (share selected objects between Snowflake accounts) but contains no mention of a marketplace, data exchange, or third-party dataset listings that an analyst could browse and directly enrich their own data with — the specific marketplace capability described in the story is absent from the pack.

   • [claimed-docs] “Secure Data Sharing lets you share selected objects in a database in your account with other Snowflake accounts.”
   • [claimed-docs] “Secure Data Sharing lets you share selected objects in a database in your account with other Snowflake accounts. ... no actual data is copie…”

   proof ↗⚑ flag

   MotherDuck—none0/10

   MotherDuck's docs describe secure data *sharing* (grants, roles, presets, share links like md:_share/hacker_news/...) for collaboration within or across an organization, but there is no evidence of a curated marketplace of third-party datasets from external providers that an analyst could browse and attach for enrichment.

   • [claimed-docs] “Grant read access to users or roles for multi-tenant applications and collaboration.”
   • [claimed-docs] “Limit which tables and views a Share exposes with an include pattern.”
   • [claimed-docs] “You can securely share data in MotherDuck.”
   • [claimed-docs] “Sharing data with specific preset roles or accounts in your organization. This is popular with data application builders that need to isolat…”
   • [claimed-docs] “Attach this db 'md:_share/hacker_news/de11a0e3-9d68-48d2-ac44-40e07a1d496b' give me some analytics.”

   proof ↗⚑ flag

2. data-engineerShare live datasets with another account or organization without copying data or building an export pipeline

   weight 2 · round to Snowflake
   Snowflake✓fullclaimed9/10

   Snowflake's Secure Data Sharing directly delivers this story: it lets accounts share selected database objects with other Snowflake accounts, with docs explicitly stating no actual data is copied or transferred between accounts, eliminating the need for export pipelines. This is a first-party, well-documented core Snowflake feature (also referenced as part of Standard plan capabilities). Missing for 10: independent/hands-on third-party confirmation of cross-organization sharing experience beyond vendor docs.

   • [claimed-docs] “Secure Data Sharing lets you share selected objects in a database in your account with other Snowflake accounts.”
   • [claimed-docs] “Secure Data Sharing lets you share selected objects in a database in your account with other Snowflake accounts. ... no actual data is copie…”
   • [claimed-docs] “Standard: An entry-level, introductory offering providing access to core functionality. ... Security with automatic encryption of all data, …”

   proof ↗⚑ flag

   MotherDuck✓fullclaimed8/10

   MotherDuck's Sharing Data docs describe granting read access to specific users, roles, or accounts (including cross-org) via Shares without copying data, with the shared database attachable directly (e.g. `md:_share/...`), and include ways to restrict exposed tables/views — exactly a live-share model without export pipelines. This is corroborated by concrete attach syntax in the MCP getting-started doc showing a live shared dataset being queried directly. missing for 10: independent/hands-on confirmation of cross-organization (not just cross-user) sharing in production and any limits/latency of live share updates.

   • [claimed-docs] “You can securely share data in MotherDuck.”
   • [claimed-docs] “Grant read access to users or roles for multi-tenant applications and collaboration.”
   • [claimed-docs] “Limit which tables and views a Share exposes with an include pattern.”
   • [claimed-docs] “Sharing data with specific preset roles or accounts in your organization. This is popular with data application builders that need to isolat…”
   • [claimed-docs] “Attach this db 'md:_share/hacker_news/de11a0e3-9d68-48d2-ac44-40e07a1d496b' give me some analytics.”

   proof ↗⚑ flag

Lakehouse

1. data-engineerQuery open table formats and files in object storage — Iceberg, Delta, Parquet — without first loading them into proprietary storage

   weight 2 · round to Snowflake
   Snowflake✓fullclaimed8/10

   Snowflake supports Apache Iceberg tables directly on customer-managed external cloud storage, explicitly positioned for 'existing data lakes that you cannot, or choose not to, store in Snowflake,' and Snowpipe/COPY plus external stages allow querying files in object storage without loading them into proprietary storage. Missing for 10: explicit docs on Delta Lake table querying and independent hands-on benchmarks confirming performance parity for external Iceberg/Delta queries.

   • [claimed-docs] “Apache Iceberg™ tables for Snowflake combine the performance and query semantics of typical Snowflake tables with external cloud storage tha…”
   • [claimed-docs] “They are ideal for existing data lakes that you cannot, or choose not to, store in Snowflake.”

   proof ↗⚑ flag

   MotherDuck~partialclaimed5/10

   MotherDuck's docs show S3 object-storage integration (secrets for S3 credentials) and DuckLake for building a lakehouse on top of 'your own files' or bring-your-own object storage, implying in-place querying of external storage rather than mandatory ingestion. However, the pack never explicitly names Iceberg or Delta table format support, or demonstrates querying Parquet/Iceberg/Delta files directly without first loading them into MotherDuck-managed storage — most 'loading data' docs (docs-6, docs-29, docs-42) describe explicit load/upload workflows instead. Missing for 10: explicit documentation or example of querying Iceberg/Delta tables in place, a worked example reading Parquet directly from S3 without a load step, and independent/hands-on confirmation of zero-copy querying against object storage.

   • [claimed-docs] “Spin up a fully managed lakehouse with MotherDuck handling both metadata and storage, or bring your own cloud object storage.”
   • [claimed-docs] “You can safely store your Amazon S3 credentials in MotherDuck for convenience by creating a SECRET object”
   • [claimed-docs] “Use DuckLake to build a data lake on top of your own files”
   • [claimed-docs] “Load your data from other databases and object storage”
   • [claimed-docs] “Secrets are scoped to your user account and are not shared with other users in your organization.”

   proof ↗⚑ flag

Performance

1. data-engineerInspect query profiles and execution plans to find why a query is slow or expensive

   weight 2 · round to Snowflake
   Snowflake✓fullcommunity8/10

   Snowsight's Query History page lets data engineers monitor executed queries and drill into a detailed query profile that explores each step of execution, directly supporting root-cause analysis of slow/expensive queries; this is corroborated by community mention of Snowsight's query/visualize UI. missing for 10: no independent hands-on account of using query profile specifically to diagnose a slow query, and no detail on cost-per-query attribution tooling (one community comment even notes lack of query-level cost attribution).

   • [claimed-docs] “With the Query History page in Snowsight, you can do the following: Monitor individual or grouped queries that are executed by users in your…”
   • [claimed-docs] “The Query History page lets you explore queries executed in your Snowflake account over the last 14 days.”
   • [claimed-docs] “Explore each step of an executed query in the query profile.”
   • [claimed-docs] “Monitor individual or grouped queries that are executed by users in your account.”
   • [community] “Snowflake's preview app called Snowsight provides a way to both query and visualize the data.”
   • [community] “The problem with Snowflake is particularly worse due to its lack of query level attribution of costs and no in-built features for monitoring…”

   proof ↗⚑ flag

   MotherDuck—none0/10

   The evidence pack mentions a query-performance doc and billing/usage dashboards (docs-44, docs-46) but none of it describes actual query profiling tools, EXPLAIN/ANALYZE output, or execution-plan visualization for diagnosing slow or expensive queries. Missing for 10: any documentation of an EXPLAIN/PROFILE command, a query plan visualizer, or per-query cost/latency breakdown tool for MotherDuck specifically.

   • [claimed-docs] “MotherDuck provides SQL views and a billing dashboard to help you understand your compute and storage consumption.”
   • [claimed-docs] “read scaling adds read-only Ducklings so concurrent users don't queue behind each other.”

   proof ↗⚑ flag

Recovery

1. data-engineerTime-travel — query data as of a past point and restore dropped or corrupted tables from history

   weight 2 · round to Snowflake
   Snowflake✓fullclaimed9/10

   Snowflake's documented Time Travel feature explicitly supports querying data as of a past point and restoring accidentally/intentionally deleted objects (tables, schemas, databases) within a retention window, directly matching the story; Clone/UNDROP mechanics and object cloning (inheriting privileges) further support restoration workflows. Missing for 10: no independent/hands-on corroboration of restore success or retention-period limits from community evidence.

   • [claimed-docs] “Using Time Travel, you can perform the following actions within a defined period of time: Query data in the past that has since been updated…”
   • [claimed-docs] “Restoring objects that might have been accidentally or intentionally deleted.”
   • [claimed-docs] “Query data in the past that has since been updated or deleted.”
   • [claimed-docs] “Restoring objects that might have been accidentally or intentionally deleted. You can restore individual objects, such as tables, or restore…”
   • [claimed-docs] “Snowflake Time Travel enables accessing historical data (that is, data that has been changed or deleted) at any point within a defined perio…”
   • [claimed-docs] “the clone inherits all granted privileges on the clones of all child objects contained in the source object”
   • [claimed-docs] “If the source object is a database or schema, the clone inherits all granted privileges on the clones of all child objects contained in the …”

   proof ↗⚑ flag

   MotherDuck—none0/10

   The evidence pack covers connectivity, sharing, MCP, dbt integration, pricing, and dashboards, but contains no mention of time-travel querying, point-in-time recovery, or restoring dropped/corrupted tables from history — a capability common in some cloud warehouses but not documented here for MotherDuck.

   ⚑ flag

Sql

1. analystI get a full analytical SQL surface — window functions, CTEs, semi-structured JSON, arrays, and rich date/time types — without bolt-on extensions

   weight 3 · round to Snowflake
   Snowflake~partialcommunity7/10

   Docs confirm window functions, semi-structured VARIANT/OBJECT/ARRAY types, and Time Travel/date handling are native SQL features, and community evidence corroborates JSON handling via COPY/JSON Lines. However, one community report notes a gap versus generate_series-style sequence generation, and CTE support and rich date/time type breadth aren't directly evidenced in the pack. missing for 10: explicit CTE documentation, comprehensive date/time type reference, independent corroboration beyond the noted generate_series gap.

   • [claimed-docs] “SQL reference, "Window functions": "Window functions are analytic functions that you can use for various calculations such as running totals…”
   • [claimed-docs] “SQL reference, "Semi-structured data types" (VARIANT/OBJECT/ARRAY) with guides "Introduction to loading semi-structured data", "Querying Sem…”
   • [community] “Snowflake doesn't have a generate_series function equivalent. The closest thing it has is a generator function which only accepts constants.”
   • [community] “Regarding combining to a single file for loading: not necessary... Just make them JSON Lines. The COPY command will even skip files it has a…”
   • [claimed-docs] “Using Time Travel, you can perform the following actions within a defined period of time: Query data in the past that has since been updated…”

   proof ↗⚑ flag

   MotherDuck~partialprobed5/10

   MotherDuck runs on DuckDB and evidence confirms native CTE support (praised CTE inspection feature) and a real keyless aggregate GROUP BY analytical query executed without extensions, suggesting a native, non-bolt-on SQL engine. However, the pack contains no explicit documentation or examples of window functions, semi-structured JSON handling, array types, or rich date/time types. Missing for 10: explicit docs/examples of window functions, JSON/semi-structured querying, array types, and date/time type support.

   • [community] “Praise for MotherDuck's CTE inspection feature in Instant SQL: "CTE inspection is amazing. I spend too much time doing that manually."”
   • [probe] “PROBE runtime (recorded 2026-09-06): the engine under MotherDuck ran FULLY keyless on a laptop — `duckdb -c` built a 1,000,000-row table and…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://motherduck.com/llms.txt # MotherDuck MotherDuck is a modern serverless data warehouse built on DuckDB. …”
   • [claimed-docs] “Use DuckLake to build a data lake on top of your own files”

   proof ↗⚑ flag

Streaming

1. data-engineerRun continuous or incremental transformations — streams, tasks, declarative pipelines, or continuous queries — inside the platform

   weight 1 · round to Snowflake
   Snowflake✓fullclaimed8/10

   Snowflake documents Streams for CDC-based incremental change capture (doc-7/21/38/54), Dynamic Tables (GA, doc-15) for declarative continuous transformation pipelines, and Snowpipe for continuous/micro-batch ingestion (doc-6/20/29/34/44/76) — directly matching the story's streams/declarative-pipeline/continuous-processing capabilities inside the platform. Missing for 10: explicit documentation of the Tasks object (scheduling/orchestration companion to Streams), Snowpipe Streaming (true low-latency continuous ingestion) specifics, and independent/hands-on validation of these pipelines at production scale.

   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables, including inserts (including COPY INTO), updates, and delet…”
   • [claimed-docs] “CREATE OR ALTER DYNAMIC TABLE (General availability)”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables, including inserts (including COPY INTO), updates, and delet…”
   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables, including inserts, updates, and deletes”
   • [claimed-docs] “A stream object records data manipulation language (DML) changes made to tables... so that actions can be taken using the changed data”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches”

   proof ↗⚑ flag

   MotherDuck~partialclaimed3/10

   MotherDuck's docs mention running scheduled Python jobs for ingest/transformation (docs-3) and dbt integration supporting incremental models (docs-7/19/32), which gives some incremental transformation capability, but there is no evidence of native streaming primitives, continuous queries, declarative pipeline objects, or task/stream constructs (à la Snowflake Streams & Tasks or Materialize) — MotherDuck is positioned as a serverless analytical warehouse, not a streaming engine. Missing for 10: native stream/CDC ingestion, continuous query execution, declarative pipeline DSL, task scheduling beyond generic Python cron jobs, and any independent evidence of these being used for continuous transformations.

   • [claimed-docs] “Run Python jobs on a schedule for ingest, transformation, and operational tasks”
   • [claimed-docs] “The only change needed for motherduck is the path: setting.”
   • [claimed-docs] “dbt-duckdb is the adapter which allows dbt to use DuckDB and MotherDuck.”
   • [claimed-docs] “The only change needed for motherduck is the `path:` setting.”

   proof ↗⚑ flag

2. data-engineerStreaming writes land queryable within seconds through a documented streaming ingestion API

   weight 2 · round to Snowflake
   Snowflake~partialclaimed4/10

   Snowflake documents Snowpipe as a streaming/micro-batch ingestion API, but the documentation explicitly states data becomes available 'within minutes,' not seconds, directly at odds with the story's 'queryable within seconds' requirement. There is no evidence pack mention of the lower-latency Snowpipe Streaming API or REST-based streaming ingestion that could close this gap. Missing for 10: documented sub-second/seconds-level ingestion latency, evidence of a dedicated low-latency streaming ingestion API (e.g., Snowpipe Streaming), and independent/hands-on confirmation of near-real-time query availability.

   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they’re available in a stage”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage.”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they’re available in a stage.”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they’re available in a stage. This means you can load data from files in micro-batches, …”
   • [claimed-docs] “Snowpipe enables loading data from files as soon as they're available in a stage. This means you can load data from files in micro-batches”

   proof ↗⚑ flag

   MotherDuck—none0/10

   Evidence shows batch-style ingestion (file uploads, scheduled Python jobs, database/object-storage loads) but no documented streaming ingestion API with seconds-level queryability guarantees. No mention of Kafka/CDC connectors, streaming inserts, or latency SLAs for streamed data.

   ⚑ flag