Turso vs ClickHouse

Agent ops

1. ai-native userMy coding agent can provision a database end to end — create it, fetch the connection string, apply schema, and run queries — through the API, CLI, or MCP without touching the dashboard

   weight 3 · round to Turso
   Turso✓fullprobed8/10

   Turso documents and runtime-probes confirm a full non-dashboard provisioning path: the API can create/token-scope/tear down a database per agent (turso-docs-8), the CLI can create a db and shell into it (turso-docs-14/15/40, turso-probe-5), and the official MCP server (docs-9/37, turso-probe-4) lets any MCP-capable agent manage orgs/databases/groups and run SQL with no token copy-paste — independently verified live and returning a real OAuth challenge (turso-probe-rt-3), plus a keyless local libSQL server actually executing CREATE TABLE/INSERT/SELECT via CLI (turso-probe-rt-2). Schema/data operations are covered via SDK push()/pull() (docs-7/20/43) and CLI shell/.dump (docs-47). Missing for 10: a single documented end-to-end example chaining API-create→connection-string→schema-apply→query in one flow, and independent (non-vendor) confirmation of the full agent-driven MCP workflow beyond the auth handshake.

   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “turso db create my-db --tursodb”
   • [claimed-docs] “Now connect to it with the `shell` command:”
   • [claimed-docs] “turso db shell my-db”
   • [claimed-docs] “push() sends your changes to the cloud. pull() brings remote changes down.”
   • [claimed-docs] “Push local writes to Turso Cloud await db.push(); // Pull remote changes to local database const changed = await db.pull();”
   • [probe] “official MCP server documented at https://docs.turso.tech/integrations/mcp”
   • [probe] “official CLI documented at https://docs.turso.tech/cli/introduction”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse~partialprobed6/10

   ClickHouse's CLI (clickhousectl) documentation shows it can create/manage ClickHouse Cloud clusters, manage cloud resources, and execute queries against ClickHouse servers entirely from the command line (clickhouse-docs-17,20,31,32), and an official MCP server (mcp-clickhouse) lets AI assistants connect and query ClickHouse (clickhouse-docs-5,6, clickhouse-probe-4), plus an OpenAPI spec exists for API-based automation (clickhouse-probe-3). However, no evidence explicitly documents fetching a connection string as a discrete step, and the MCP server is framed for connecting to/querying existing databases rather than full provisioning, so the end-to-end 'create→connect→schema→query' agent workflow is only partially evidenced rather than demonstrated as a single seamless path. Missing for 10: explicit connection-string retrieval step, an end-to-end walkthrough or hands-on example of an agent provisioning a fresh cluster via CLI/MCP without dashboard, and independent corroboration of this workflow succeeding in practice.

   • [claimed-docs] “Push your local ClickHouse development to cloud”
   • [claimed-docs] “Set up ClickHouse Cloud and create cloud-managed ClickHouse clusters * Create and manage ClickHouse Cloud Postgres services * Manage ClickHo…”
   • [claimed-docs] “Run and manage local Postgres instances * Execute queries against ClickHouse servers * Set up ClickHouse Cloud and create cloud-managed Clic…”
   • [claimed-docs] “Install and manage local ClickHouse versions * Launch and manage local ClickHouse servers”
   • [claimed-docs] “Choose an MCP client or framework to connect an AI assistant to ClickHouse.”
   • [claimed-docs] “Connect ClickHouse to your AI assistants.”
   • [probe] “PROBE openapi: HTTP 200 at https://clickhouse.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://github.com/ClickHouse/mcp-clickhouse”
   • [probe] “official CLI documented at https://clickhouse.com/docs/concepts/features/interfaces/cli”

   proof ↗⚑ flag

2. ai-native userAn agent can run SQL and schema operations through scoped tools that distinguish read-only from destructive actions, so I can safely delegate database work

   weight 2 · round to ClickHouse
   Turso—none0/10

   Turso ships an official MCP server (turso-docs-9, turso-docs-37, turso-probe-rt-3) that lets any MCP-capable agent run SQL and manage databases, and token-scoped per-agent database provisioning (turso-docs-8) exists, but there is no evidence the MCP tool set distinguishes read-only query tools from destructive/schema-mutating ones (e.g. no documented tool scoping, permission tiers, or dry-run/confirmation gating for DDL/DML vs SELECT).

   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse~partialprobed4/10

   ClickHouse ships an official MCP server (mcp-clickhouse) letting AI assistants connect and run queries against ClickHouse, and docs mention agent skills/CLI integration, so agents can execute SQL through a sanctioned tool interface. However, none of the evidence describes scoped tool definitions that explicitly separate read-only queries from destructive/schema-changing operations, nor any permissioning model for safe delegation. missing for 10: documentation of read-only vs write/destructive tool scoping, permission controls or guardrails within the MCP server, independent confirmation that agents can't run destructive ops unintentionally.

   • [claimed-docs] “Choose an MCP client or framework to connect an AI assistant to ClickHouse.”
   • [claimed-docs] “Connect ClickHouse to your AI assistants.”
   • [probe] “official MCP server documented at https://github.com/ClickHouse/mcp-clickhouse”
   • [claimed-docs] “Install the official ClickHouse agent skills into supported coding agents”

   proof ↗⚑ flag

