Turso vs CockroachDB

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

   CockroachDB~partialprobed7/10

   Local provisioning and full SQL schema/query workflows are verified end-to-end via CLI (`cockroach demo` booted a keyless cluster and executed a real CREATE TABLE/INSERT/SELECT roundtrip with no cloud account), and CockroachDB Cloud has a dedicated `ccloud` CLI for creating/connecting clusters plus an official MCP server that supports natural-language table listing, statement execution, and row inserts. However, the managed MCP endpoint is OAuth-gated (401 requiring bearer auth against a protected resource), meaning cloud provisioning via MCP/API isn't fully dashboard-free without an auth setup step, and no REST/API spec was found (openapi probes all 404'd). Missing for 10: a demonstrated single continuous agent flow (create→connect→schema→query) purely through API or MCP without any OAuth/dashboard touchpoint, and a documented REST API surface.

   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [claimed-docs] “The `ccloud` tool is a command-line interface (CLI) tool that allows you to create, manage, and connect to CockroachDB Cloud clusters.”
   • [claimed-docs] “install `ccloud` and use the `ccloud quickstart` command to interactively log in and create a new CockroachDB Serverless cluster.”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cockroachlabs.com/openapi.json, https://docs.cockroachlabs.com/swagger.json, https://do…”

   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 CockroachDB
   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

   CockroachDB~partialprobed5/10

   CockroachDB Cloud ships an official MCP server (confirmed live and OAuth-gated in probe) that lets an agent run natural-language-driven SQL operations including listing tables, executing statements, and inserting rows, which supports the 'agent runs SQL via tools' half of the story. However, no evidence describes distinct scoped tools separating read-only from destructive/write actions, or any safety controls for delegation. Missing for 10: documented read-only vs. write/destructive tool separation, permission scoping or confirmation gates for destructive operations, and any independent hands-on account of using these MCP tools safely.

   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “official MCP server documented at https://docs.cockroachlabs.com/docs/cockroachcloud/connect-to-the-cockroachdb-cloud-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”

   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

   CockroachDB~partialprobed4/10

   CockroachDB Cloud offers a programmatic CLI (`ccloud`) for creating/managing clusters and serverless billing that scales to zero when idle, which could support cost-efficient per-tenant provisioning, and `cockroach demo`/single-node clusters show lightweight instance creation is possible. However there is no evidence of a purpose-built mechanism for creating thousands of cheap, isolated databases (e.g., per-agent/tenant sandboxes) or bulk/programmatic fleet management at that scale. Missing for 10: evidence of bulk/batch database creation APIs, per-database cost/isolation guarantees at thousands-scale, and documented tenant-isolation patterns for AI-agent workflows.

   • [claimed-docs] “The `ccloud` tool is a command-line interface (CLI) tool that allows you to create, manage, and connect to CockroachDB Cloud clusters.”
   • [claimed-docs] “install `ccloud` and use the `ccloud quickstart` command to interactively log in and create a new CockroachDB Serverless cluster.”
   • [claimed-docs] “Request Unit consumption scales to zero when your cluster has no activity.”
   • [claimed-docs] “The `cockroach demo` starts a temporary, in-memory CockroachDB cluster of one or more nodes, with or without a preloaded dataset, and opens …”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round to Turso
   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

   CockroachDB✓fullprobed8/10

   CockroachDB serves a working llms.txt at docs.cockroachlabs.com/llms.txt (HTTP 200, indexing 6364 pages) plus a docs/.md agent-oriented endpoint, both confirmed live via direct probes rather than just vendor claims. missing for 10: no independent/community confirmation that agents actually consume these endpoints successfully, and no OpenAPI spec (404s) to complement the docs for agent tooling.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.cockroachlabs.com/llms.txt # CockroachDB - [CockroachDB (6364 pages)](https://docs.cockroachlabs.c…”
   • [probe] “PROBE docs-md: HTTP 200 at https://docs.cockroachlabs.com/docs/.md > ## Documentation Index > Fetch the complete documentation index at: htt…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   CockroachDB✓fullprobed8/10

   The `cockroach demo` and `cockroach start-single-node` commands can run entirely headlessly with no interactive shell or account (verified by a runtime probe executing SQL via `-e` flag, offline, insecure mode), and CockroachDB installs via simple package managers (brew) suitable for CI pipelines. missing for 10: no explicit CI recipe/Docker/GitHub Actions example in docs, and no independent CI-integration case study.

   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach version` printed `Build Tag: v26.3.1` keylessly after `brew install cockroachdb/tap/cockroac…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”
   • [claimed-docs] “The `cockroach demo` starts a temporary, in-memory CockroachDB cluster of one or more nodes, with or without a preloaded dataset, and opens …”
   • [claimed-docs] “A single-node cluster is appropriate for quick SQL testing or app development.”
   • [claimed-docs] “Instruct Homebrew to install CockroachDB: $ brew install cockroachdb/tap/cockroach”

   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

   CockroachDB✓fullprobed8/10

   CockroachDB Cloud offers an official, documented MCP server enabling natural-language agent interactions (listing tables, executing statements, inserting rows), and a runtime probe confirms the endpoint is live and OAuth-gated exactly as documented. Missing for 10: independent/community hands-on validation of agent workflows beyond first-party docs and probes, and details on feature completeness/limits of the MCP server's tool surface.

   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “official MCP server documented at https://docs.cockroachlabs.com/docs/cockroachcloud/connect-to-the-cockroachdb-cloud-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”

   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

   CockroachDB✓fullprobed8/10

   CockroachDB ships an official `cockroach` CLI (demo, start, sql shell) verified via runtime probes performing real SQL roundtrips, plus a separate `ccloud` CLI for cloud cluster management, both documented and hands-on confirmed. This is a general-purpose DB CLI rather than one purpose-built for AI-native/agentic workflows, though the product does offer an MCP server for natural-language agent interaction as a complementary path. Missing for 10: CLI features explicitly marketed toward AI-agent automation (e.g., structured/JSON output modes tailored for agent consumption, agent-specific CLI subcommands) and independent third-party corroboration of ccloud CLI usage.

   • [claimed-docs] “CockroachDB changefeeds have an at-least-once delivery guarantee as well as message ordering guarantees.”
   • [claimed-docs] “The `ccloud` tool is a command-line interface (CLI) tool that allows you to create, manage, and connect to CockroachDB Cloud clusters.”
   • [claimed-docs] “install `ccloud` and use the `ccloud quickstart` command to interactively log in and create a new CockroachDB Serverless cluster.”
   • [probe] “official CLI documented at https://docs.cockroachlabs.com/docs/stable/cockroach-demo”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach version` printed `Build Tag: v26.3.1` keylessly after `brew install cockroachdb/tap/cockroac…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”

   proof ↗⚑ flag

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

   weight 3 · round to Turso
   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

   CockroachDB~partialprobed7/10

   CockroachDB exposes a well-documented, driver-agnostic PostgreSQL wire protocol (verified live via `cockroach demo` running real SQL) plus a documented MCP server for natural-language driving of read/write operations, both confirmed live in the probes. However, there is no discoverable OpenAPI/REST spec (all candidate paths 404), so a fully machine-readable HTTP API for cloud/cluster management is absent — missing for 10: a public OpenAPI/REST spec for cluster administration, independent hands-on confirmation of the MCP server's read/write actions beyond the documented claim.

   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”
   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cockroachlabs.com/openapi.json, https://docs.cockroachlabs.com/swagger.json, https://do…”
   • [probe] “official MCP server documented at https://docs.cockroachlabs.com/docs/cockroachcloud/connect-to-the-cockroachdb-cloud-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach version` printed `Build Tag: v26.3.1` keylessly after `brew install cockroachdb/tap/cockroac…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”

   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

   CockroachDB—none0/10

   The evidence shows CockroachDB's Cloud MCP server is gated by OAuth (401 + WWW-Authenticate Bearer, resource_metadata endpoint) and that SQL-level roles exist in general, but nothing in the pack documents an actual mechanism for issuing scoped, least-privilege API credentials specifically for an AI agent (e.g., agent-specific API keys, granular OAuth scopes, or role templates for automated clients). Missing for 10: documentation of scoped credential/token issuance workflow for agents, evidence of least-privilege role templates tied to the MCP/API surface, and any hands-on confirmation that such scoping works as intended.

   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”

   proof ↗⚑ 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

   CockroachDB~partialcommunity3/10

   CockroachDB doesn't maintain distinct official SDKs; it relies on PostgreSQL wire-protocol compatibility so any standard Postgres client library works, which is documented, but there is no evidence of CockroachDB-branded official SDKs for Python/Go/Java/etc. or AI-agent-specific SDK tooling. missing for 10: dedicated first-party SDKs beyond Postgres driver compatibility, independent corroboration of official SDK maintenance, and any SDK docs targeting AI-native/agentic use cases.

   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”
   • [community] “The wire protocol is compatible with Postgres, which allows re-using battle-tested Postgres clients. However it's a non-starter for my use c…”

   proof ↗⚑ 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

   CockroachDB—none0/10

   The evidence only shows CockroachDB changefeeds with at-least-once delivery guarantees (cockroachdb-docs-5), but no citation explicitly confirms webhook sinks or a webhook subscription mechanism as part of the changefeed feature; older community comments even note the lack of a 'change notification' mechanism. Missing for 10: explicit documentation of webhook sink configuration, webhook payload/auth setup, and any hands-on confirmation of webhook delivery.

   • [claimed-docs] “CockroachDB changefeeds have an at-least-once delivery guarantee as well as message ordering guarantees.”
   • [community] “It looks like there is still no mechanism for change notification, which in our particular case is the only missing feature that prevents us…”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to CockroachDB
   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

   CockroachDB~partialprobed4/10

   CockroachDB Cloud's official MCP server lets users issue natural-language prompts to query and manipulate data, and a runtime probe confirms the endpoint is live and OAuth-gated as documented, which enables AI-agent-driven exploration of data. However, this is a natural-language query interface, not a native AI insights/suggestions engine (e.g., automatic anomaly detection, recommended optimizations, or generated summaries) built into the product. Missing for 10: evidence of built-in generative insights/analytics beyond NL query passthrough, and independent hands-on validation of insight quality.

   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “official MCP server documented at https://docs.cockroachlabs.com/docs/cockroachcloud/connect-to-the-cockroachdb-cloud-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”

   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

   CockroachDB—none0/10

   CockroachDB documents background data mechanisms like changefeeds and backups, but there is no evidence of an AI-native automation framework where an agent can configure tasks that run autonomously in the background; the MCP server evidence only covers interactive read/write operations, not scheduled or persistent automations.

   • [claimed-docs] “CockroachDB changefeeds have an at-least-once delivery guarantee as well as message ordering guarantees.”
   • [claimed-docs] “You can create full or incremental backups of a , , or . Taking regular backups of your data is an operational best practice.”
   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   CockroachDB—none0/10

   Evidence only shows CockroachDB Cloud's MCP server, which lets external AI agents connect to and query CockroachDB using natural language — this is CockroachDB acting as a tool for outside AI agents, not a built-in assistant inside the product to which a user delegates tasks. No evidence of an in-console AI assistant/copilot feature exists in the pack.

   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”

   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

   CockroachDB✓fullprobed7/10

   CockroachDB Cloud ships an official MCP server that explicitly lets users issue natural-language prompts to list tables, execute statements, and insert rows, and a runtime probe confirms the documented MCP endpoint is live and OAuth-gated exactly as described. This is a direct, first-party natural-language interface to database operations rather than just NL-to-SQL translation elsewhere. Missing for 10: independent/hands-on evidence of an actual successful NL command being executed end-to-end (beyond auth handshake), and confirmation that this capability extends to self-hosted (non-Cloud) CockroachDB deployments.

   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “official MCP server documented at https://docs.cockroachlabs.com/docs/cockroachcloud/connect-to-the-cockroachdb-cloud-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”

   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

   CockroachDB—none0/10

   CockroachDB documents SQL reference, quickstarts, and an interactive `cockroach demo` shell, but there is no evidence of an interactive API reference (e.g., an OpenAPI/Swagger-style explorer with runnable examples) — the openapi probe explicitly found all candidate spec paths returning 404. This axis is plausible for a database's developer docs site, so the absence of evidence yields 'none' rather than 'na'.

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

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   CockroachDB—none0/10

   CockroachDB Cloud does offer a management API/CLI, but the evidence pack shows an explicit probe for a machine-readable API spec (openapi.json, swagger.json, etc.) at the docs domain returning 404 on every candidate path, and no other citation surfaces an OpenAPI or equivalent spec anywhere in the docs or cloud console.

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

   proof ↗⚑ flag

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

   weight 1 · round drawn
   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

   CockroachDB✓fullprobed8/10

   `cockroach demo` spins up a temporary, in-memory, single-node/multi-node cluster with a real interactive SQL shell that runs entirely offline with no cloud account, letting an AI-native user run test queries/CRUD without touching production data — confirmed by both docs and a hands-on runtime probe showing a full CREATE/INSERT/SELECT roundtrip. missing for 10: independent third-party corroboration beyond vendor docs/probe, and explicit documentation tying this sandbox workflow specifically to AI-agent/MCP-driven testing rather than manual SQL shell use.

   • [claimed-docs] “The `cockroach demo` starts a temporary, in-memory CockroachDB cluster of one or more nodes, with or without a preloaded dataset, and opens …”
   • [claimed-docs] “A single-node cluster is appropriate for quick SQL testing or app development.”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”

   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

   CockroachDB—none0/10

   The evidence pack contains no documentation of API versioning schemes or a deprecation policy for CockroachDB's SQL/client APIs, MCP server, or Cloud APIs. While such a policy is plausible for a database product (SQL compatibility, wire protocol versions, Cloud API), nothing in the provided evidence addresses it, so it cannot be credited.

   ⚑ flag

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

   weight 2 · round to Turso
   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

   CockroachDB~partialclaimed5/10

   CockroachDB is a distributed SQL database and standard SQL/Postgres-compatible clients naturally support batch INSERTs, transactions, and bulk import/export via backup-restore, but the evidence pack has no explicit documentation of bulk/batch operations (e.g., IMPORT, multi-row INSERT, bulk API) and the MCP server docs only mention inserting single rows via natural language rather than bulk multi-item operations. Missing for 10: explicit bulk-insert/IMPORT documentation, evidence of the MCP or CLI performing multi-item bulk operations in one call, and independent confirmation of bulk-operation performance at scale.

   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [claimed-docs] “You can create full or incremental backups of a , , or . Taking regular backups of your data is an operational best practice.”
   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”

   proof ↗⚑ flag

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

   weight 3 · round to CockroachDB
   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

   CockroachDB~partialclaimed3/10

   CockroachDB offers changefeeds (CDC) that emit ordered, at-least-once delivery events to external systems, which can be used to build event-driven automation outside the database, but there is no evidence of a native rule/trigger engine that itself defines conditions and executes actions in response to events. missing for 10: native trigger/rule syntax, conditional action execution inside CockroachDB, documented automation examples beyond raw change-event streaming.

   • [claimed-docs] “CockroachDB changefeeds have an at-least-once delivery guarantee as well as message ordering guarantees.”

   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

   CockroachDB—none0/10

   The evidence pack covers backups, restore, changefeeds, MCP connectivity, and cluster management, but nothing describes a scheduling mechanism for recurring jobs or workflows (e.g., cron-like scheduled SQL/backup jobs) that an AI-native user could invoke. Since database products plausibly could offer such scheduling (e.g., scheduled backups), the axis applies, but no evidence documents it here.

   ⚑ 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

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

   CockroachDB—none0/10

   The evidence pack covers CockroachDB's backup/restore and point-in-time restore features but contains no mention of a 'branch' concept, branch creation, or resetting a branch from its parent — capabilities central to this story. Since database branching is a reasonable feature category for a modern SQL database to offer, its total absence here means the story is unmet rather than out-of-category.

   • [claimed-docs] “You can create full or incremental backups of a , , or . Taking regular backups of your data is an operational best practice.”
   • [claimed-docs] “A restore from an arbitrary point in time within the revision history of a backup.”

   proof ↗⚑ 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

   CockroachDB—none0/10

   No evidence of a branching feature (e.g., copy-on-write database branches per PR) or CI/deploy-platform integration for automated branch creation/teardown; only unrelated capabilities like `cockroach demo` (ephemeral in-memory instance) and ccloud cluster creation are documented, neither of which supports per-PR branch lifecycle automation.

   • [claimed-docs] “The `cockroach demo` starts a temporary, in-memory CockroachDB cluster of one or more nodes, with or without a preloaded dataset, and opens …”
   • [claimed-docs] “The `ccloud` tool is a command-line interface (CLI) tool that allows you to create, manage, and connect to CockroachDB Cloud clusters.”
   • [claimed-docs] “install `ccloud` and use the `ccloud quickstart` command to interactively log in and create a new CockroachDB Serverless cluster.”

   proof ↗⚑ 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

   CockroachDB—none0/10

   No evidence of a copy-on-write branching feature for schema+data in CockroachDB; the pack only shows backups/restores, demo clusters, and single-node dev instances, none of which provide instant branchable copies of production 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

   CockroachDB—none0/10

   CockroachDB supports the standard PostgreSQL wire protocol via TCP connections and any Postgres driver, but there is no evidence of an official HTTP/WebSocket driver designed for stateless, short-lived serverless/edge function connections (unlike e.g. Neon's serverless driver). No documentation or product mentions this capability.

   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”
   • [community] “The wire protocol is compatible with Postgres, which allows re-using battle-tested Postgres clients. However it's a non-starter for my use c…”

   proof ↗⚑ flag

Latency

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

   weight 2 · round to CockroachDB
   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

   CockroachDB✓fullcommunity8/10

   CockroachDB's docs describe explicit multi-region primitives—survival goals and table locality—for placing data/replicas close to users to reduce latency, plus survives datacenter failures with minimal latency disruption, directly matching the story. Missing for 10: independent latency benchmarks confirming real-world regional read-latency improvements, and community comments (comm-2) note multi-region can be restricted under certain licensing tiers, which is a real-world caveat on availability of the feature.

   • [claimed-docs] “_Survival goal_ dictates how many simultaneous failure(s) a database can survive.”
   • [claimed-docs] “_Table locality_ determines how CockroachDB optimizes access to a table's data.”
   • [claimed-docs] “_Table locality_ determines how CockroachDB optimizes access to a table’s data.”
   • [claimed-docs] “survives** disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention”
   • [claimed-docs] “survives disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention; supports strongly-con…”
   • [community] “For me it was the multiple regions. It's like.. with that disabled why are we even here? Data residency is the whole point...”

   proof ↗⚑ 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

   CockroachDB—none0/10

   The evidence pack shows CockroachDB supports the Postgres wire protocol and various client drivers, but nowhere documents a built-in connection pooler (equivalent to pgbouncer) that manages thousands of concurrent client connections. No mention of connection pooling, session multiplexing, or proxy-replacement architecture appears in any docs, community, or probe items.

   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”
   • [claimed-docs] “CockroachDB is a cloud-agnostic, PostgreSQL compatible database built for modern applications”

   proof ↗⚑ 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

   CockroachDB✓fullclaimed7/10

   CockroachDB documents a native VECTOR type and vector indexes supporting efficient approximate nearest neighbor (ANN) search on high-dimensional columns, compatible with the pgvector extension, meaning developers can store embeddings and run similarity search directly in CockroachDB without a separate vector DB. Missing for 10: hands-on/independent corroboration of vector search performance or real-world usage reports, and no community discussion validating this feature in practice.

   • [claimed-docs] “A _vector index_ enables efficient approximate nearest neighbor (ANN) search on high-dimensional columns.”
   • [claimed-docs] “`VECTOR` functionality is compatible with the [`pgvector`](https://github.com/pgvector/pgvector) extension for PostgreSQL.”

   proof ↗⚑ flag

Analytics

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

   weight 2 · round drawn
   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

   CockroachDB—none0/10

   The evidence pack covers CockroachDB's OLTP features (ACID transactions, backups, changefeeds, multi-region, vector indexes) but contains no mention of analytical/OLAP acceleration, columnar execution, materialized views, or benchmarks showing fast large-table aggregation performance suitable for dashboards. Nothing addresses avoiding a separate warehouse for analytics. missing for 10: any documentation of analytical query performance, columnar/vectorized execution engine, dashboard-scale aggregation benchmarks, or HTAP-specific tooling.

   ⚑ 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 CockroachDB
   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

   CockroachDB!disputedcontradicted5/10

   CockroachDB documents and demonstrates real PostgreSQL wire-protocol compatibility (standard pg drivers work, `cockroach demo` runs actual SQL round-trips) rather than a toy subset, but hands-on community reports concretely contradict 'full' Postgres compatibility — e.g. missing array columns ('it lacks array columns, which Postgres supports') and, historically, missing change-notification/CDC — meaning code written against real Postgres dialect features can break. There is no MySQL or SQLite dialect compatibility at all, only Postgres. Missing for 10: MySQL/SQLite compatibility, resolution of the array-column and other documented Postgres feature gaps, and independent verification that these gaps are now closed.

   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”
   • [claimed-docs] “CockroachDB is a cloud-agnostic, PostgreSQL compatible database built for modern applications”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”
   • [community] “The wire protocol is compatible with Postgres, which allows re-using battle-tested Postgres clients. However it's a non-starter for my use c…”
   • [community] “It looks like there is still no mechanism for change notification, which in our particular case is the only missing feature that prevents us…”

   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

   CockroachDB✓fullprobed8/10

   The `cockroach` CLI covers the daily loop: `cockroach demo`/`cockroach start-single-node` create and connect to a cluster with an interactive SQL shell, verified hands-on via runtime probes showing a keyless install and real SQL roundtrip entirely offline. Docs and probes confirm install (brew), demo/shell, and Postgres-wire-protocol connectivity for inspection via any SQL client. Missing for 10: independent (non-vendor) third-party validation of the full CLI daily loop beyond the single runtime probe, and explicit CLI subcommand documentation for 'inspect' beyond SQL shell usage.

   • [claimed-docs] “The `cockroach demo` starts a temporary, in-memory CockroachDB cluster of one or more nodes, with or without a preloaded dataset, and opens …”
   • [claimed-docs] “A single-node cluster is appropriate for quick SQL testing or app development.”
   • [claimed-docs] “Instruct Homebrew to install CockroachDB: $ brew install cockroachdb/tap/cockroach”
   • [probe] “official CLI documented at https://docs.cockroachlabs.com/docs/stable/cockroach-demo”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach version` printed `Build Tag: v26.3.1` keylessly after `brew install cockroachdb/tap/cockroac…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”

   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

   CockroachDB✓fullprobed9/10

   CockroachDB ships as a downloadable binary (brew install) and `cockroach demo`/single-node start modes that spin up a full in-memory or local cluster with an interactive SQL shell, requiring no account, license key entry, or cloud dependency; a runtime probe confirms a keyless offline SQL roundtrip actually executed. This directly satisfies local/offline dev and CI use since the same open-source engine runs identically to production. missing for 10: explicit first-party documentation or example of wiring `cockroach demo`/single-node mode into a CI pipeline, and independent (non-vendor) confirmation of CI usage.

   • [claimed-docs] “The `cockroach demo` starts a temporary, in-memory CockroachDB cluster of one or more nodes, with or without a preloaded dataset, and opens …”
   • [claimed-docs] “A single-node cluster is appropriate for quick SQL testing or app development.”
   • [claimed-docs] “Instruct Homebrew to install CockroachDB: $ brew install cockroachdb/tap/cockroach”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach version` printed `Build Tag: v26.3.1` keylessly after `brew install cockroachdb/tap/cockroac…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”

   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 to CockroachDB
   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

   CockroachDB~partialcommunity3/10

   CockroachDB advertises PostgreSQL wire-protocol compatibility, implying general compatibility with Postgres-based ORMs/drivers, but the evidence pack contains no documented, ORM-specific guides (Prisma, Drizzle, Django, Rails) and one community report notes incompatibilities (missing array columns) that break real-world Postgres-client usage. missing for 10: dedicated official guides for Prisma, Drizzle, Django, and Rails integration, and confirmation that ORM-specific features work without workarounds.

   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”
   • [community] “The wire protocol is compatible with Postgres, which allows re-using battle-tested Postgres clients. However it's a non-starter for my use c…”

   proof ↗⚑ flag

Migrations

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

   weight 1 · round to Turso
   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

   CockroachDB~partialclaimed3/10

   The docs index references a dedicated 'Migrate' / migration-overview page (MOLT) suggesting a documented migration path exists, but the evidence pack contains no actual content describing minimal-downtime steps, replication/cutover tooling, or verified success stories. Missing for 10: detailed migration guide content, explanation of minimal-downtime mechanics (e.g., live migration/replication tooling), and independent/hands-on confirmation of a low-downtime cutover.

   • [claimed-docs] “Migrate ](/docs/molt/migration-overview)”

   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

   CockroachDB—none0/10

   The evidence pack contains no mention of online DDL, schema-change safety, migration tooling, or branch/merge workflows for schema changes — topics like backups, changefeeds, multiregion survival, and MCP/CLI tools are covered but schema migration safety is entirely absent. Missing for 10: any documentation or community evidence of online/non-blocking schema changes, migration CLI/tooling, or safe rollout mechanisms for DDL.

   ⚑ flag

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

   weight 2 · round to Turso
   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

   CockroachDB~partialprobed5/10

   CockroachDB exposes core capabilities via SQL (Postgres wire protocol), a CLI (`ccloud`) for cluster creation/management, and an MCP server for natural-language read/write operations, giving API-level parity for data operations and basic cluster admin. However the evidence pack shows Cloud Console-specific features (cost estimation, resource-usage dashboards, cluster overview page) documented only as UI pages with no confirmed API/CLI equivalent, and no general REST/OpenAPI surface was found (probe for openapi.json returned 404s). Missing for 10: documented Cloud API/REST parity for console-only features like billing/cost estimates and resource monitoring, and confirmation that all UI actions are scriptable via API.

   • [claimed-docs] “The `ccloud` tool is a command-line interface (CLI) tool that allows you to create, manage, and connect to CockroachDB Cloud clusters.”
   • [claimed-docs] “install `ccloud` and use the `ccloud quickstart` command to interactively log in and create a new CockroachDB Serverless cluster.”
   • [claimed-docs] “A user can interact with their clusters using natural language prompts to perform read and write operations such as listing tables, executin…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the managed MCP server https://cockroachlabs.cloud/mcp returned HTT…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.cockroachlabs.com/openapi.json, https://docs.cockroachlabs.com/swagger.json, https://do…”
   • [claimed-docs] “The monthly cost estimate is calculated using simple extrapolation that assumes your workload during the selected time frame is an accurate …”
   • [claimed-docs] “The **Clusters** page provides a high-level view of your clusters.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   CockroachDB!disputedcontradicted4/10

   CockroachDB docs describe full/incremental backup and restore plus PostgreSQL wire-protocol compatibility, which could support exporting data in open, portable formats, but community hands-on reports state the backup/restore feature (needed to actually get data out) was 'locked behind their enterprise version' for non-paying users, directly undercutting a free, no-strings ability to export and leave. Additional community feedback notes real PostgreSQL-compatibility gaps (e.g., no array columns) limiting true open-format portability. Missing for 10: a documented open/standard export format (e.g., SQL dump, CSV) freely available without enterprise licensing, and confirmation that exports are usable outside CockroachDB without vendor lock-in.

   • [claimed-docs] “You can create full or incremental backups of a , , or . Taking regular backups of your data is an operational best practice.”
   • [claimed-docs] “A restore from an arbitrary point in time within the revision history of a backup.”
   • [community] “I love cockroachdb to death, but the key features that prevent me from using it in any real projects I'm doing are the backup/restore featur…”
   • [community] “The wire protocol is compatible with Postgres, which allows re-using battle-tested Postgres clients. However it's a non-starter for my use c…”
   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   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

   CockroachDB!disputedcontradicted4/10

   CockroachDB's source is published on GitHub (cockroachdb-gh-1), which superficially satisfies 'read the source', but community evidence indicates the licensing model is restrictive rather than a clean open license — users report needing an annual license key even as free users and enterprise features gated behind licensing (cockroachdb-comm-4, cockroachdb-comm-1, cockroachdb-comm-8). This contradicts a straightforward 'open license' claim. Missing for 10: explicit license text/OSI-approval evidence, confirmation that ALL source (not just visible code) is under a recognized open-source license, and resolution of the license-key requirement contradiction.

   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”
   • [community] “I do love Cockroach, but the old licensing model was pretty brutal if you required any enterprise features (ex: incremental backup).”
   • [community] “I don't like the fact that even free users need an annual license key.”
   • [community] “I love cockroachdb to death, but the key features that prevent me from using it in any real projects I'm doing are the backup/restore featur…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to CockroachDB
   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

   CockroachDB✓fullprobed9/10

   CockroachDB core is open-source and can be installed and run entirely locally without any cloud account, verified by runtime probes showing brew install and cockroach demo/single-node clusters running full SQL workloads offline and keylessly. Docs also describe single-node and multi-node self-hosted deployment options. missing for 10: independent third-party confirmation of full multi-node self-hosted cluster beyond demo mode, and clarity on which enterprise features require licensing when self-hosted (per community complaints about backup/CDC being enterprise-gated).

   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach version` printed `Build Tag: v26.3.1` keylessly after `brew install cockroachdb/tap/cockroac…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”
   • [claimed-docs] “A single-node cluster is appropriate for quick SQL testing or app development.”
   • [claimed-docs] “Instruct Homebrew to install CockroachDB: $ brew install cockroachdb/tap/cockroach”
   • [claimed-docs] “The `cockroach demo` starts a temporary, in-memory CockroachDB cluster of one or more nodes, with or without a preloaded dataset, and opens …”

   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 CockroachDB
   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

   CockroachDB~partialclaimed3/10

   CockroachDB Cloud provides Request Unit usage monitoring and a monthly cost estimate/extrapolation tool, plus a 'diagnose and optimize resource consumption' guide, giving founders some visibility into spend before a bill arrives. However, there is no evidence of an actual configurable spend cap or proactive usage alert/notification mechanism (e.g., budget thresholds that trigger emails or auto-throttling) — the pack only shows passive dashboards and estimates. Missing for 10: documented spend-cap/budget-limit feature, documented usage-threshold alerting/notifications, and any hands-on confirmation these prevent runaway bills.

   • [claimed-docs] “The monthly cost estimate is calculated using simple extrapolation that assumes your workload during the selected time frame is an accurate …”
   • [claimed-docs] “Diagnose and optimize your resource consumption explains how to find and optimize queries and processes that may be consuming excessive reso…”
   • [claimed-docs] “You can review how many request units your cluster has used on the .”
   • [claimed-docs] “Request Unit consumption scales to zero when your cluster has no activity.”

   proof ↗⚑ flag

Insights

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

   weight 2 · round to CockroachDB
   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

   CockroachDB~partialclaimed3/10

   Docs reference a resource-usage page that helps 'find and optimize queries and processes that may be consuming excessive resources' and a Clusters overview page, hinting at some performance monitoring, but there's no evidence of a dedicated built-in insights view naming slow queries or explicit index recommendations. Missing for 10: documentation of a specific 'Insights' or performance-insights UI, evidence of index recommendation output, and independent/hands-on confirmation of these features actually surfacing in the console.

   • [claimed-docs] “Diagnose and optimize your resource consumption explains how to find and optimize queries and processes that may be consuming excessive reso…”
   • [claimed-docs] “The **Clusters** page provides a high-level view of your clusters.”

   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

   CockroachDB!disputedcontradicted5/10

   CockroachDB offers a genuinely free local path (open-source binary, `cockroach demo` running real SQL with no account per probe-rt-1/rt-2) plus a Cloud free trial with $400 credit and serverless scale-to-zero billing (docs-8, docs-25, docs-18), which supports real prototyping. However, community reports concretely contradict full 'free tier usability' — free/core users still need an annual license key, and key features prototypers would want (incremental backup/restore, CDC, follower-reads) are locked behind the paid Enterprise tier, pushing some users back to Postgres (comm-4, comm-8, comm-9). missing for 10: evidence that backup/restore, CDC, and other blocked features are truly available for free, and confirmation the license-key requirement doesn't undermine 'free' framing.

   • [claimed-docs] “This page shows you how to use free trial credits to deploy a CockroachDB cluster on CockroachDB Standard and use sample code to run your fi…”
   • [claimed-docs] “it will be credited with $400 in to get you started”
   • [claimed-docs] “Request Unit consumption scales to zero when your cluster has no activity.”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach version` printed `Build Tag: v26.3.1` keylessly after `brew install cockroachdb/tap/cockroac…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”
   • [community] “I don't like the fact that even free users need an annual license key.”
   • [community] “I love cockroachdb to death, but the key features that prevent me from using it in any real projects I'm doing are the backup/restore featur…”
   • [community] “I stopped using them when they released Follower-Reads as an enterprise feature. I'm back to Postgres for now.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   CockroachDB—none0/10

   Evidence shows CockroachDB Cloud tracks Request Unit usage and provides a monthly cost *estimate* tool, plus free trial credits, but no evidence pack item publishes actual per-unit dollar rates for compute, storage, or traffic that a founder could use to predict a bill in advance. Community comments even highlight surprise/confusion about cost (e.g., being quoted 10x pricier than alternatives), suggesting pricing isn't transparently published upfront.

   • [claimed-docs] “The monthly cost estimate is calculated using simple extrapolation that assumes your workload during the selected time frame is an accurate …”
   • [claimed-docs] “Request Unit consumption scales to zero when your cluster has no activity.”
   • [claimed-docs] “You can review how many request units your cluster has used on the .”
   • [community] “Spanner is cheap in comparison depending on your storage requirements. I've seen CockroachDB quoted as 10x more, and for a product that is h…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   CockroachDB~partialcommunity6/10

   CockroachDB's multi-region docs (survival goals, table locality) explicitly let you place data by region, which is what data residency requires — but community reports (comm-2) note that region/residency-only features have at times been gated to enterprise/paid tiers, adding a real caveat that data residency 'is the whole point' but can be restricted depending on license/tier. Missing for 10: independent/hands-on confirmation of granular region pinning in practice, and clarity on which specific product tier includes full multi-region/residency controls.

   • [claimed-docs] “_Survival goal_ dictates how many simultaneous failure(s) a database can survive.”
   • [claimed-docs] “_Table locality_ determines how CockroachDB optimizes access to a table's data.”
   • [claimed-docs] “_Table locality_ determines how CockroachDB optimizes access to a table’s data.”
   • [community] “For me it was the multiple regions. It's like.. with that disabled why are we even here? Data residency is the whole point...”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Turso—none0/10

   The evidence pack contains no policy statement, terms-of-service excerpt, or documentation addressing whether Turso uses customer database content to train AI models — despite Turso being a data-storage platform with AI-agent integrations (MCP) where such a privacy assurance would be a reasonable buyer question. No mention of data-training opt-out, model-training exclusion, or similar privacy commitment appears anywhere in the docs, pricing, or community evidence.

   ⚑ flag

   CockroachDB—none0/10

   The evidence pack contains no mention of any AI-model-training opt-out, data-usage policy, or privacy commitment regarding customer data being used to train AI models. CockroachDB Cloud does handle customer data and has AI-adjacent features (natural-language MCP interface), so the axis is a fair question for the product, but no documentation or community evidence addresses this specific privacy control. missing for 10: any documented policy on AI-training data usage, opt-out mechanism, or explicit privacy statement about model training.

   ⚑ flag

3. 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

   CockroachDB~partialclaimed4/10

   Evidence shows backup/restore and point-in-time restore capabilities (cockroachdb-docs-6, cockroachdb-docs-15), and standard SQL access via Postgres wire protocol implies DELETE/DROP support (cockroachdb-gh-1), but there is no explicit documentation in this pack of retention policies, row-level TTL, or data deletion/purge controls tailored for AI-native privacy needs. missing for 10: explicit TTL/retention-policy docs, GDPR-style delete-on-request tooling, data lifecycle management guidance.

   • [claimed-docs] “You can create full or incremental backups of a , , or . Taking regular backups of your data is an operational best practice.”
   • [claimed-docs] “A restore from an arbitrary point in time within the revision history of a backup.”
   • [github] “CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers to connect from various languages.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Turso—none0/10

   No evidence pack item addresses telemetry, analytics, or usage-tracking opt-out settings for Turso's CLI, SDKs, or cloud platform — the question is a fair one for a developer tool/CLI product but nothing in docs, pricing, or community discussion confirms or denies a telemetry opt-out mechanism.

   ⚑ flag

   CockroachDB—none0/10

   No evidence in the pack shows a documented telemetry opt-out mechanism; instead, community feedback explicitly states the telemetry is mandatory ('the only thing I don't like is the mandatory telemetry'), indicating no user-facing opt-out exists.

   • [community] “The only thing I don't like is the mandatory telemetry.”

   proof ↗⚑ flag

Availability

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

   weight 2 · round to CockroachDB
   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

   CockroachDB~partialcommunity6/10

   CockroachDB's docs clearly document automatic replication and failover: it 'survives disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention,' with configurable multi-region survival goals and table locality, which functions as its answer to read-replica/HA needs. However, CockroachDB is architecturally a distributed consensus database rather than a primary/read-replica system, and community reports note that follower-reads (the closest analog to 'read replicas' for read scaling) were moved behind an enterprise license, which a platform engineer would need to navigate. Missing for 10: explicit 'read replica' terminology/setup guide, independent verification of failover behavior in production, and clarity on which HA/read-scaling features require paid tiers.

   • [claimed-docs] “survives** disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention”
   • [claimed-docs] “survives disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention; supports strongly-con…”
   • [claimed-docs] “_Survival goal_ dictates how many simultaneous failure(s) a database can survive.”
   • [claimed-docs] “_Table locality_ determines how CockroachDB optimizes access to a table's data.”
   • [community] “I stopped using them when they released Follower-Reads as an enterprise feature. I'm back to Postgres for now.”

   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

   CockroachDB!disputedcontradicted4/10

   Docs describe full/incremental backups and point-in-time restore as available features (cockroachdb-docs-6, cockroachdb-docs-15), but there's no evidence of a visible/configurable backup schedule UI or self-serve founder-facing controls, and community reports concretely contradict self-serve availability: 'backup/restore feature... is currently locked behind their enterprise version' and 'the old licensing model was pretty brutal if you required any enterprise features (ex: incremental backup)' — meaning for a founder on the free/core tier, backups may not be truly self-serve or automatic. Missing for 10: evidence of a schedule visibility/config UI, confirmation that free-tier founders get automatic scheduled backups without enterprise licensing, and independent hands-on confirmation of restore self-service.

   • [claimed-docs] “You can create full or incremental backups of a , , or . Taking regular backups of your data is an operational best practice.”
   • [claimed-docs] “A restore from an arbitrary point in time within the revision history of a backup.”
   • [community] “I love cockroachdb to death, but the key features that prevent me from using it in any real projects I'm doing are the backup/restore featur…”
   • [community] “I do love Cockroach, but the old licensing model was pretty brutal if you required any enterprise features (ex: incremental backup).”

   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

   CockroachDB~partialcommunity6/10

   Docs confirm full/incremental backups with revision history enabling restore to an arbitrary point in time within the backup window (docs-6, docs-15), directly matching the 'restore to any point in time' part of the story. However, there is no evidence of a database-branching capability (e.g., cloning a live copy at a timestamp for testing), and community reports note that backup/restore (and other reliability features) are gated behind enterprise licensing, adding a real cost/access caveat (comm-8, comm-1). Missing for 10: evidence of branching/cloning functionality, and confirmation that PITR restore is available outside enterprise tier.

   • [claimed-docs] “You can create full or incremental backups of a , , or . Taking regular backups of your data is an operational best practice.”
   • [claimed-docs] “A restore from an arbitrary point in time within the revision history of a backup.”
   • [community] “I love cockroachdb to death, but the key features that prevent me from using it in any real projects I'm doing are the backup/restore featur…”
   • [community] “I do love Cockroach, but the old licensing model was pretty brutal if you required any enterprise features (ex: incremental backup).”

   proof ↗⚑ flag

Elasticity

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

   weight 2 · round to CockroachDB
   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

   CockroachDB~partialclaimed5/10

   CockroachDB Cloud's Serverless/Basic tier documents automatic request-unit scaling, including scale-to-zero on inactivity, which aligns with autoscaling compute without manual resizing. However, evidence is thin on how it scales up under load or guarantees against downtime, and CockroachDB's core distributed architecture (self-hosted) generally requires manual node provisioning for scaling, so this capability is specific to the managed cloud tier only. missing for 10: detailed scale-up mechanics/limits, evidence of zero-downtime during scale events, independent/hands-on confirmation of autoscaling behavior under real load.

   • [claimed-docs] “Request Unit consumption scales to zero when your cluster has no activity.”
   • [claimed-docs] “You can review how many request units your cluster has used on the .”
   • [claimed-docs] “The monthly cost estimate is calculated using simple extrapolation that assumes your workload during the selected time frame is an accurate …”
   • [claimed-docs] “The **Clusters** page provides a high-level view of your clusters.”

   proof ↗⚑ flag

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

   weight 3 · round to CockroachDB
   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

   CockroachDB✓fullclaimed7/10

   CockroachDB Cloud's Serverless/Basic tier explicitly scales Request Unit consumption to zero when idle, while data remains durably stored and billed only for storage, directly matching the story of a free-when-idle prototype database. Docs also show a $400 free trial credit and cluster management dashboards for tracking usage, reinforcing the cost-to-zero model for founders/side projects. Missing for 10: independent/hands-on confirmation of actual $0 billing behavior during idle periods, and no community reports validating the scale-to-zero claim in practice (only docs-level evidence).

   • [claimed-docs] “Request Unit consumption scales to zero when your cluster has no activity.”
   • [claimed-docs] “You can review how many request units your cluster has used on the .”
   • [claimed-docs] “This page shows you how to use free trial credits to deploy a CockroachDB cluster on CockroachDB Standard and use sample code to run your fi…”
   • [claimed-docs] “it will be credited with $400 in to get you started”
   • [claimed-docs] “The monthly cost estimate is calculated using simple extrapolation that assumes your workload during the selected time frame is an accurate …”

   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

   CockroachDB✓fullprobed7/10

   CockroachDB ships both `cockroach demo` (verified live in a runtime probe to instantly spin up a keyless in-memory cluster with real SQL roundtrip) and the `ccloud quickstart` CLI which interactively creates a CockroachDB Serverless/Basic cluster with request-unit billing that scales to zero, removing the need for capacity planning. Docs also describe a free-trial quickstart flow for going from zero to a connected cluster in seconds via CLI. missing for 10: no runtime probe verifying the cloud `ccloud quickstart` actually provisions a ready-to-connect serverless cluster (only local `cockroach demo` was runtime-tested), and no first-class REST/API path for cluster creation beyond the CLI is evidenced.

   • [claimed-docs] “install `ccloud` and use the `ccloud quickstart` command to interactively log in and create a new CockroachDB Serverless cluster.”
   • [claimed-docs] “Request Unit consumption scales to zero when your cluster has no activity.”
   • [claimed-docs] “The `ccloud` tool is a command-line interface (CLI) tool that allows you to create, manage, and connect to CockroachDB Cloud clusters.”
   • [claimed-docs] “This page shows you how to use free trial credits to deploy a CockroachDB cluster on CockroachDB Standard and use sample code to run your fi…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `cockroach demo --no-example-database --insecure=true -e ...` booted a keyless in-memory single-node cl…”
   • [claimed-docs] “A single-node cluster is appropriate for quick SQL testing or app development.”

   proof ↗⚑ flag