3. ai-native userCheaply create thousands of isolated databases — one per agent, tenant, or preview — and manage the fleet programmatically

   weight 2 · round to Turso
   Turso✓fullprobed7/10

   First-party docs explicitly describe provisioning a dedicated isolated SQLite database per user/agent, creating/token-scoping/tearing down via API, and spinning up 'thousands or millions' of isolated databases programmatically as core architecture, plus branch-per-PR automation and CLI/API creation flows. Missing for 10: independent/hands-on evidence of actually managing a large fleet (thousands) at scale, and concrete cost data proving 'cheap' bulk provisioning.

   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Spin up thousands or millions of isolated databases programmatically, each with its own boundary. Not a workaround. The architecture.”
   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”
   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [probe] “official CLI documented at https://docs.turso.tech/cli/introduction”

   proof ↗⚑ flag

   ClickHouse~partialprobed4/10

   ClickHouse Cloud offers a CLI/API to programmatically create and manage cloud-managed clusters and resources, plus usage-based pricing that scales compute to zero when idle, which supports cost-efficient fleet-style provisioning. However, there is no direct evidence describing a pattern for spinning up thousands of isolated per-agent/tenant databases, no documented multi-tenant isolation guidance, and no explicit 'fleet management' API for bulk database lifecycle at that scale. missing for 10: explicit multi-tenant/isolated-database-per-agent provisioning docs, bulk/fleet management API examples, and evidence of cost/performance at thousands-of-databases scale.

   • [claimed-docs] “Set up ClickHouse Cloud and create cloud-managed ClickHouse clusters”
   • [claimed-docs] “Set up ClickHouse Cloud and create cloud-managed ClickHouse clusters * Create and manage ClickHouse Cloud Postgres services * Manage ClickHo…”
   • [claimed-docs] “pay only for the compute and storage you use, scaled separately and down to zero when idle”
   • [claimed-docs] “Usage-based pricing: pay only for the compute and storage you use, scaled separately and down to zero when idle.”
   • [probe] “official CLI documented at https://clickhouse.com/docs/concepts/features/interfaces/cli”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   Turso✓fullprobed9/10

   Turso hosts a live llms.txt index (HTTP 200) that links to markdown docs pages, exactly matching the agent-oriented docs pattern, and this was independently confirmed via probe. Missing for 10: no independent/community corroboration that agents actually use this llms.txt file successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.turso.tech/llms.txt # Turso ## Docs - [Welcome to Turso](https://docs.turso.tech/introduction.md)…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.turso.tech/introduction.md > ## Documentation Index > Fetch the complete documentation index at: htt…”

   proof ↗⚑ flag

   ClickHouse✓fullprobed9/10

   A live probe confirms llms.txt is served at clickhouse.com/llms.txt returning HTTP 200 with structured content describing ClickHouse, directly satisfying the story; ClickHouse also documents agent skills and MCP integration as complementary agent-oriented resources. Missing for 10: independent/community confirmation that agents actually consume this llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://clickhouse.com/llms.txt # ClickHouse > ClickHouse is a fast open-source column-oriented database manage…”
   • [claimed-docs] “Install the official ClickHouse agent skills into supported coding agents”
   • [claimed-docs] “Choose an MCP client or framework to connect an AI assistant to ClickHouse.”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso✓fullprobed8/10

   Turso ships a scriptable CLI (turso db create/shell), local dev server (turso dev / sqld) that runs keylessly with no account, and SDK push/pull automation, all confirmed by hands-on probes showing real SQL roundtrips headlessly on port 8085 — ideal for CI pipelines and PR-based branch automation. missing for 10: no explicit CI recipe/example (e.g. GitHub Actions workflow) in the evidence, and no independent community report specifically confirming CI usage.

   • [claimed-docs] “turso db create my-db --tursodb”
   • [claimed-docs] “Now connect to it with the `shell` command:”
   • [claimed-docs] “This will start a local libSQL server and create a database for you.”
   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”
   • [claimed-docs] “Push local writes to Turso Cloud await db.push(); // Pull remote changes to local database const changed = await db.pull();”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Turso CLI installed via the vendor's get.tur.so installer and `turso --version` printed `t…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”
   • [probe] “official CLI documented at https://docs.turso.tech/cli/introduction”

   proof ↗⚑ flag

   ClickHouse✓fullprobed7/10

   ClickHouse ships a single-binary CLI, clickhouse-local for scripting without a full install, and an HTTP interface with explicit format control (X-ClickHouse-Format), all of which support headless/automated use, plus a simple curl-based install script suited for CI environments. Missing for 10: no explicit CI/pipeline example or GitHub Actions integration doc, and no independent hands-on report specifically confirming CI usage.

   • [claimed-docs] “developers can use SQL commands ... directly from the command line, providing a simple and efficient way to access ClickHouse features witho…”
   • [claimed-docs] “clickhouse-local is an easy-to-use version of ClickHouse that is ideal for developers who need to perform fast processing on local and remot…”
   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment. Quick install gets you a single binary fast”
   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment.”
   • [claimed-docs] “The X-ClickHouse-Format HTTP request header now explicitly selects the format of the response”
   • [claimed-docs] “The X-ClickHouse-Format HTTP request header now explicitly selects the format of the response: it is an alias for the output_format setting,…”
   • [github] “curl https://clickhouse.com/ | sh”
   • [probe] “official CLI documented at https://clickhouse.com/docs/concepts/features/interfaces/cli”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Turso✓fullprobed8/10

   Turso ships an official hosted MCP server (mcp.turso.ai) that lets any MCP-capable agent manage databases, branches, and run SQL without manual token handling, documented at docs.turso.tech/integrations/mcp and confirmed live via a runtime probe returning the expected OAuth challenge from the real endpoint. Missing for 10: independent/community hands-on validation of the MCP server specifically (all community evidence concerns core DB features, not MCP usage).

   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “There’s no API token to copy or paste.”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [probe] “official MCP server documented at https://docs.turso.tech/integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse✓fullprobed8/10

   ClickHouse ships an official MCP server (mcp-clickhouse on GitHub) plus docs guiding users to choose an MCP client/framework to connect an AI assistant to ClickHouse, directly matching the story. Missing for 10: independent hands-on verification of the MCP server's reliability/feature completeness beyond first-party docs.

   • [claimed-docs] “Choose an MCP client or framework to connect an AI assistant to ClickHouse.”
   • [claimed-docs] “Connect ClickHouse to your AI assistants.”
   • [probe] “official MCP server documented at https://github.com/ClickHouse/mcp-clickhouse”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Turso
   Turso✓fullprobed9/10

   Turso ships an official CLI (documented at docs.turso.tech/cli/introduction, used throughout quickstart for db create, shell, dump) and this was independently verified at runtime (installed via get.tur.so, `turso --version` worked, and `turso dev` booted a real local libSQL server with a working SQL roundtrip). It also integrates with AI agents via an official MCP server, reinforcing agenticness. missing for 10: no independent community commentary specifically praising/critiquing the CLI's AI-native workflow ergonomics beyond vendor docs and probes.

   • [probe] “official CLI documented at https://docs.turso.tech/cli/introduction”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Turso CLI installed via the vendor's get.tur.so installer and `turso --version` printed `t…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”
   • [claimed-docs] “turso db create my-db --tursodb”
   • [claimed-docs] “Now connect to it with the `shell` command:”
   • [claimed-docs] “turso db shell my-db”
   • [probe] “official MCP server documented at https://docs.turso.tech/integrations/mcp”

   proof ↗⚑ flag

   ClickHouse✓fullprobed8/10

   ClickHouse ships an official CLI (clickhousectl, installed via curl https://clickhouse.com/cli | sh) that manages local/cloud ClickHouse instances, and it explicitly supports installing official agent skills into coding agents, directly targeting AI-native/agentic workflows. missing for 10: independent hands-on community corroboration of the CLI's agentic features specifically (community evidence pack covers general ClickHouse use, not this CLI).

   • [claimed-docs] “Install and manage local ClickHouse versions”
   • [claimed-docs] “Install the official ClickHouse agent skills into supported coding agents”
   • [claimed-docs] “With clickhousectl you can: * Install and manage local ClickHouse versions * Launch and manage local ClickHouse servers”
   • [claimed-docs] “clickhousectl works as a version manager for ClickHouse, inspired by tools like uv and pnpm.”
   • [claimed-docs] “curl https://clickhouse.com/cli | sh”
   • [probe] “official CLI documented at https://clickhouse.com/docs/concepts/features/interfaces/cli”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Turso✓fullprobed8/10

   Turso documents and exposes a public API (database provisioning, token-scoping, SQL execution) per turso-docs-8/12, plus SDKs in multiple languages (turso-docs-13) and a live Hrana HTTP API confirmed via runtime probe (turso-probe-rt-2), and a hosted MCP endpoint for agent-driven control (turso-docs-9, turso-probe-rt-3). No formal OpenAPI/Swagger spec was found (turso-probe-3), and community evidence doesn't specifically corroborate API completeness beyond SDK usage. missing for 10: a discoverable OpenAPI/swagger spec, independent hands-on confirmation of the REST/management API beyond SQL execution.

   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “Spin up thousands or millions of isolated databases programmatically, each with its own boundary. Not a workaround. The architecture.”
   • [claimed-docs] “SQLite-compatible. SDKs in TypeScript, Python, Rust, and Go. Self-serve from signup to production.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.turso.tech/openapi.json, https://docs.turso.tech/swagger.json, https://docs.turso.tech/…”
   • [probe] “official MCP server documented at https://docs.turso.tech/integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse✓fullprobed8/10

   ClickHouse exposes a documented public HTTP/SQL API, an OpenAPI spec (clickhouse-probe-3), and an llms.txt for AI-native discovery (clickhouse-probe-1), plus a CLI and official MCP server for programmatic/agentic access. This gives AI-native users multiple documented, machine-consumable interfaces to drive the product. missing for 10: independent hands-on validation of the OpenAPI/HTTP API from third parties, and more detail on API versioning/stability guarantees.

   • [probe] “PROBE llms.txt: HTTP 200 at https://clickhouse.com/llms.txt # ClickHouse > ClickHouse is a fast open-source column-oriented database manage…”
   • [probe] “PROBE openapi: HTTP 200 at https://clickhouse.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://github.com/ClickHouse/mcp-clickhouse”
   • [probe] “official CLI documented at https://clickhouse.com/docs/concepts/features/interfaces/cli”
   • [claimed-docs] “Choose an MCP client or framework to connect an AI assistant to ClickHouse.”
   • [claimed-docs] “Connect ClickHouse to your AI assistants.”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso✓fullprobed8/10

   Docs explicitly describe provisioning a dedicated, isolated database per AI agent that you 'create, token-scope, and tear down via the API' (turso-docs-8), directly matching least-privilege per-agent credentials, and the MCP integration uses OAuth-based auth rather than shared static tokens (turso-docs-9/37, confirmed live via turso-probe-rt-3). Missing for 10: detailed documentation of fine-grained permission scopes (e.g., read-only vs write, table-level scopes) and independent/hands-on validation of the token-scoping API itself.

   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse—none0/10

   No evidence describes issuing scoped or least-privilege API credentials/tokens specifically for AI agents; ClickHouse Cloud has general access controls but nothing in this pack documents credential scoping tailored to agentic use.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Turso
   Turso✓fullprobed9/10

   Turso documents official SDKs in TypeScript, Python, Rust, and Go with concrete quickstart usage (push/pull, embedded replicas), and this is corroborated by a CLI/local-dev runtime probe showing real SQL execution over a supported protocol. This directly satisfies 'build against official SDKs' for AI-native/agentic use, including per-agent database provisioning via API and MCP integration for agent-driven management. Missing for 10: independent hands-on validation of the non-TS SDKs (Python/Rust/Go) specifically, beyond the TS quickstart and vendor docs.

   • [claimed-docs] “SQLite-compatible. SDKs in TypeScript, Python, Rust, and Go. Self-serve from signup to production.”
   • [claimed-docs] “push() sends your changes to the cloud. pull() brings remote changes down.”
   • [claimed-docs] “Push local writes to Turso Cloud await db.push(); // Pull remote changes to local database const changed = await db.pull();”
   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”
   • [probe] “official MCP server documented at https://docs.turso.tech/integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse—none0/10

   The evidence pack documents ClickHouse's CLI, MCP server, and OpenAPI spec but contains no mention of official client SDKs (e.g., Python, Go, Java client libraries) for building applications, which is what this story specifically asks about.

   ⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Turso—none0/10

   No evidence anywhere in the pack of webhook support or event subscription mechanisms; Turso's documented integration surface is CLI, SDKs, API, and MCP, not webhooks. This is a fair capability to ask of a cloud database (e.g., change-data-capture notifications), so absence is 'none' rather than 'na'.

   ⚑ flag

   ClickHouse—none0/10

   No evidence of any webhook subscription or event-notification mechanism in ClickHouse; the evidence covers CLI, MCP, cloud pricing, vector search, and materialized views but nothing about webhooks for event-driven notifications.

   ⚑ flag

Agentic features

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

   weight 2 · round to ClickHouse
   Turso—none0/10

   Turso provides infrastructure primitives (native vector search, MCP integration for agents to run SQL) but no evidence of a built-in feature that itself generates AI insights or suggestions about the user's stored data — it merely provides raw building blocks for others to build such features on top.

   ⚑ flag

   ClickHouse~partialclaimed4/10

   ClickHouse shows early in-product AI features — an AI agent that queries logs/traces/metrics and surfaces summaries in ClickStack notebooks, plus private-preview AI Functions/Inference Service in ClickHouse Cloud — but both are waitlist/private-preview only, not generally available, and no hands-on or community evidence confirms them working in production. Missing for 10: GA availability, independent/community validation of insight quality, and broader in-product suggestion features beyond observability notebooks.

   • [claimed-docs] “You can describe an issue in plain language, and the AI agent will query logs, traces, and metrics on your behalf — surfacing relevant data,…”
   • [claimed-docs] “Sign up for private preview access to AI Functions and the AI Inference Service in ClickHouse Cloud. Use AI functions in si”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso~partialprobed5/10

   Turso provides infrastructure that supports agent-driven automation — a documented MCP server that lets any MCP-capable agent autonomously manage the Turso Cloud account, provision/branch databases and run SQL (turso-docs-9, turso-docs-37, verified live in turso-probe-rt-3), plus an API for programmatically provisioning per-agent isolated databases (turso-docs-8, turso-docs-12) and automating branch creation for CI/CD pipelines (turso-docs-11). However, Turso itself has no native scheduler, trigger, or cron/background-job engine — the 'automation' must be built externally by the agent/orchestrator calling Turso's API/MCP, not something Turso runs autonomously on its own. Missing for 10: a built-in scheduled/triggered job or workflow engine, and independent/hands-on evidence of an agent actually running unattended background automations against Turso.

   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse~partialclaimed4/10

   ClickHouse offers building blocks that could let an AI-native user configure background automation — Incremental Materialized Views that run computation automatically at insert time, ClickPipes for continuous automated data ingestion, and an official MCP server/agent skills so an AI assistant can issue the SQL to set these up — but there is no first-party or independent evidence of a named 'autonomous agent automation' feature that an AI agent sets up and monitors end-to-end in the background; the closest agentic feature (AI notebooks in ClickStack) is an interactive waitlist preview, not an autonomous background automation. Missing for 10: a documented autonomous scheduling/orchestration feature explicitly designed for AI agents, and evidence of it being used hands-on to run unattended background jobs.

   • [claimed-docs] “allow you to shift the cost of computation from query time to insert time, resulting in faster SELECT queries”
   • [claimed-docs] “Incremental Materialized Views (Materialized Views) allow you to shift the cost of computation from query time to insert time, resulting in …”
   • [claimed-docs] “Create and manage ClickPipes for data ingestion (S3, Kafka, Kinesis, Postgres, MySQL, MongoDB, BigQuery)”
   • [claimed-docs] “Choose an MCP client or framework to connect an AI assistant to ClickHouse.”
   • [claimed-docs] “Connect ClickHouse to your AI assistants.”
   • [claimed-docs] “Install the official ClickHouse agent skills into supported coding agents”
   • [claimed-docs] “You can describe an issue in plain language, and the AI agent will query logs, traces, and metrics on your behalf — surfacing relevant data,…”

   proof ↗⚑ flag

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

   weight 3 · round to ClickHouse
   Turso—none0/10

   Turso's evidence only shows an MCP server letting external AI agents connect to and manage Turso (agent-as-client), not a built-in AI assistant embedded within the Turso product itself that users could delegate tasks to. No CLI, dashboard, or SDK feature describes an in-product AI assistant.

   ⚑ flag

   ClickHouse~partialclaimed3/10

   ClickHouse Cloud is previewing an in-product AI agent (ClickStack AI notebooks) that can query logs/traces/metrics on the user's behalf, and a separate AI Functions/Inference Service is also in private preview — but both are waitlist-only, not generally available built-in assistants. Missing for 10: GA availability of the assistant, first-party documentation beyond waitlist pages, and independent/hands-on evidence of it actually delegating tasks.

   • [claimed-docs] “You can describe an issue in plain language, and the AI agent will query logs, traces, and metrics on your behalf — surfacing relevant data,…”
   • [claimed-docs] “Sign up for private preview access to AI Functions and the AI Inference Service in ClickHouse Cloud. Use AI functions in si”
   • [claimed-docs] “Sign up for private preview access to ClickStack Cloud, a fully turnkey observability platform built on ClickHouse. Send OpenTelemetry logs,…”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso✓fullprobed8/10

   Turso ships an official, documented MCP integration that lets any MCP-capable AI agent manage the Turso Cloud account (create/branch databases, groups) and run SQL directly via natural-language agent commands, with no manual API token handling — and a runtime probe confirms the hosted MCP endpoint (mcp.turso.ai) is live and enforces the documented OAuth flow. This directly satisfies the AI-native/agentic natural-language operation story. Missing for 10: independent/community hands-on validation of the MCP agent workflow itself (evidence pack has no third-party reports specifically using the MCP interface, only vendor docs and a runtime auth probe).

   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “There’s no API token to copy or paste.”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [probe] “official MCP server documented at https://docs.turso.tech/integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse~partialprobed5/10

   ClickHouse supports natural-language operation indirectly via its official MCP server and agent skills, which let external AI assistants translate NL into SQL/actions against ClickHouse, and a waitlisted AI-notebooks feature lets users 'describe an issue in plain language' to get results. However, this relies on third-party AI clients/MCP frameworks rather than a built-in NL interface, and the most direct plain-language feature is still in private preview/waitlist, not GA. Missing for 10: a generally-available first-party NL command interface (not waitlist-only), and independent hands-on evidence of NL command reliability.

   • [claimed-docs] “Install the official ClickHouse agent skills into supported coding agents”
   • [claimed-docs] “Choose an MCP client or framework to connect an AI assistant to ClickHouse.”
   • [claimed-docs] “Connect ClickHouse to your AI assistants.”
   • [claimed-docs] “You can describe an issue in plain language, and the AI agent will query logs, traces, and metrics on your behalf — surfacing relevant data,…”
   • [probe] “official MCP server documented at https://github.com/ClickHouse/mcp-clickhouse”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Turso—none0/10

   Turso has API reference docs (turso-docs-8) but no evidence of an interactive, runnable-example reference; a direct probe for OpenAPI/Swagger interactive docs returned 404 on all candidate paths, indicating no such interactive reference is exposed.

   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.turso.tech/openapi.json, https://docs.turso.tech/swagger.json, https://docs.turso.tech/…”

   proof ↗⚑ flag

   ClickHouse—none0/10

   The only relevant evidence is that an OpenAPI spec file exists at clickhouse.com/openapi.json (clickhouse-probe-3), but there is no evidence of an actual interactive API reference UI (e.g., Swagger/Redoc-style browser) or runnable code examples tied to it. Missing for 10: an interactive docs page, 'try it out' functionality, and runnable example snippets tied to the API reference.

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

   proof ↗⚑ flag

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

   weight 2 · round to ClickHouse
   Turso—none0/10

   A direct probe for OpenAPI/swagger spec files at Turso's docs domain returned 404 on all candidate paths, and no other evidence shows a downloadable machine-readable API spec despite Turso having an API reference and CLI/SDK docs.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.turso.tech/openapi.json, https://docs.turso.tech/swagger.json, https://docs.turso.tech/…”
   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”

   proof ↗⚑ flag

   ClickHouse✓fullprobed9/10

   A probe confirms a live, machine-readable OpenAPI spec at https://clickhouse.com/openapi.json returning HTTP 200 with an 'openapi' key, and ClickHouse also publishes an llms.txt for AI-native discovery. Missing for 10: no independent/community corroboration of the OpenAPI spec's completeness or usage.

   • [probe] “PROBE openapi: HTTP 200 at https://clickhouse.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://clickhouse.com/llms.txt # ClickHouse > ClickHouse is a fast open-source column-oriented database manage…”

   proof ↗⚑ flag

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

   weight 1 · round to Turso
   Turso✓fullprobed8/10

   Turso's branching feature explicitly creates a separate database instance from production for dev/testing without affecting the original, and local development (turso dev, local file DBs, dump-and-use-locally) plus PITR further support safe sandbox testing away from production; runtime probes confirm branching and local dev commands actually work. Missing for 10: no independent hands-on evidence of branch-based testing workflows specifically (only local-dev CLI was runtime-verified), and no documented automatic data-masking/anonymization when branching from production data.

   • [claimed-docs] “Branches are useful for development and testing, because they allow you to make changes to the database without affecting the original datab…”
   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database.”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database... Branches are useful for development and testing, becau…”
   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”
   • [claimed-docs] “You can always dump your production database and use it locally for development”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”

   proof ↗⚑ flag

   ClickHouse~partialprobed6/10

   ClickHouse offers clickhouse-local and clickhousectl for spinning up local/ephemeral ClickHouse instances for testing without touching a production cluster, and chdb for in-process experimentation, which functionally serve as sandbox environments. However, there's no explicit 'sandbox mode' or dedicated test-data isolation feature marketed for AI agents specifically, and no evidence of built-in safeguards preventing accidental production writes. Missing for 10: explicit sandbox/test-environment product feature, documentation tying local instances to safe AI-agent testing workflows, and independent verification that local/dev setups are isolated from production by design.

   • [claimed-docs] “developers can use SQL commands ... directly from the command line, providing a simple and efficient way to access ClickHouse features witho…”
   • [claimed-docs] “clickhouse-local is an easy-to-use version of ClickHouse that is ideal for developers who need to perform fast processing on local and remot…”
   • [claimed-docs] “With clickhousectl you can: * Install and manage local ClickHouse versions * Launch and manage local ClickHouse servers”
   • [claimed-docs] “clickhousectl works as a version manager for ClickHouse, inspired by tools like uv and pnpm.”
   • [claimed-docs] “Experience the power of ClickHouse, in-process. With unparalleled performance, reliability, and scalability for any data-intensive applicati…”
   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment.”
   • [probe] “official CLI documented at https://clickhouse.com/docs/concepts/features/interfaces/cli”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Turso—none0/10

   No evidence pack item mentions API versioning scheme or a deprecation policy for Turso's APIs, SDKs, or CLI; probes even show no OpenAPI spec discoverable at expected paths. This is a fair axis for a cloud API/database product, so absence of evidence yields 'none'.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.turso.tech/openapi.json, https://docs.turso.tech/swagger.json, https://docs.turso.tech/…”

   proof ↗⚑ flag

   ClickHouse—none0/10

   The evidence shows changelog entries documenting breaking behavior changes (e.g., default value and HTTP header changes) and an OpenAPI spec exists, but there is no documented API versioning scheme or formal deprecation policy anywhere in the pack.

   • [claimed-docs] “The default value of max_insert_threads changed from 1 to auto, which resolves to the number of CPU cores available to the server. This para…”
   • [claimed-docs] “The X-ClickHouse-Format HTTP request header now explicitly selects the format of the response”
   • [claimed-docs] “The X-ClickHouse-Format HTTP request header now explicitly selects the format of the response: it is an alias for the output_format setting,…”
   • [probe] “PROBE openapi: HTTP 200 at https://clickhouse.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Turso✓fullclaimed7/10

   Turso explicitly documents provisioning thousands/millions of isolated databases programmatically via API for per-user/per-agent use cases, which directly supports bulk automation for AI-native workflows (turso-docs-8, turso-docs-12, turso-docs-13). Missing for 10: independent/hands-on corroboration of large-scale bulk provisioning, and explicit documentation of bulk row-level SQL batch operations (e.g. batch insert/update APIs) beyond database-level scale.

   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Spin up thousands or millions of isolated databases programmatically, each with its own boundary. Not a workaround. The architecture.”
   • [claimed-docs] “SQLite-compatible. SDKs in TypeScript, Python, Rust, and Go. Self-serve from signup to production.”

   proof ↗⚑ flag

   ClickHouse✓fullprobed7/10

   ClickHouse's SQL engine natively supports bulk operations across massive row counts — documented bulk/async insert strategies, parallelized INSERT SELECT by default, and materialized views that batch-process computation at insert time — and this is corroborated by independent users ingesting billions of rows/day with fast bulk queries. AI-native access to this bulk capability is enabled via the official CLI and MCP server, letting an AI agent issue such bulk SQL operations directly. Missing for 10: no evidence of an AI-agent-specific batch/bulk API (e.g., a dedicated bulk-operation endpoint for the MCP tool) beyond general SQL bulk insert/query support.

   • [claimed-docs] “How to choose an insert strategy, including bulk and asynchronous inserts.”
   • [claimed-docs] “The default value of max_insert_threads changed from 1 to auto, which resolves to the number of CPU cores available to the server. This para…”
   • [claimed-docs] “Incremental Materialized Views (Materialized Views) allow you to shift the cost of computation from query time to insert time, resulting in …”
   • [community] “I'm using Clickhouse to dump 1-5 billion rows per day from my company's traffic data, with 60 days retained, onto a single i5 desktop. Compl…”
   • [community] “Overall positive experience: 3-node cluster up quickly with official Docker images, ingested billions of rows fast, great compression. Downs…”
   • [probe] “official MCP server documented at https://github.com/ClickHouse/mcp-clickhouse”
   • [probe] “official CLI documented at https://clickhouse.com/docs/concepts/features/interfaces/cli”

   proof ↗⚑ flag

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

   weight 3 · round to ClickHouse
   Turso—none0/10

   The evidence pack contains no mention of SQL triggers, webhooks, change-data-capture, or any event-driven rule/action mechanism built into Turso. The closest mention (turso-docs-11, automating branch creation per pull request) describes external CI automation, not a rules engine that fires actions on database events, so this applicable axis (SQLite-based DBs commonly support CREATE TRIGGER) has no supporting evidence.

   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”

   proof ↗⚑ flag

   ClickHouse~partialclaimed4/10

   ClickHouse's incremental materialized views automatically trigger computation when new data (events/inserts) arrive, shifting cost from query time to insert time — a limited form of 'rule triggers on event' behavior, but this is scoped to SQL transformation, not a general action/automation rules engine (e.g. alerts, webhooks, external actions). Missing for 10: evidence of a broader rule/alerting/action framework, triggers tied to arbitrary conditions beyond inserts, or integration with external action systems (notifications, workflows).

   • [claimed-docs] “allow you to shift the cost of computation from query time to insert time, resulting in faster SELECT queries”
   • [claimed-docs] “Incremental Materialized Views (Materialized Views) allow you to shift the cost of computation from query time to insert time, resulting in …”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Turso—none0/10

   Turso's evidence pack covers database provisioning, branching, replication, vector search, and MCP-based agent management, but nothing describes any capability to schedule recurring jobs, cron-like tasks, or workflow automation triggers within Turso itself. As a database platform this axis is plausible (e.g., scheduled queries/maintenance jobs), so absence of evidence means 'none' rather than 'na'.

   ⚑ flag

   ClickHouse—none0/10

   ClickHouse is a database with CLI, cloud, MCP, and materialized view features, but there is no evidence of a job scheduler or workflow orchestration capability for recurring tasks; this is an applicable axis (databases can offer scheduled queries/cron jobs) but no such feature is documented.

   ⚑ flag

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

   weight 1 · round to Turso
   Turso~partialprobed5/10

   Turso provides branching (versioning of schema/data changes, including automating a new branch per PR) and point-in-time recovery (rollback for user errors), and its MCP integration lets an AI agent create/manage these branches and run SQL directly. However, there is no documented 'review' mechanism (e.g., diffing or approval workflow before merging a branch back), so the story's review component is unevidenced. Missing for 10: explicit review/diff/approval tooling for automation changes, and independent confirmation that AI agents actually use branching+PITR as a version-control workflow in practice.

   • [claimed-docs] “Branches are useful for development and testing, because they allow you to make changes to the database without affecting the original datab…”
   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”
   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [claimed-docs] “PITR allows you to restore a database to a specific point in time. This is useful for recovering from user errors, such as dropping a table …”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time.”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time. This is usefu…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [probe] “official MCP server documented at https://docs.turso.tech/integrations/mcp”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse—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

Branching

1. developerReset a branch from its parent or restore it to an earlier state without rebuilding from a dump

   weight 1 · round to Turso
   Turso~partialclaimed6/10

   Turso docs show branches can be created fresh from a parent (`turso db create ... --from-db`) and databases can be restored to an earlier point via PITR, both without needing a SQL dump/reload, which covers the two halves of the story. However, there's no documented in-place 'reset this existing branch to its parent' command — you'd recreate/delete-and-recreate the branch — and PITR is described as whole-database recovery, not branch-specific reset. Missing for 10: an explicit branch-reset API/CLI command, and documentation tying PITR restore to a specific branch rather than the whole database.

   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database.”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database... Branches are useful for development and testing, becau…”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time.”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time. This is usefu…”
   • [claimed-docs] “You can always dump your production database and use it locally for development”

   proof ↗⚑ flag

   ClickHouse—none0/10

   The evidence pack contains no mention of database branching, parent/child branch resets, or restoring branch state without rebuilding from a dump — this is a database branching feature (as seen in products like PlanetScale/Neon) that ClickHouse's docs never reference. Nothing in the docs, changelogs, or community discussion addresses branch lifecycle management.

   ⚑ flag

2. platform-engineerCreate and tear down per-pull-request database branches automatically from CI or my deploy platform

   weight 2 · round to Turso
   Turso~partialprobed7/10

   Turso documents branch creation via CLI (`turso db create ... --from-db`) and explicitly calls out automating branching for per-pull-request databases, plus API-driven provisioning/teardown of isolated databases, which platform engineers could wire into CI. However, there's no first-party CI/CD integration (e.g., GitHub Action, deploy-platform plugin) or documented teardown API call/webhook example, and no independent/hands-on evidence of a real CI pipeline doing this end-to-end. missing for 10: a documented CI/CD integration or GitHub Action for PR-branch lifecycle, an explicit teardown API example/webhook, and independent verification of the automated per-PR workflow in practice.

   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”
   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Spin up thousands or millions of isolated databases programmatically, each with its own boundary. Not a workaround. The architecture.”
   • [probe] “official CLI documented at https://docs.turso.tech/cli/introduction”

   proof ↗⚑ flag

   ClickHouse—none0/10

   No evidence of any database-branching feature (e.g., copy-on-write branches per PR) or CI/deploy-platform integration for creating/tearing down ephemeral database branches; ClickHouse's evidence covers local/cloud CLI setup, scaling, and pricing but nothing about branch-per-PR workflows.

   ⚑ flag

3. developerCreate an instant copy-on-write branch of my database — schema and data — to develop and test against production-shaped data

   weight 3 · round to Turso
   Turso✓fullclaimed9/10

   Turso's docs directly document creating a branch from an existing database with schema and data (`turso db create my-new-database-branch --from-db my-existing-database`), explicitly framed for dev/test isolation without affecting the original, and even automating per-PR branch creation. Community evidence corroborates general reliability of the platform, though no independent hands-on report specifically validates branch creation. Missing for 10: independent/community confirmation of the branching feature itself (only vendor docs cover it).

   • [claimed-docs] “Branches are useful for development and testing, because they allow you to make changes to the database without affecting the original datab…”
   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database.”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database... Branches are useful for development and testing, becau…”
   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”

   proof ↗⚑ flag

   ClickHouse—none0/10

   No evidence of a copy-on-write branching feature for schema+data in ClickHouse; the docs describe local dev servers, cloud clusters, CLI tooling, materialized views, and pricing, but nothing about instant branch/fork of a database for testing against production-shaped data.

   ⚑ flag

Drivers

1. developerQuery over HTTP or WebSockets from serverless and edge functions with an official driver built for short-lived connections

   weight 2 · round to Turso
   Turso~partialprobed7/10

   Turso's docs and probes confirm an HTTP-based protocol (Hrana) with a real SQL roundtrip over the HTTP pipeline API, and official SDKs in TypeScript/Python/Rust/Go built on a stateless client model suited to short-lived connections. However, the evidence pack never explicitly discusses WebSocket transport or edge/serverless deployment targeting, so only part of the story is directly evidenced. Missing for 10: explicit documentation of WebSocket driver mode, explicit serverless/edge runtime guidance (e.g. Vercel/Cloudflare Workers examples), and independent hands-on confirmation of edge usage.

   • [claimed-docs] “SQLite-compatible. SDKs in TypeScript, Python, Rust, and Go. Self-serve from signup to production.”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”
   • [claimed-docs] “Fully backwards compatible with SQLite, but built for the next generation”

   proof ↗⚑ flag

   ClickHouse—none0/10

   Evidence shows ClickHouse has a generic HTTP interface (format headers) but no mention of an official driver purpose-built for serverless/edge functions, no WebSocket support, and no discussion of short-lived-connection optimizations for edge runtimes.

   ⚑ flag

Latency

1. developerPlace data or replicas in regions close to my users to keep read latency low worldwide

   weight 2 · round to Turso
   Turso~partialcommunity6/10

   Turso's Embedded Replicas feature directly supports placing local read replicas near users, with reads served in microseconds from the replica and writes syncing to the cloud primary — this is well documented across multiple sources. However, the evidence pack lacks explicit documentation of choosing/configuring specific regions for primary or replica placement (e.g., a region-selection API/flag), and a community report notes a real-world multi-day latency spike tied to a regional networking issue on Turso's infrastructure, tempering confidence in worldwide low-latency guarantees. Missing for 10: explicit region-selection tooling/docs for placing databases or replicas in specific geographies, and independent benchmark confirmation of low latency across regions.

   • [claimed-docs] “Embedded Replicas keep a local read replica of a Turso Cloud database: reads run locally from the file in microseconds, and writes are sent …”
   • [claimed-docs] “reads run locally from the file in microseconds, and writes are sent to the cloud primary and then reflected back to the replica”
   • [claimed-docs] “Embedded Replicas keep a local read replica of a Turso Cloud database: reads run locally from the file in microseconds, and writes are sent …”
   • [claimed-docs] “providing local-first writes, explicit `push()` / `pull()`, and significantly less bandwidth and lower latency”
   • [community] “Didn't have a good experience with them. One day we suddenly started to experience severe latency spikes, lasting for more than a day, causi…”

   proof ↗⚑ flag

   ClickHouse—none0/10

   The evidence pack covers CLI tools, MCP integration, materialized views, vector search, pricing/autoscaling, and community sentiment on performance/compression, but contains no mention of multi-region deployment, region selection for ClickHouse Cloud services, or geo-distributed replica placement to reduce latency for global users. This is a fair question for a distributed database, so the axis applies, but there is no supporting evidence, yielding 'none'.

   ⚑ flag

Pooling

1. platform-engineerA built-in connection pooler handles thousands of concurrent connections without me operating my own pgbouncer or proxy

   weight 2 · round drawn
   Turso—none0/10

   Turso's evidence describes SQLite/libSQL architecture (embedded replicas, multi-writer without locking, HTTP/Hrana protocol) but nowhere documents a built-in connection pooler analogous to pgbouncer or claims about handling thousands of concurrent raw connections without such a proxy. Since Turso is not Postgres-based, the pgbouncer-specific framing doesn't map cleanly, but the general concern (many concurrent clients without an external pooler) is a fair question for any hosted DB and is simply unaddressed in the evidence pack.

   ⚑ flag

   ClickHouse—none0/10

   No evidence pack item mentions a built-in connection pooler, pgbouncer replacement, or handling of concurrent connection scaling within ClickHouse itself; evidence covers CLI, MCP, pricing autoscaling of compute, and general performance but not connection pooling.

   ⚑ flag

Ai data

1. developerStore embeddings and run vector similarity search natively without adding a separate vector database

   weight 2 · round to Turso
   Turso✓fullcommunity8/10

   Turso docs explicitly state native vector search support with no extensions required, supporting storage of embeddings alongside relational data and built-in distance functions for similarity search, and community evidence corroborates this as a genuine advantage over bolting vector extensions onto plain SQLite. Missing for 10: independent hands-on benchmarks of vector search performance/scale, and community feedback notes documentation on vector embeddings could be more robust.

   • [claimed-docs] “Turso supports vector search as a native feature — no extensions required.”
   • [claimed-docs] “Turso supports vector search as a native feature — no extensions required. Store vector embeddings alongside your relational data”
   • [claimed-docs] “Turso supports vector search as a native feature — no extensions required. Store vector embeddings alongside your relational data and query …”
   • [community] “It natively supports vector embeddings, which seems like it could be nice. The sqlite extensions I've tried for vector embeddings have been …”
   • [community] “We switched our main API from Postgres to Turso last month and haven't looked back. The automatic schema migrations are a nice touch, but I …”

   proof ↗⚑ flag

   ClickHouse✓fullclaimed7/10

   ClickHouse's docs explicitly document native exact and approximate vector similarity search written directly in SQL via ANN indexes, with tunable accuracy/speed trade-offs, meaning embeddings can be stored and searched without a separate vector DB. Missing for 10: independent/hands-on community validation of vector search performance and concrete embedding-storage usage examples beyond first-party docs.

   • [claimed-docs] “A vector search (exact or approximate) can be written in SQL as follows”
   • [claimed-docs] “A vector search (exact or approximate) can be written in SQL”
   • [claimed-docs] “Many approximate techniques provide parameters to tune the trade-off between the result accuracy and the search time.”
   • [claimed-docs] “Documentation for Exact and Approximate Vector Search”

   proof ↗⚑ flag

Analytics

1. developerRun heavy analytical aggregations over large tables fast enough for dashboards without exporting to a separate warehouse

   weight 2 · round to ClickHouse
   Turso—none0/10

   Turso's docs focus on SQLite-compatible OLTP features (embedded replicas, branching, PITR, vector search) with no mention of analytical/OLAP optimizations, columnar storage, or dashboard-scale aggregation performance. Community evidence actually points the other way: users report missing window functions and 'deeply nested joins which overflow something,' both core to heavy analytical aggregations, suggesting the product is not built or proven for this workload.

   • [community] “I've been using it locally and with their hosted offering for awhile now and it's rock solid other than if I make super deeply nested joins …”
   • [community] “Looks like it's still missing some important features like savepoints (!!!), windows and attach database.”

   proof ↗⚑ flag

   ClickHouse✓fullcommunity8/10

   ClickHouse's core design (columnar, MergeTree, incremental materialized views to precompute aggregations) is documented for fast analytical queries, and this is strongly corroborated by independent community reports of real-time aggregation over hundreds of millions/billions of rows at low cost, replacing Elasticsearch/Druid at scale, and use as a single-node BI backend without a separate warehouse (clickhouse-comm-18, -20, -12, -13, -15, -11, clickhouse-docs-9/18/12). Missing for 10: a documented head-to-head dashboard-latency benchmark, and mention of caveats like limited JOIN performance (clickhouse-comm-19) that could affect some aggregation workloads.

   • [claimed-docs] “allow you to shift the cost of computation from query time to insert time, resulting in faster SELECT queries”
   • [claimed-docs] “Incremental Materialized Views (Materialized Views) allow you to shift the cost of computation from query time to insert time, resulting in …”
   • [claimed-docs] “Powering agentic systems with millisecond queries at petabyte scale.”
   • [community] “I'm using Clickhouse to dump 1-5 billion rows per day from my company's traffic data, with 60 days retained, onto a single i5 desktop. Compl…”
   • [community] “I've used it in production for a year and a half - no other database gives real-time aggregation over hundreds of millions of rows inserted …”
   • [community] “ClickHouse is incredible. It has replaced a large, expensive and slow Elasticsearch cluster at Contentsquare - 300 Elastic nodes vs 12 Click…”
   • [community] “Druid got blown away by ClickHouse at eBay: Druid needed 700+ servers versus a 2-region fully replicated ClickHouse system of 40 nodes.”
   • [community] “Compared to Postgres, Clickhouse was a couple orders of magnitude faster for our query pattern, and easier to set up a single-node config th…”
   • [community] “People often think ClickHouse is useful only for TBs of data. That's wrong! It perfectly works on a single-server as a data source for self-…”
   • [community] “Overall positive experience: 3-node cluster up quickly with official Docker images, ingested billions of rows fast, great compression. Downs…”

   proof ↗⚑ flag

Compatibility

1. developerI get real engine compatibility — the Postgres, MySQL, or SQLite dialect and extensions my existing code expects — not a lookalike subset

   weight 3 · round to Turso
   Turso!disputedcontradicted4/10

   Turso's docs claim full SQLite compatibility ('Fully backwards compatible with SQLite', 'SQLite-compatible' SDKs, dump/shell/CLI tooling that mirrors SQLite), but hands-on community reports directly contradict this: using Turso/libSQL extensions breaks file-format compatibility so the standard SQLite CLI, Litestream, sqlite_rsync, recovery tools and SQLite UIs stop working, WAL-mode multi-process reads behave differently (exclusive lock errors), and important SQL features like savepoints, window functions, and ATTACH DATABASE are reported missing. Missing for 10: verified parity testing against the full SQLite feature/extension surface, resolution of the savepoints/windows/attach gaps, and independent confirmation that 'compatible' claims hold once libSQL-specific features are used.

   • [claimed-docs] “Fully backwards compatible with SQLite, but built for the next generation”
   • [claimed-docs] “SQLite-compatible. SDKs in TypeScript, Python, Rust, and Go. Self-serve from signup to production.”
   • [claimed-docs] “They are fully SQLite-compatible — they open existing SQLite files — and run entirely in your process, no server needed”
   • [community] “A gotcha, if you are expecting compatibility with sqlite. You can't set PRAGMA journal_mode=WAL and expect to be able to read database state…”
   • [community] “You're only file format compatible if you don't use any of the Turso extensions. As soon as you use an unsupported feature in your schema...…”
   • [community] “Looks like it's still missing some important features like savepoints (!!!), windows and attach database.”
   • [community] “I don't trust an open-source project once it's backed by a VC firm... At this point 'compatible with SQLite' has become a marketing term IMO…”
   • [community] “LOL '[conflict] resolution is not yet implemented'”

   proof ↗⚑ flag

   ClickHouse—none0/10

   ClickHouse uses its own SQL dialect; there is no evidence of genuine Postgres/MySQL/SQLite wire- or dialect-level compatibility for existing application code. Evidence instead points to the CLI managing separate Postgres instances/services (unrelated to ClickHouse's own SQL engine) and community feedback explicitly notes 'not-quite-standard SQL syntax' compared to standard dialects.

   • [claimed-docs] “Set up ClickHouse Cloud and create cloud-managed ClickHouse clusters * Create and manage ClickHouse Cloud Postgres services * Manage ClickHo…”
   • [claimed-docs] “Run and manage local Postgres instances * Execute queries against ClickHouse servers * Set up ClickHouse Cloud and create cloud-managed Clic…”
   • [community] “Overall positive experience: 3-node cluster up quickly with official Docker images, ingested billions of rows fast, great compression. Downs…”

   proof ↗⚑ flag

Local loop

1. developerThe official CLI covers my daily loop — create, connect, shell into, and inspect databases — without opening the dashboard

   weight 2 · round drawn
   Turso✓fullprobed8/10

   Docs and a runtime probe confirm the official `turso` CLI covers create (`turso db create`), connect/shell (`turso db shell`), and inspect (`.dump`) without needing the dashboard, and a live CLI install was verified running a local libSQL server keylessly. Missing for 10: independent/hands-on third-party confirmation of the full daily loop (beyond vendor docs) and more inspection commands (e.g. schema/list) shown in action.

   • [claimed-docs] “turso db create my-db --tursodb”
   • [claimed-docs] “Now connect to it with the `shell` command:”
   • [claimed-docs] “Congratulations, you created a database! Now connect to it with the `shell` command”
   • [claimed-docs] “turso db shell my-db”
   • [claimed-docs] “turso db shell your-database .dump > dump.sql”
   • [probe] “official CLI documented at https://docs.turso.tech/cli/introduction”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Turso CLI installed via the vendor's get.tur.so installer and `turso --version` printed `t…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”

   proof ↗⚑ flag

   ClickHouse✓fullprobed8/10

   ClickHouse ships an official clickhousectl CLI documented to install/manage local versions, launch/manage local servers, execute queries against servers, connect to Postgres, and push local dev to cloud, covering the create/connect/shell/inspect loop without a dashboard; clickhouse-local and single-binary install further support local dev workflows. Missing for 10: independent hands-on developer accounts specifically praising/critiquing the clickhousectl CLI daily loop (community evidence covers ClickHouse server usage generally, not the CLI tool itself), and detail on 'inspect' commands like schema browsing beyond query execution.

   • [claimed-docs] “With clickhousectl you can: * Install and manage local ClickHouse versions * Launch and manage local ClickHouse servers”
   • [claimed-docs] “clickhousectl works as a version manager for ClickHouse, inspired by tools like uv and pnpm.”
   • [claimed-docs] “Run and manage local Postgres instances * Execute queries against ClickHouse servers * Set up ClickHouse Cloud and create cloud-managed Clic…”
   • [claimed-docs] “Install and manage local ClickHouse versions * Launch and manage local ClickHouse servers”
   • [claimed-docs] “Push your local ClickHouse development to cloud”
   • [claimed-docs] “curl https://clickhouse.com/cli | sh”
   • [probe] “official CLI documented at https://clickhouse.com/docs/concepts/features/interfaces/cli”
   • [claimed-docs] “clickhouse-local is an easy-to-use version of ClickHouse that is ideal for developers who need to perform fast processing on local and remot…”
   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment. Quick install gets you a single binary fast”

   proof ↗⚑ flag

2. developerRun the same engine locally and keylessly — no account or cloud dependency — for offline development and CI tests

   weight 3 · round drawn
   Turso✓fullprobed9/10

   Turso's docs and CLI explicitly support a local, server-less libSQL database file with no account needed (turso-docs-2, turso-docs-16, turso-docs-17, turso-docs-30), and a hands-on runtime probe confirms `turso dev` boots a keyless local libSQL server and successfully executes real SQL without any cloud or account dependency (turso-probe-rt-1, turso-probe-rt-2). This directly satisfies offline/local dev and CI use cases keylessly. Missing for 10: an explicit first-party CI pipeline example/tutorial demonstrating this in an automated test suite context.

   • [claimed-docs] “local database file, no server needed (recommended)”
   • [claimed-docs] “Local Turso database — local database file, no server needed (recommended)”
   • [claimed-docs] “This will start a local libSQL server and create a database for you.”
   • [claimed-docs] “They are fully SQLite-compatible — they open existing SQLite files — and run entirely in your process, no server needed”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Turso CLI installed via the vendor's get.tur.so installer and `turso --version` printed `t…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”

   proof ↗⚑ flag

   ClickHouse✓fullcommunity9/10

   ClickHouse ships an open-source single binary and clickhouse-local that run entirely locally without any account or cloud dependency, explicitly marketed for building/testing/experimenting and fast local/CI file processing via SQL (clickhouse-docs-23, clickhouse-docs-27, clickhouse-docs-15, clickhouse-docs-1). Community corroboration confirms clickhouse-local's local, keyless utility for ad-hoc SQL processing (clickhouse-comm-4). Missing for 10: no explicit CI-pipeline example/tutorial demonstrating offline test usage in evidence.

   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment. Quick install gets you a single binary fast”
   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment.”
   • [claimed-docs] “clickhouse-local is an easy-to-use version of ClickHouse that is ideal for developers who need to perform fast processing on local and remot…”
   • [claimed-docs] “developers can use SQL commands ... directly from the command line, providing a simple and efficient way to access ClickHouse features witho…”
   • [github] “curl https://clickhouse.com/ | sh”
   • [community] “Clickhouse is criminally underused. It's common knowledge that 'postgres is all you need' - but if you reach the stage where postgres isn't …”

   proof ↗⚑ flag

Integrations

1. developerThe database works out of the box with my ORM and framework (Prisma, Drizzle, Django, Rails) with documented guides

   weight 2 · round drawn
   Turso—none0/10

   The evidence pack shows Turso's own CLI, SDKs, branching, embedded replicas, and MCP integration, but contains no mention of Prisma, Drizzle, Django, or Rails integration guides or documented ORM support. A database product could reasonably be expected to publish such guides, so the axis applies, but no evidence confirms it here.

   ⚑ flag

   ClickHouse—none0/10

   No evidence pack items mention Prisma, Drizzle, Django, Rails, or any ORM/framework integration guides for ClickHouse; documentation focuses on CLI tools, cloud setup, MCP, and vector search instead.

   ⚑ flag

Migrations

1. developerImport an existing production database with minimal downtime using a documented migration path

   weight 1 · round to ClickHouse
   Turso~partialclaimed4/10

   Turso docs show some building blocks for migration — opening existing SQLite files directly (turso-docs-30), dumping a production DB for local use (turso-docs-29, turso-docs-47), and creating a new DB branch `--from-db` an existing database (turso-docs-18) — but there is no dedicated, documented end-to-end migration guide addressing downtime, cutover, or importing from non-Turso production systems (e.g., Postgres/MySQL). Missing for 10: a documented step-by-step production migration/cutover guide, downtime guarantees or minimization strategy, and any independent/hands-on report of a real production migration succeeding.

   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [claimed-docs] “You can always dump your production database and use it locally for development”
   • [claimed-docs] “They are fully SQLite-compatible — they open existing SQLite files — and run entirely in your process, no server needed”
   • [claimed-docs] “turso db shell your-database .dump > dump.sql”

   proof ↗⚑ flag

   ClickHouse~partialclaimed5/10

   ClickHouse documents migration guides from various platforms and ClickPipes connectors for ingesting from Postgres, MySQL, MongoDB, BigQuery, Kafka, etc., which supports moving existing production data in with documented paths (clickhouse-docs-7, clickhouse-docs-28, clickhouse-docs-43). However, none of the evidence explicitly addresses minimal-downtime cutover strategies (e.g., dual-write, CDC replication, rollback plan) for a live production database migration. Missing for 10: explicit minimal-downtime/CDC migration guidance, a documented rollback/verification step, and independent hands-on confirmation that the migration path works with near-zero downtime.

   • [claimed-docs] “Migration guides from various platforms”
   • [claimed-docs] “Create and manage ClickPipes for data ingestion (S3, Kafka, Kinesis, Postgres, MySQL, MongoDB, BigQuery)”
   • [claimed-docs] “By migrating to ClickHouse from BigQuery, you can expect:”
   • [claimed-docs] “Run and manage local Postgres instances * Execute queries against ClickHouse servers * Set up ClickHouse Cloud and create cloud-managed Clic…”

   proof ↗⚑ flag

2. developerShip schema changes safely — online DDL, deploy requests, or branch-and-merge workflows — without locking or breaking production

   weight 3 · round to Turso
   Turso!disputedcontradicted5/10

   Turso documents branch creation from an existing database and automated per-PR branches for schema experimentation, plus PITR for rollback after bad migrations, giving developers a partial branch-based schema workflow — but there is no documented 'merge back' step, no online-DDL/zero-downtime migration tooling, and the vendor's 'Multiple writers, zero conflicts, without locking' claim is directly contradicted by hands-on community reports of WAL exclusive-lock errors and an admitted 'conflict resolution is not yet implemented' in Turso's newer engine. missing for 10: explicit branch-merge/schema-diff tooling, documented zero-downtime DDL mechanism, resolution of the locking/conflict contradictions.

   • [claimed-docs] “Branches are useful for development and testing, because they allow you to make changes to the database without affecting the original datab…”
   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”
   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database.”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database... Branches are useful for development and testing, becau…”
   • [claimed-docs] “Multiple writers, zero conflicts, without locking”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time.”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time. This is usefu…”
   • [community] “A gotcha, if you are expecting compatibility with sqlite. You can't set PRAGMA journal_mode=WAL and expect to be able to read database state…”
   • [community] “LOL '[conflict] resolution is not yet implemented'”

   proof ↗⚑ flag

   ClickHouse—none0/10

   The evidence pack contains no documentation of online/non-locking DDL, deploy-request workflows, or branch-and-merge schema change tooling for ClickHouse; the only tangentially related community notes describe ClickHouse as 'rigid-schema + append-only' and having 'limited DELETE support' rather than confirming safe schema-change tooling. Since schema-migration safety is a legitimate axis for any database product, absence of supporting evidence yields 'none' rather than 'na'.

   • [community] “Clickhouse is rigid-schema + append-only - you can't simply dump semi-structured JSON into it without workarounds; the only integration I've…”
   • [community] “Overall positive experience: 3-node cluster up quickly with official Docker images, ingested billions of rows fast, great compression. Downs…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Turso~partialprobed6/10

   Turso's Platform API and CLI let you create/manage databases, branches, tokens, and even tear down resources programmatically (turso-docs-8, turso-docs-14, turso-docs-18), and the official MCP server lets an AI agent manage organizations, databases, groups, and run SQL without manual tokens (turso-docs-9, turso-probe-rt-3), suggesting broad API/UI parity. However there is no explicit documentation stating full feature parity between dashboard and API, and a discoverable OpenAPI/swagger spec could not be found (turso-probe-3 all 404), leaving some doubt about completeness for every UI feature (e.g., billing, VPC allow-list config in turso-docs-22/46 aren't shown as API-controllable). missing for 10: explicit UI/API parity statement, a public OpenAPI spec, evidence that dashboard-only settings (billing, VPC allow lists) are also API-manageable.

   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Connect any MCP-capable AI agent and it can manage your Turso Cloud account — organizations, databases, groups — and run SQL, on your behalf…”
   • [claimed-docs] “turso db create my-db --tursodb”
   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.turso.tech/openapi.json, https://docs.turso.tech/swagger.json, https://docs.turso.tech/…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.turso.ai/mcp returned HTTP 401 wi…”

   proof ↗⚑ flag

   ClickHouse~partialprobed6/10

   ClickHouse's CLI/API (clickhousectl, HTTP interface, SQL) documents broad coverage of Cloud console functions—creating and managing clusters, ClickPipes, Postgres services, and cloud resources—suggesting most UI actions have API/CLI equivalents (clickhouse-docs-16/17/20/28/31/32). However, there is no explicit vendor statement guaranteeing full UI/API parity, and some Cloud-only waitlist features (AI Functions, ClickStack Cloud, PromQL support) appear to be UI/console-first with no confirmed API equivalent yet. Missing for 10: an explicit parity statement, independent verification that all console actions have API equivalents, and clarity on whether newer preview features are API-accessible.

   • [claimed-docs] “With clickhousectl you can: * Install and manage local ClickHouse versions * Launch and manage local ClickHouse servers”
   • [claimed-docs] “Push your local ClickHouse development to cloud”
   • [claimed-docs] “Set up ClickHouse Cloud and create cloud-managed ClickHouse clusters * Create and manage ClickHouse Cloud Postgres services * Manage ClickHo…”
   • [claimed-docs] “Create and manage ClickPipes for data ingestion (S3, Kafka, Kinesis, Postgres, MySQL, MongoDB, BigQuery)”
   • [claimed-docs] “Run and manage local Postgres instances * Execute queries against ClickHouse servers * Set up ClickHouse Cloud and create cloud-managed Clic…”
   • [claimed-docs] “Install and manage local ClickHouse versions * Launch and manage local ClickHouse servers”
   • [claimed-docs] “The X-ClickHouse-Format HTTP request header now explicitly selects the format of the response”
   • [claimed-docs] “The X-ClickHouse-Format HTTP request header now explicitly selects the format of the response: it is an alias for the output_format setting,…”
   • [probe] “PROBE openapi: HTTP 200 at https://clickhouse.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Sign up for private preview access to AI Functions and the AI Inference Service in ClickHouse Cloud. Use AI functions in si”
   • [claimed-docs] “Sign up for private preview access to ClickStack Cloud, a fully turnkey observability platform built on ClickHouse. Send OpenTelemetry logs,…”

   proof ↗⚑ flag

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

   weight 3 · round to ClickHouse
   Turso!disputedcontradicted4/10

   Turso documents a straightforward export path (`turso db shell <db> .dump > dump.sql`, docs-47) and markets itself as fully SQLite-compatible (docs-24, docs-13), which would let a user take a clean SQL dump and leave. However hands-on community reports directly contradict full openness: once any Turso-specific feature (vector search, replication, etc.) is used, the file is no longer plain-SQLite compatible — 'the SQLite CLI no longer works, Litestream doesn't work, sqlite_rsync doesn't work, recovery tools don't work, SQLite UIs don't work' (comm-8), undermining the 'export in open formats and leave' promise for any non-trivial schema. Missing for 10: vendor documentation acknowledging or addressing this compatibility caveat, and evidence of successful re-import of a dumped Turso database (with extensions) into vanilla SQLite/another engine.

   • [claimed-docs] “turso db shell your-database .dump > dump.sql”
   • [claimed-docs] “You can always dump your production database and use it locally for development”
   • [claimed-docs] “Fully backwards compatible with SQLite, but built for the next generation”
   • [claimed-docs] “SQLite-compatible. SDKs in TypeScript, Python, Rust, and Go. Self-serve from signup to production.”
   • [community] “You're only file format compatible if you don't use any of the Turso extensions. As soon as you use an unsupported feature in your schema...…”
   • [community] “I don't trust an open-source project once it's backed by a VC firm... At this point 'compatible with SQLite' has become a marketing term IMO…”

   proof ↗⚑ flag

   ClickHouse~partialclaimed5/10

   ClickHouse supports flexible output formats (e.g., the X-ClickHouse-Format header overriding query FORMAT) and offers 'Export backups to your own cloud account' plus migration guides and clickhouse-local for processing/exporting local and remote files via SQL, all pointing to open-format data portability. However, there is no explicit documentation enumerating full data export tooling (e.g., bulk export to CSV/Parquet/JSON at scale) or a stated commitment to avoiding lock-in, so the story is only partially evidenced. Missing for 10: explicit full-dataset export documentation/tutorial, an open-format export guarantee statement, and independent confirmation that a full migration-out is smooth.

   • [claimed-docs] “The X-ClickHouse-Format HTTP request header now explicitly selects the format of the response”
   • [claimed-docs] “The X-ClickHouse-Format HTTP request header now explicitly selects the format of the response: it is an alias for the output_format setting,…”
   • [claimed-docs] “Export backups to your own cloud account”
   • [claimed-docs] “Migration guides from various platforms”
   • [claimed-docs] “clickhouse-local is an easy-to-use version of ClickHouse that is ideal for developers who need to perform fast processing on local and remot…”
   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment.”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to ClickHouse
   Turso~partialprobed5/10

   A Turso engineer confirms that libSQL — the SQLite fork underlying Turso — is open source under the MIT license, and the CLI/local dev tooling is documented and runtime-verified as freely usable. However, there's no first-party documentation pack entry confirming the full Turso Cloud service or its newer Rust-based core is open-licensed, only a community aside. Missing for 10: an official first-party source-availability/license statement covering the whole product (cloud service, Rust rewrite), and independent corroboration beyond one community comment.

   • [community] “disclosure: I work at Turso. libSQL is our fork of SQLite. It adds new features on top of SQLite, such as vector search, replication, server…”
   • [probe] “official CLI documented at https://docs.turso.tech/cli/introduction”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Turso CLI installed via the vendor's get.tur.so installer and `turso --version` printed `t…”

   proof ↗⚑ flag

   ClickHouse✓fullprobed7/10

   ClickHouse's own site describes it as a 'fast open-source column-oriented database' and its source is hosted publicly on GitHub, confirming the codebase is openly readable/licensed. Missing for 10: an explicit citation of the license file/terms (e.g., Apache-2.0) rather than just the word 'open-source'.

   • [probe] “PROBE llms.txt: HTTP 200 at https://clickhouse.com/llms.txt # ClickHouse > ClickHouse is a fast open-source column-oriented database manage…”
   • [github] “curl https://clickhouse.com/ | sh”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to ClickHouse
   Turso~partialprobed7/10

   Turso's core engine, libSQL/sqld, is open source (MIT) and can be run entirely locally with no cloud dependency — confirmed by docs (turso-docs-16/17/30) and a hands-on probe showing a real keyless local libSQL server handling SQL round-trips (turso-probe-rt-1/rt-2). However, most of Turso's advanced product surface (branching, PITR, embedded replicas sync, hosted MCP, dashboards, BYOC S3) is tied to Turso Cloud rather than a fully self-hostable platform, and community comments raise real compatibility/feature caveats on the libSQL fork (turso-comm-8, turso-comm-9, turso-comm-12). Missing for 10: first-party docs/guide for self-hosting the full platform (not just dev-mode server), and independent reports of production self-hosted deployments at scale.

   • [claimed-docs] “Local Turso database — local database file, no server needed (recommended)”
   • [claimed-docs] “This will start a local libSQL server and create a database for you.”
   • [claimed-docs] “They are fully SQLite-compatible — they open existing SQLite files — and run entirely in your process, no server needed”
   • [community] “disclosure: I work at Turso. libSQL is our fork of SQLite. It adds new features on top of SQLite, such as vector search, replication, server…”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Turso CLI installed via the vendor's get.tur.so installer and `turso --version` printed `t…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”
   • [community] “You're only file format compatible if you don't use any of the Turso extensions. As soon as you use an unsupported feature in your schema...…”
   • [community] “Looks like it's still missing some important features like savepoints (!!!), windows and attach database.”

   proof ↗⚑ flag

   ClickHouse✓fullprobed8/10

   ClickHouse is a genuinely open-source, self-hostable database with a public GitHub repo, one-line install script, and docs explicitly instructing users to 'Run ClickHouse on your own machine to build, test, and experiment,' with community accounts confirming real self-hosted production deployments (Docker-based clusters, single-server setups, etc.). Some community reports note self-hosting has operational overhead (resource contention with Keeper, container privilege issues, ops burden vs managed cloud), but these are caveats about ease, not evidence the core product can't be self-hosted. Missing for 10: a first-party self-hosted deployment/ops guide (e.g., Kubernetes operator docs) cited directly and more independent large-scale self-host case studies.

   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment. Quick install gets you a single binary fast”
   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment.”
   • [github] “curl https://clickhouse.com/ | sh”
   • [probe] “PROBE llms.txt: HTTP 200 at https://clickhouse.com/llms.txt # ClickHouse > ClickHouse is a fast open-source column-oriented database manage…”
   • [community] “We're using Clickhouse to power our in-product analytics. It's awesome but would love a managed service - it definitely requires a bit of ma…”
   • [community] “I learned of Clickhouse in an unpleasant way. It is a dependency of Sentry. Installing self-hosted sentry on OpenShift failed because Clickh…”
   • [community] “Overall positive experience: 3-node cluster up quickly with official Docker images, ingested billions of rows fast, great compression. Downs…”

   proof ↗⚑ flag

Cost controls

1. founderSet spend caps or usage alerts so a runaway query or traffic spike cannot produce a surprise bill

   weight 1 · round to ClickHouse
   Turso—none0/10

   No evidence pack item mentions spend caps, budget limits, billing alerts, or usage-threshold notifications; pricing page references only mention plan tiers and VPC allow lists, not cost-control tooling. This is an applicable axis for a usage-billed cloud database, but nothing in the docs or community evidence shows Turso offers alerting or spend-capping features.

   • [claimed-docs] “AWS VPC Allow Lists”
   • [claimed-docs] “AWS VPC Allow Lists Free Developer Yes”

   proof ↗⚑ flag

   ClickHouse~partialclaimed6/10

   ClickHouse Cloud's pricing docs explicitly state you can 'Set compute autoscaling limits to prevent runaway queries from unexpected bills' and that compute scales down to zero when idle, directly addressing the founder's concern about surprise bills. However, this is a single vendor pricing-page mention with no detail on configurable spend caps, budget alerts/notifications, or independent/hands-on corroboration of how this works in practice. Missing for 10: documented alerting/notification mechanism for usage thresholds, more detailed spend-cap configuration docs, and independent user confirmation that this prevents runaway bills in practice.

   • [claimed-docs] “Set compute autoscaling limits to prevent runaway queries from unexpected bills”
   • [claimed-docs] “We automatically scale unused resources down to zero so that you don't pay for idle services”
   • [claimed-docs] “We automatically scale up and down compute resources based on your workload”
   • [claimed-docs] “Usage-based pricing: pay only for the compute and storage you use, scaled separately and down to zero when idle.”

   proof ↗⚑ flag

Insights

1. platform-engineerSee slow queries, index recommendations, and performance metrics in a built-in insights view

   weight 2 · round to ClickHouse
   Turso—none0/10

   No evidence of a built-in insights/observability view covering slow queries, index recommendations, or performance metrics; docs focus on branching, replication, durability, MCP, and CLI, with no mention of query analytics dashboards.

   ⚑ flag

   ClickHouse~partialclaimed2/10

   The only tangentially relevant evidence is a private-preview waitlist feature (AI notebooks in ClickStack) where an AI agent can surface logs/traces/metrics as charts and summaries, which loosely touches 'performance metrics' but is not a shipped, built-in insights view and never mentions slow-query identification or index recommendations. Everything else in the pack is about CLI tooling, pricing, MCP/AI integrations, and general architecture, none of which address a query-performance insights dashboard. Missing for 10: a GA built-in query-performance/insights view, explicit slow-query surfacing, and any index-recommendation capability with documentation or hands-on evidence.

   • [claimed-docs] “You can describe an issue in plain language, and the AI agent will query logs, traces, and metrics on your behalf — surfacing relevant data,…”
   • [claimed-docs] “Sign up for private preview access to ClickStack Cloud, a fully turnkey observability platform built on ClickHouse. Send OpenTelemetry logs,…”

   proof ↗⚑ flag

Pricing

1. founderA genuinely usable free tier lets me run real prototypes before paying

   weight 2 · round to Turso
   Turso✓fullcommunity7/10

   Turso's pricing page explicitly lists a Free plan alongside paid tiers (turso-docs-45, turso-docs-46), and independent community testimony confirms real production-adjacent use without needing to upgrade: "Super fast and cheap, haven't had to need more than the free tier" (turso-comm-2), plus another builder describing building an internal tool entirely on Turso (turso-comm-1). Missing for 10: explicit documentation of free-tier limits (storage/row/request caps) and more independent reports specifically stress-testing the free tier for prototyping at scale.

   • [claimed-docs] “Free 99.999999999% up to 100ms”
   • [claimed-docs] “AWS VPC Allow Lists Free Developer Yes”
   • [community] “I've been using it locally and with their hosted offering for awhile now and it's rock solid other than if I make super deeply nested joins …”
   • [community] “I built our internal meme platform with Turso. Really fun and easy to use.”

   proof ↗⚑ flag

   ClickHouse~partialclaimed6/10

   ClickHouse ships as fully free, open-source software that can be installed with a single binary or run via clickhouse-local/chDB for local prototyping without any paid tier (clickhouse-docs-23, clickhouse-docs-27, clickhouse-docs-35), and ClickHouse Cloud's usage-based pricing scales resources down to zero when idle so light prototyping incurs minimal cost (clickhouse-docs-25, clickhouse-docs-41, clickhouse-docs-11). However, there is no explicit documentation of a dedicated 'free tier' with trial credits for Cloud, and no community evidence describing hands-on prototyping experience on a genuinely free plan. Missing for 10: documented free-tier/trial credit details for ClickHouse Cloud, independent user accounts of prototyping for free before paying.

   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment. Quick install gets you a single binary fast”
   • [claimed-docs] “Run ClickHouse on your own machine to build, test, and experiment.”
   • [claimed-docs] “Experience the power of ClickHouse, in-process. With unparalleled performance, reliability, and scalability for any data-intensive applicati…”
   • [claimed-docs] “pay only for the compute and storage you use, scaled separately and down to zero when idle”
   • [claimed-docs] “Usage-based pricing: pay only for the compute and storage you use, scaled separately and down to zero when idle.”
   • [claimed-docs] “We automatically scale unused resources down to zero so that you don't pay for idle services”
   • [claimed-docs] “Start building instantly without having to size and scale your cluster.”

   proof ↗⚑ flag

2. founderPublished per-unit pricing for compute, storage, and traffic lets me predict my bill before committing

   weight 3 · round to ClickHouse
   Turso—none0/10

   The evidence only shows a pricing page exists with tier names and feature toggles (e.g., 'AWS VPC Allow Lists', 'Free', 'Developer') but no per-unit rates for compute, storage, or traffic (e.g., $/GB, $/row-read, $/egress) are cited anywhere in the pack, so a founder cannot predict a bill from this evidence.

   • [claimed-docs] “AWS VPC Allow Lists”
   • [claimed-docs] “AWS VPC Allow Lists Free Developer Yes”

   proof ↗⚑ flag

   ClickHouse~partialclaimed5/10

   ClickHouse's pricing page confirms a usage-based model—pay only for compute and storage used, scaled separately and down to zero when idle—plus autoscaling limits to cap bills, giving founders a general cost structure to reason about. However, the evidence never shows explicit published per-unit rates (e.g., $/vCPU-hour, $/GB-month storage, $/GB traffic) that would let someone precompute a bill precisely. Missing for 10: explicit per-unit dollar rates for compute, storage, and network egress, and any calculator/estimator evidence.

   • [claimed-docs] “We automatically scale unused resources down to zero so that you don't pay for idle services”
   • [claimed-docs] “Set compute autoscaling limits to prevent runaway queries from unexpected bills”
   • [claimed-docs] “pay only for the compute and storage you use, scaled separately and down to zero when idle”
   • [claimed-docs] “We automatically scale up and down compute resources based on your workload”
   • [claimed-docs] “Usage-based pricing: pay only for the compute and storage you use, scaled separately and down to zero when idle.”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso~partialclaimed6/10

   Turso's docs explicitly promise data-residency control — 'Bring-your-own-cloud deployment. Data residency you control' and the ability for Pro/Enterprise customers to use their own S3 buckets so 'data lives inside their infrastructure,' plus VPC allow-lists for network isolation. These are first-party claims only, gated to paid tiers, and the evidence pack lacks concrete detail on region selection at database-creation time or independent verification of BYOC/residency in practice. Missing for 10: independent/hands-on confirmation of residency controls, explicit region-picker mechanism in CLI/API docs, and clarity on free-tier residency options.

   • [claimed-docs] “Pro and Enterprise customers can use their own S3 / S3-express buckets, guaranteeing that data lives inside their infrastructure.”
   • [claimed-docs] “Per-database encryption with customer-held keys. Bring-your-own-cloud deployment. Data residency you control.”
   • [claimed-docs] “AWS VPC Allow Lists”
   • [claimed-docs] “AWS VPC Allow Lists Free Developer Yes”

   proof ↗⚑ flag

   ClickHouse—none0/10

   The evidence pack documents ClickHouse Cloud setup, pricing, and CLI tooling but never mentions selecting a deployment region or data residency options for AI-native users. Absence of evidence for this applicable cloud-data-residency capability means it is not shown to deliver.

   ⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Turso
   Turso~partialclaimed6/10

   Turso lets users provision and 'tear down via the API' isolated per-user/per-agent databases (docs-8), supports full dump/export for data portability (docs-29/47), and offers PITR for recovery windows plus customer-held encryption keys and BYOC/data-residency controls (docs-27, docs-28) — all relevant to retention/deletion posture. However there is no explicit documentation of configurable retention periods, GDPR-style deletion guarantees, or backup-purge behavior after deletion. Missing for 10: explicit retention-period configuration, documented deletion/purge guarantees for backups and replicas, and independent verification that tear-down fully erases data.

   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “Pro and Enterprise customers can use their own S3 / S3-express buckets, guaranteeing that data lives inside their infrastructure.”
   • [claimed-docs] “Per-database encryption with customer-held keys. Bring-your-own-cloud deployment. Data residency you control.”
   • [claimed-docs] “You can always dump your production database and use it locally for development”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time. This is usefu…”

   proof ↗⚑ flag

   ClickHouse—none0/10

   The evidence pack contains no vendor documentation on TTL policies, row-level deletion, or data retention controls; the only related community evidence (clickhouse-comm-19) notes 'limited DELETE support,' which does not establish that users can reliably control retention/deletion. Backup export (clickhouse-docs-22) is tangential and does not address retention/deletion policy.

   • [community] “Overall positive experience: 3-node cluster up quickly with official Docker images, ingested billions of rows fast, great compression. Downs…”
   • [claimed-docs] “Export backups to your own cloud account”

   proof ↗⚑ flag

Availability

1. platform-engineerAdd read replicas and rely on documented high-availability and failover behavior

   weight 2 · round to Turso
   Turso~partialclaimed5/10

   Turso documents embedded (read) replicas with clear push/pull replication behavior and durability guarantees (11 nines, sub-10ms), giving platform engineers some operational detail, but the evidence pack has no explicit documentation of failover/promotion behavior if the primary fails, multi-region HA topology, or replica-to-primary promotion procedures. Missing for 10: documented automatic failover/promotion process, multi-region HA architecture details, and independent verification of failover behavior under primary outage.

   • [claimed-docs] “Embedded Replicas keep a local read replica of a Turso Cloud database: reads run locally from the file in microseconds, and writes are sent …”
   • [claimed-docs] “reads run locally from the file in microseconds, and writes are sent to the cloud primary and then reflected back to the replica”
   • [claimed-docs] “Embedded Replicas keep a local read replica of a Turso Cloud database: reads run locally from the file in microseconds, and writes are sent …”
   • [claimed-docs] “providing local-first writes, explicit `push()` / `pull()`, and significantly less bandwidth and lower latency”
   • [claimed-docs] “99.999999999% up to 10ms”
   • [claimed-docs] “99.999999999%”
   • [claimed-docs] “99.999999999% ... up to 10ms”

   proof ↗⚑ flag

   ClickHouse~partialcommunity3/10

   Evidence only gestures at ClickHouse's replication/coordination layer (Keeper) and community anecdotes about running replicated clusters, but the pack contains no first-party documentation of adding read replicas, replica configuration, or documented failover behavior. missing for 10: dedicated HA/replication setup docs, explicit failover behavior documentation, read-replica configuration guide, quorum/consistency guarantees during failover.

   • [claimed-docs] “ClickHouse Keeper solves the well-known drawbacks of ZooKeeper and makes many additional improvements.”
   • [community] “IMO the only reason to not use ClickHouse is when you have 'small' data (<100GB) or small servers (<64GB RAM). Otherwise it's a better solut…”
   • [community] “Druid got blown away by ClickHouse at eBay: Druid needed 700+ servers versus a 2-region fully replicated ClickHouse system of 40 nodes.”

   proof ↗⚑ flag

Recovery

1. founderAutomatic backups run on a schedule I can see and configure, and restores are self-serve

   weight 2 · round to Turso
   Turso~partialclaimed4/10

   Turso documents point-in-time recovery (PITR) that lets you restore to a specific timestamp, which covers the recovery half of the story, and Pro/Enterprise customers can bring their own S3 buckets for backup storage. However there is no evidence of a visible, configurable backup schedule (frequency, retention window shown/editable) or a self-serve restore UI/CLI walkthrough — PITR is presented as continuous rather than a schedule you configure and see. Missing for 10: a documented backup schedule dashboard/config, explicit retention settings, and a concrete self-serve restore command/flow example.

   • [claimed-docs] “PITR allows you to restore a database to a specific point in time. This is useful for recovering from user errors, such as dropping a table …”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time.”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time. This is usefu…”
   • [claimed-docs] “Pro and Enterprise customers can use their own S3 / S3-express buckets, guaranteeing that data lives inside their infrastructure.”

   proof ↗⚑ flag

   ClickHouse~partialclaimed3/10

   Evidence only shows ClickHouse Cloud can 'export backups to your own cloud account' (pricing page), implying some backup capability exists, but there is no documentation of a visible/configurable backup schedule or a self-serve restore workflow. missing for 10: schedule visibility/configuration UI, self-serve restore process, docs or hands-on confirmation of restore success.

   • [claimed-docs] “Export backups to your own cloud account”

   proof ↗⚑ flag

2. platform-engineerRestore or branch the database to any point in time within the retention window to recover from bad writes

   weight 3 · round to Turso
   Turso✓fullclaimed8/10

   Turso documents explicit PITR ("restore a database to a specific point in time... recovering from user errors, such as dropping a table by mistake") and branching from any existing database (`turso db create ... --from-db`), directly covering both restore and branch-for-recovery workflows within a retention window. Docs also describe automating branch creation, giving platform engineers a scriptable recovery/testing path. Missing for 10: no explicit documentation of the retention window length/configurability, no independent/hands-on report confirming a PITR restore actually worked in production.

   • [claimed-docs] “PITR allows you to restore a database to a specific point in time. This is useful for recovering from user errors, such as dropping a table …”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time.”
   • [claimed-docs] “Turso supports point-in-time recovery (PITR) for databases. PITR allows you to restore a database to a specific point in time. This is usefu…”
   • [claimed-docs] “turso db create my-new-database-branch --from-db my-existing-database”
   • [claimed-docs] “A branch is a separate database instance that is created from an existing database.”
   • [claimed-docs] “Automating branching is useful for creating a new database for each pull request.”

   proof ↗⚑ flag

   ClickHouse—none0/10

   No evidence pack item mentions point-in-time restore, backup/restore mechanisms tied to a retention window, or database branching/cloning; the only tangential reference is 'Export backups to your own cloud account' which does not describe PITR or branching functionality.

   ⚑ flag

Elasticity

1. platform-engineerCompute autoscales up and down with load automatically, without manual resizes or downtime

   weight 2 · round to ClickHouse
   Turso—none0/10

   The evidence pack describes database provisioning at scale (thousands/millions of isolated databases), branching, replication, and durability, but contains no claim or documentation that per-database compute automatically scales up/down with load without manual resizing or downtime. Missing for 10: any docs on compute/resource autoscaling, load-based scaling triggers, or zero-downtime resize behavior.

   • [claimed-docs] “Spin up thousands or millions of isolated databases programmatically, each with its own boundary. Not a workaround. The architecture.”
   • [claimed-docs] “SQLite-compatible. SDKs in TypeScript, Python, Rust, and Go. Self-serve from signup to production.”

   proof ↗⚑ flag

   ClickHouse✓fullcommunity7/10

   ClickHouse Cloud docs explicitly state automatic compute autoscaling up and down, including scale-to-zero when idle, and usage-based pricing tied to actual usage rather than manual resizing (clickhouse-docs-40, clickhouse-docs-11, clickhouse-docs-25/41, clickhouse-docs-26). Autoscaling limits can also be configured to control cost (clickhouse-docs-21), directly matching the platform-engineer's need for automatic, downtime-free scaling. missing for 10: independent/hands-on confirmation that Cloud autoscaling avoids downtime in practice, and clarification of applicability to self-managed ClickHouse (community feedback in clickhouse-comm-8/9 notes self-hosted clusters historically lack storage/compute separation and require manual ops).

   • [claimed-docs] “We automatically scale up and down compute resources based on your workload”
   • [claimed-docs] “We automatically scale unused resources down to zero so that you don't pay for idle services”
   • [claimed-docs] “pay only for the compute and storage you use, scaled separately and down to zero when idle”
   • [claimed-docs] “Usage-based pricing: pay only for the compute and storage you use, scaled separately and down to zero when idle.”
   • [claimed-docs] “Start building instantly without having to size and scale your cluster.”
   • [claimed-docs] “Set compute autoscaling limits to prevent runaway queries from unexpected bills”
   • [community] “We just did months of testing on a bunch of dbs for a time-series workload. Whilst we really liked the story and devs behind clickhouse, the…”
   • [community] “We're using Clickhouse to power our in-product analytics. It's awesome but would love a managed service - it definitely requires a bit of ma…”

   proof ↗⚑ flag

2. founderIdle databases scale to zero so prototypes and side projects cost nothing while the data stays durable

   weight 3 · round to ClickHouse
   Turso—none0/10

   The evidence pack covers durability, branching, embedded replicas, vector search, and pricing tiers, but nowhere states that idle Turso databases scale to zero or that idle usage incurs no cost while data remains durable. Without explicit documentation or community confirmation of scale-to-zero behavior, this story is unsupported by the given evidence.

   ⚑ flag

   ClickHouse✓fullclaimed8/10

   ClickHouse Cloud explicitly advertises usage-based pricing that scales compute and storage down to zero when idle, so idle prototypes incur no compute cost while data remains stored durably in the cloud service, and users can start instantly without provisioning a cluster. Missing for 10: independent/hands-on confirmation of zero-cost idle behavior and durability guarantees specifically for long-dormant side projects (evidence is vendor-pricing-page only, no community corroboration of this exact scale-to-zero behavior).

   • [claimed-docs] “We automatically scale unused resources down to zero so that you don't pay for idle services”
   • [claimed-docs] “pay only for the compute and storage you use, scaled separately and down to zero when idle”
   • [claimed-docs] “We automatically scale up and down compute resources based on your workload”
   • [claimed-docs] “Usage-based pricing: pay only for the compute and storage you use, scaled separately and down to zero when idle.”
   • [claimed-docs] “Start building instantly without having to size and scale your cluster.”

   proof ↗⚑ flag

Provisioning

1. developerCreate a ready-to-connect database in seconds through the CLI or API without capacity planning

   weight 3 · round to Turso
   Turso✓fullprobed9/10

   Docs and runtime probes show `turso db create` plus `turso db shell` for instant cloud DB creation, and `turso dev` spinning up a fully keyless local libSQL server with a real SQL roundtrip in seconds — no capacity planning, provisioning API for programmatic per-user/agent DB creation, and self-serve signup-to-production flow are all documented and probe-verified. missing for 10: independent (non-vendor) benchmark or user account specifically confirming 'seconds-to-ready' timing for cloud creation beyond docs/probe.

   • [claimed-docs] “Create your first Turso Cloud database”
   • [claimed-docs] “turso db create my-db --tursodb”
   • [claimed-docs] “Now connect to it with the `shell` command:”
   • [claimed-docs] “Provision a dedicated database per user or per AI agent. Each entity gets its own isolated SQLite database that you create, token-scope, and…”
   • [claimed-docs] “SQLite-compatible. SDKs in TypeScript, Python, Rust, and Go. Self-serve from signup to production.”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Turso CLI installed via the vendor's get.tur.so installer and `turso --version` printed `t…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `turso dev --db-file /tmp/pa-turso-probe.db --port 8085` booted a fully keyless local libSQL server (sq…”
   • [claimed-docs] “Spin up thousands or millions of isolated databases programmatically, each with its own boundary. Not a workaround. The architecture.”

   proof ↗⚑ flag

   ClickHouse✓fullclaimed8/10

   ClickHouse Cloud can be provisioned via the CLI (clickhousectl) without manual capacity planning — docs explicitly state you can 'Set up ClickHouse Cloud and create cloud-managed ClickHouse clusters' from the CLI and 'Start building instantly without having to size and scale your cluster,' backed by usage-based, scale-to-zero autoscaling pricing so no upfront sizing is needed. Missing for 10: independent/hands-on corroboration of actual provisioning speed ('seconds'), and clearer standalone API (non-CLI) creation flow documentation.

   • [claimed-docs] “Set up ClickHouse Cloud and create cloud-managed ClickHouse clusters”
   • [claimed-docs] “Push your local ClickHouse development to cloud”
   • [claimed-docs] “Set up ClickHouse Cloud and create cloud-managed ClickHouse clusters * Create and manage ClickHouse Cloud Postgres services * Manage ClickHo…”
   • [claimed-docs] “Start building instantly without having to size and scale your cluster.”
   • [claimed-docs] “We automatically scale up and down compute resources based on your workload”
   • [claimed-docs] “Usage-based pricing: pay only for the compute and storage you use, scaled separately and down to zero when idle.”
   • [claimed-docs] “We automatically scale unused resources down to zero so that you don't pay for idle services”

   proof ↗⚑ flag