Neon vs Turso

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 drawn
   Neon✓fullprobed8/10

   Neon documents a full API (openapi.json, Neon API docs), an official CLI (neon-docs-11/34, confirmed runnable keylessly via npx per probe), and an official MCP server (neon-docs-12/33, confirmed live and functioning with OAuth per probe), covering project/database creation, connection string retrieval, and SQL execution — enabling end-to-end agent-driven provisioning without the dashboard. Missing for 10: no hands-on independent third-party account of a full agent-driven create→connect→schema→query workflow end-to-end via MCP/CLI, only first-party docs and isolated runtime probes.

   • [claimed-docs] “Neon CLI”
   • [claimed-docs] “Neon MCP Server overview”
   • [claimed-docs] “Neon API”
   • [probe] “PROBE openapi: HTTP 200 at https://neon.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://neon.com/docs/ai/neon-mcp-server”
   • [probe] “official CLI documented at https://neon.com/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Neon CLI ran keylessly from npm — `npx -y neon@latest --version` printed `4.14.1` with no …”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.neon.tech/mcp returned HTTP 401 w…”

   proof ↗⚑ flag

   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

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 Neon
   Neon~partialprobed6/10

   Neon ships an official MCP Server (docs + live runtime probe confirming the hosted endpoint) and CLI that let agents run SQL/schema operations against Neon Postgres, and the MCP server docs likely expose scoped tools (e.g., run_sql, list_projects, migrations) though the evidence pack doesn't detail a read-only vs destructive tool permission split. missing for 10: explicit documentation of separate read-only vs destructive tool scopes/permissions within the MCP server, independent hands-on confirmation of safe-delegation behavior, and evidence of confirmation/guardrails for destructive actions.

   • [claimed-docs] “Neon MCP Server overview”
   • [claimed-docs] “Neon MCP Server overview - Neon Docs”
   • [probe] “official MCP server documented at https://neon.com/docs/ai/neon-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.neon.tech/mcp returned HTTP 401 w…”
   • [claimed-docs] “Neon CLI”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Neon CLI ran keylessly from npm — `npx -y neon@latest --version` printed `4.14.1` with no …”

   proof ↗⚑ flag

   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

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
   Neon~partialcommunity6/10

   Neon documents programmatic fleet management via its API/CLI and instant, cheap branching (branch-per-tenant/agent pattern), plus a 'claimable database integration' workflow for spinning up isolated DBs on demand, and scale-to-zero to keep idle databases cheap. However, the pricing page caps at '100 projects' (neon-docs-6), and there is no direct evidence of managing 'thousands' of isolated databases or of per-agent isolation specifically validated at that scale — missing for 10: documented support/pricing for thousands of projects/branches, hands-on evidence of bulk automated provisioning at scale, and confirmation that the 100-project cap doesn't bottleneck a thousands-scale fleet.

   • [claimed-docs] “Branching - Neon Docs”
   • [claimed-docs] “Claimable database integration guide”
   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon CLI”
   • [claimed-docs] “Scale to Zero”
   • [claimed-docs] “100 projects”
   • [community] “Nice work Neon! I've used it a number of times and am impressed at how quickly databases become available. Leaps and bounds faster than RDS.…”
   • [community] “We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and per…”

   proof ↗⚑ flag

   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

Agent access

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

   weight 2 · round drawn
   Neon✓fullprobed9/10

   Neon has a live llms.txt (HTTP 200, structured markdown index) and a machine-readable docs.md summary page, both directly verified via probes, confirming agent-oriented documentation an AI agent can consume. Missing for 10: no independent/community confirmation of an agent actually using llms.txt successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://neon.com/llms.txt # Neon Postgres > Neon is a complete set of cloud backend primitives built around Lak…”
   • [probe] “PROBE docs-md: HTTP 200 at https://neon.com/docs/introduction.md > Full Neon documentation index: https://neon.com/docs/llms.txt > Summary:…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Turso
   Neon✓fullprobed7/10

   Neon ships a documented CLI and REST API usable non-interactively (API-key auth), plus a GitHub Actions integration for branch-per-PR workflows, and a runtime probe confirms the CLI can be invoked keylessly via npx (`npx -y neon@latest --version`), supporting scripted/CI use. Missing for 10: explicit CI/GitHub Actions workflow YAML examples in the evidence pack and a probe showing authenticated (API-key) command execution in a pipeline context.

   • [claimed-docs] “Neon CLI”
   • [claimed-docs] “Neon CLI - Neon Docs”
   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon API - Neon Docs”
   • [claimed-docs] “The Neon GitHub integration”
   • [claimed-docs] “The Neon GitHub integration - Neon Docs”
   • [probe] “official CLI documented at https://neon.com/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Neon CLI ran keylessly from npm — `npx -y neon@latest --version` printed `4.14.1` with no …”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Neon✓fullprobed8/10

   Neon publishes an official MCP server, documented at neon.com/docs/ai/neon-mcp-server, and a runtime probe confirms the hosted endpoint (mcp.neon.tech/mcp) is live and correctly implements the MCP OAuth handshake. Missing for 10: independent/community hands-on reports of an agent successfully using the MCP server in production workflows.

   • [claimed-docs] “Neon MCP Server overview”
   • [claimed-docs] “Neon MCP Server overview - Neon Docs”
   • [probe] “official MCP server documented at https://neon.com/docs/ai/neon-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.neon.tech/mcp returned HTTP 401 w…”

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Neon✓fullprobed9/10

   Neon documents and ships an official CLI (neon/neonctl), confirmed both in docs and a hands-on runtime probe showing `npx neon@latest --version` working keylessly. Missing for 10: independent community commentary specifically evaluating the CLI's AI-native workflows/UX.

   • [claimed-docs] “Neon CLI”
   • [claimed-docs] “Neon CLI - Neon Docs”
   • [probe] “official CLI documented at https://neon.com/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Neon CLI ran keylessly from npm — `npx -y neon@latest --version` printed `4.14.1` with no …”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Neon
   Neon✓fullprobed9/10

   Neon publishes a documented public REST API (neon-docs-20/38) backed by a live OpenAPI spec (neon-probe-3), plus an llms.txt and docs.md tailored for AI agents (neon-probe-1, neon-probe-2), enabling programmatic control of projects, branches, etc. Missing for 10: independent hands-on verification of API usage beyond probes and richer coverage of API scopes/rate limits.

   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon API - Neon Docs”
   • [probe] “PROBE openapi: HTTP 200 at https://neon.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://neon.com/llms.txt # Neon Postgres > Neon is a complete set of cloud backend primitives built around Lak…”
   • [probe] “PROBE docs-md: HTTP 200 at https://neon.com/docs/introduction.md > Full Neon documentation index: https://neon.com/docs/llms.txt > Summary:…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Turso
   Neon~partialprobed4/10

   Neon's hosted MCP server enforces an OAuth-protected-resource flow (401 + WWW-Authenticate + resource_metadata) rather than handing over a full-account API key, and the 'Claimable database integration' guide suggests a mechanism for issuing scoped, per-project credentials to external/agent consumers. However, there is no explicit documentation of configurable least-privilege scopes (e.g., read-only, project-limited API keys) for general API/agent use beyond the MCP OAuth flow. Missing for 10: explicit docs on granular API-key scoping/roles, examples of issuing a restricted key specifically for an agent, and independent confirmation that the MCP OAuth tokens are least-privilege rather than full-account.

   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.neon.tech/mcp returned HTTP 401 w…”
   • [claimed-docs] “Claimable database integration guide”
   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon MCP Server overview - Neon Docs”

   proof ↗⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Turso
   Neon~partialprobed6/10

   Neon documents an official serverless driver (JS/TS) and a full REST API with a published OpenAPI spec, plus a CLI and MCP server for programmatic/agentic access, giving AI-native builders official tooling to integrate against. Missing for 10: multi-language official SDKs beyond the JS serverless driver, and independent/hands-on validation of SDK ergonomics or completeness.

   • [claimed-docs] “Neon serverless driver”
   • [claimed-docs] “Neon API”
   • [probe] “PROBE openapi: HTTP 200 at https://neon.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Neon CLI”
   • [claimed-docs] “Neon MCP Server overview”

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Neon—none0/10

   No evidence of a webhooks subscription feature for Neon events (e.g., project/branch/compute state changes); Neon's API, CLI, and MCP server are documented but no webhook/event-subscription mechanism appears anywhere in the pack.

   ⚑ flag

   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

Agentic features

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

   weight 2 · round drawn
   Neon—none0/10

   Evidence shows Neon provides AI infrastructure (AI Gateway, pgvector, MCP server for agent access) but nothing about Neon itself analyzing a user's data and surfacing AI-generated insights or suggestions (e.g., query optimization tips, anomaly detection, usage recommendations). These are tools for building AI apps on top of Neon, not an in-product insight/suggestion feature.

   • [claimed-docs] “AI Gateway. All models, one API, one bill. Powered by Databricks.”
   • [claimed-docs] “The pgvector extension”
   • [claimed-docs] “Neon MCP Server overview - Neon Docs”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Turso
   Neon—none0/10

   Neon's evidence covers database infrastructure (branching, autoscaling, functions, MCP server, CLI) but nothing describes a scheduling/trigger/automation mechanism that lets an AI-native user configure work to run autonomously in the background without a live agent invoking it. Neon Functions and the MCP server enable agent-driven interactions, but no cron/trigger/webhook automation feature is documented.

   • [claimed-docs] “Functions. Long-running, without timeouts, and closer to your database.”
   • [claimed-docs] “Neon MCP Server overview”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.neon.tech/mcp returned HTTP 401 w…”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Neon—none0/10

   Evidence shows Neon offers an AI Gateway for routing to external AI models and an MCP server so external AI agents can control Neon, but there is no evidence of a built-in AI assistant inside the Neon console/product itself that users can delegate tasks to.

   • [claimed-docs] “AI Gateway. All models, one API, one bill. Powered by Databricks.”
   • [claimed-docs] “AI Gateway. All models, one API, one bill.”
   • [claimed-docs] “Neon MCP Server overview”
   • [claimed-docs] “Neon MCP Server overview - Neon Docs”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Turso
   Neon~partialprobed6/10

   Neon ships an official MCP server (hosted, live per runtime probe with OAuth flow) and a CLI, both of which let AI agents/natural-language tools operate the database (create branches, run queries, manage projects) via MCP tool calls rather than requiring raw SQL/API calls. This supports agentic/natural-language operation but the evidence doesn't show a first-party conversational NL interface (e.g., a chat UI translating plain English to SQL) beyond MCP-mediated tool use. missing for 10: no evidence of a native NL-to-SQL/chat interface distinct from MCP tool-calling, no independent/hands-on account of an agent successfully operating Neon end-to-end via natural language.

   • [claimed-docs] “Neon MCP Server overview - Neon Docs”
   • [claimed-docs] “Neon CLI - Neon Docs”
   • [probe] “official MCP server documented at https://neon.com/docs/ai/neon-mcp-server”
   • [probe] “official CLI documented at https://neon.com/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Neon CLI ran keylessly from npm — `npx -y neon@latest --version` printed `4.14.1` with no …”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.neon.tech/mcp returned HTTP 401 w…”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round drawn
   Neon—none0/10

   Neon has an API reference and OpenAPI spec (neon-docs-20/38, neon-probe-3), but no evidence describes an interactive, runnable-example experience (e.g., in-browser 'try it' consoles) for that API reference.

   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon API - Neon Docs”
   • [probe] “PROBE openapi: HTTP 200 at https://neon.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Neon
   Neon✓fullprobed9/10

   Neon publishes a live OpenAPI spec at https://neon.com/openapi.json (confirmed by probe returning HTTP 200 with an 'openapi' key), plus a documented reference API page, satisfying a machine-readable API spec download for AI-native tooling. Missing for 10: no independent/community corroboration of third-party consumption of the spec.

   • [probe] “PROBE openapi: HTTP 200 at https://neon.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon API - Neon Docs”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Neon✓fullcommunity8/10

   Neon's branching feature (instant copy-on-write branches of a Postgres database) is explicitly designed to let users spin up isolated environments to test changes without touching production data, and community users corroborate this exact workflow ('We can branch off the main database to test things out, and periodically reset the branch to its parent'). Docs on branching, instant restore, and claimable database integration further support safe, disposable test environments. missing for 10: independent hands-on verification of data isolation guarantees at scale, and explicit documentation of a dedicated 'sandbox' mode distinct from branching terminology.

   • [claimed-docs] “Branching - Neon Docs”
   • [community] “We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and per…”
   • [claimed-docs] “Instant restore”
   • [claimed-docs] “Claimable database integration guide”
   • [claimed-docs] “Lakebase Postgres. Serverless database that scales and branches with your app.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Neon—none0/10

   Evidence shows Neon has a documented REST API and OpenAPI spec (neon-docs-20, neon-probe-3), but nothing in the pack mentions API versioning scheme or a documented deprecation policy for breaking changes.

   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon API - Neon Docs”
   • [probe] “PROBE openapi: HTTP 200 at https://neon.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Turso
   Neon—none0/10

   Neon offers an API, CLI, and MCP server (neon-docs-20/34/33) that could in principle be scripted for bulk actions, but no evidence pack item documents batch/bulk endpoints, bulk branch/project creation, or any explicit bulk-operation capability across many items at once.

   ⚑ flag

   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

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

   weight 3 · round drawn
   Neon—none0/10

   No evidence of Neon supporting event-driven rule/action automation (e.g., webhooks, triggers-as-a-service, or rule engines) is present; the evidence pack covers branching, scaling, Functions, storage, and MCP/CLI tooling but nothing about defining automatic rule-based triggers on events.

   ⚑ flag

   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

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Neon—none0/10

   No evidence that Neon offers scheduled/recurring job or workflow capabilities (e.g., pg_cron support, cron-like triggers, or workflow scheduling); the evidence pack covers branching, scaling, storage, and connectivity but nothing about job scheduling.

   ⚑ flag

   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

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

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

   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

Branching

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

   weight 1 · round to Neon
   Neon✓fullcommunity9/10

   Neon's docs explicitly document 'Instant restore' for branches (branch-restore) and 'Branching' overview, and a community user confirms real-world usage: 'we branch off the main database to test things out, and periodically reset the branch to its parent.' This directly matches the story of resetting/restoring a branch without dump-based rebuilds. Missing for 10: no first-party CLI/API example walkthrough of the exact reset-to-parent command cited directly in the pack.

   • [claimed-docs] “Instant restore”
   • [claimed-docs] “Instant restore - Neon Docs”
   • [claimed-docs] “Branching - Neon Docs”
   • [community] “We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and per…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Neon
   Neon✓fullcommunity8/10

   Neon's branching is a first-class feature with docs, API, CLI, and GitHub integration explicitly designed for automated branch creation/teardown per PR (Neon API, Neon CLI, GitHub integration docs), and community evidence confirms real-world use of branching to test changes and reset to parent. Missing for 10: a concrete third-party CI/CD platform (e.g., Vercel preview or GitHub Actions) walkthrough or hands-on confirmation of automated PR-triggered teardown beyond docs/API existence.

   • [claimed-docs] “Branching - Neon Docs”
   • [claimed-docs] “The Neon GitHub integration”
   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon CLI”
   • [community] “We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and per…”

   proof ↗⚑ flag

   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

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 drawn
   Neon✓fullcommunity9/10

   Neon's core product feature is instant copy-on-write branching of Postgres databases including schema and data, documented explicitly in the branching docs, and corroborated by independent community usage describing branching off main to test and reset ('We can branch off the main database to test things out, and periodically reset the branch to its parent'). Instant restore and branch-based workflows are further documented, reinforcing the copy-on-write branch model used for dev/test against production-shaped data. Missing for 10: deeper hands-on verification of 'production-shaped data' fidelity at scale beyond a single community quote.

   • [claimed-docs] “Branching - Neon Docs”
   • [claimed-docs] “Instant restore”
   • [claimed-docs] “Lakebase Postgres. Serverless database that scales and branches with your app.”
   • [community] “We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and per…”

   proof ↗⚑ flag

   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

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 Neon
   Neon✓fullclaimed9/10

   Neon documents an official serverless driver ([neon-docs-14]/[neon-docs-31]) purpose-built for querying over HTTP or WebSockets, designed for serverless/edge environments with short-lived connections, and complements it with documented connection pooling ([neon-docs-13]/[neon-docs-30]) and scale-to-zero behavior. missing for 10: independent hands-on benchmarking or third-party validation of the HTTP/WebSocket driver specifically (community evidence covers general Neon experience but not this driver directly).

   • [claimed-docs] “Neon serverless driver”
   • [claimed-docs] “Neon serverless driver - Neon Docs”
   • [claimed-docs] “Connection pooling”
   • [claimed-docs] “Connection pooling - Neon Docs”
   • [claimed-docs] “Scale to Zero”

   proof ↗⚑ flag

   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

Latency

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

   weight 2 · round to Turso
   Neon~partialcommunity3/10

   Neon documents a 'Read Replicas' feature (neon-docs-16/28) which could in principle be used to place read copies closer to users, but the evidence pack contains no documentation of explicit region selection, multi-region deployment, or replica placement guidance, and community comments raise concerns about storage/compute separation adding latency (neon-comm-2, neon-comm-3). missing for 10: explicit docs on choosing/creating replicas in specific regions, guidance on multi-region latency optimization, and independent confirmation that cross-region replicas actually reduce latency.

   • [claimed-docs] “Neon Read Replicas”
   • [claimed-docs] “Neon Read Replicas - Neon Docs”
   • [community] “"We separated storage and compute" No. just no. Compute where the data lives, else you incur traffic cost and latency. A lesson learned in l…”
   • [community] “I am trying to understand how it works... the disk-backed storage here uses S3 which would introduce some severe latency... why would I run …”

   proof ↗⚑ flag

   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

Pooling

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

   weight 2 · round to Neon
   Neon✓fullclaimed8/10

   Neon documents a built-in connection pooler (PgBouncer-based) enabled via a dedicated pooled connection endpoint, described in official docs as a first-class feature (neon-docs-13/30), eliminating the need to operate a separate pgbouncer/proxy. missing for 10: independent hands-on benchmarks proving thousands-of-connections scale, and no community corroboration specifically about pooler behavior under load (community comments focus on branching/pricing/storage, not pooling).

   • [claimed-docs] “Connection pooling”
   • [claimed-docs] “Connection pooling - Neon Docs”

   proof ↗⚑ flag

   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

Ai data

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

   weight 2 · round drawn
   Neon✓fullclaimed8/10

   Neon documents native pgvector extension support, allowing embeddings storage and vector similarity search directly in Postgres without a separate vector DB (neon-docs-15/32). This is first-party docs only, without independent hands-on benchmarks of vector search performance. Missing for 10: independent/community validation of pgvector performance at scale on Neon, and details on index types (HNSW/IVFFlat) support depth.

   • [claimed-docs] “The pgvector extension”
   • [claimed-docs] “The pgvector extension - Neon Docs”

   proof ↗⚑ flag

   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

Analytics

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

   weight 2 · round drawn
   Neon—none0/10

   Neon is positioned as serverless Postgres with branching, autoscaling, read replicas, and connection pooling, but the evidence pack contains no mention of columnar storage, OLAP-optimized query engine, materialized views, or any benchmark showing fast large-table aggregation performance suitable for dashboards. Community commentary even raises concerns about storage/compute separation introducing latency, but this doesn't rise to a concrete contradiction of a specific claim—there's simply no claim to contradict.

   • [claimed-docs] “Neon Read Replicas”
   • [claimed-docs] “Autoscaling”
   • [claimed-docs] “Connection pooling”
   • [community] “"We separated storage and compute" No. just no. Compute where the data lives, else you incur traffic cost and latency. A lesson learned in l…”
   • [community] “I am trying to understand how it works... the disk-backed storage here uses S3 which would introduce some severe latency... why would I run …”

   proof ↗⚑ flag

   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

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 Neon
   Neon~partialcommunity6/10

   Neon is real Postgres (not a lookalike), evidenced by connecting via standard psql/dbeaver clients, support for extensions like pgvector, and community confirmation it's genuinely Postgres under the hood (used by Vercel). However, Neon only supports Postgres — no MySQL or SQLite dialect compatibility is offered or claimed, and some architectural differences (storage/compute separation, S3-backed storage) draw community pushback on whether behavior fully matches traditional Postgres performance expectations. missing for 10: MySQL/SQLite dialect support, exhaustive extension-compatibility list, independent verification that all Postgres extensions/behaviors work identically at scale.

   • [github] “connect to it with your preferred Postgres client (psql, dbeaver, etc) or use the online SQL Editor”
   • [github] “Neon is an open-source serverless Postgres database platform. It separates storage and compute”
   • [claimed-docs] “The pgvector extension”
   • [community] “I tried using supabase to back a vercel project. It was far too slow so we switched back to postgresql included with vercel. Turns out that …”
   • [community] “"We separated storage and compute" No. just no. Compute where the data lives, else you incur traffic cost and latency. A lesson learned in l…”
   • [community] “I am trying to understand how it works... the disk-backed storage here uses S3 which would introduce some severe latency... why would I run …”

   proof ↗⚑ flag

   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

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
   Neon✓fullprobed8/10

   Neon CLI is documented and runtime-verified to run keylessly, and Neon's docs describe CLI-based project/branch creation, connection strings, and SQL/psql-based inspection (neon-docs-11/34, neon-probe-5, neon-probe-rt-1, neon-gh-1). This covers create/connect/shell/inspect without the dashboard, though evidence doesn't show a single first-party walkthrough of the full daily loop end-to-end or independent hands-on review of CLI ergonomics. missing for 10: a documented end-to-end CLI workflow example combining create+connect+shell+inspect in one place, and independent/community validation of CLI usability.

   • [claimed-docs] “Neon CLI”
   • [claimed-docs] “Neon CLI - Neon Docs”
   • [probe] “official CLI documented at https://neon.com/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Neon CLI ran keylessly from npm — `npx -y neon@latest --version` printed `4.14.1` with no …”
   • [github] “connect to it with your preferred Postgres client (psql, dbeaver, etc) or use the online SQL Editor”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Turso
   Neon~partialclaimed6/10

   GitHub docs explicitly state Neon can be compiled and run locally/on a workstation for small experiments and to test code changes, supporting offline/CI use without cloud dependency, and the project is open-source so no account is inherently required. However, the flagship 'Neon Local' feature is documented as a local proxy that typically still connects to a cloud-hosted Neon project/branch rather than a fully standalone keyless engine, creating ambiguity about true offline independence. Missing for 10: independent/hands-on confirmation that a locally compiled Neon instance works fully offline in CI without any cloud account, and clarification that Neon Local is not itself cloud-dependent.

   • [github] “Neon can be run on a workstation for small experiments and to test code changes”
   • [github] “Alternatively, compile and run the project locally.”
   • [github] “Alternatively, compile and run the project locally (#running-local-installation).”
   • [github] “Neon is an open-source serverless Postgres database platform. It separates storage and compute”
   • [claimed-docs] “Neon Local”
   • [claimed-docs] “Neon Local - Neon Docs”

   proof ↗⚑ flag

   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

Integrations

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

   weight 2 · round drawn
   Neon—none0/10

   The evidence pack documents general Postgres compatibility features (connection pooling, serverless driver, branching, CLI, API) but contains no citation mentioning Prisma, Drizzle, Django, or Rails integration guides specifically. Without documented framework/ORM-specific guides in the evidence, this axis cannot be credited as delivered.

   ⚑ flag

   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

Migrations

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

   weight 1 · round to Turso
   Neon—none0/10

   The evidence pack covers Neon's branching, autoscaling, CLI, MCP server, and other features, but contains no documentation or reference to a migration path for importing an existing production database (e.g., pg_dump/restore, logical replication, minimal-downtime cutover guide). No citation addresses this specific story.

   ⚑ flag

   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

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

   weight 3 · round to Neon
   Neon~partialcommunity5/10

   Neon's branching (copy-on-write branches, instant restore) supports a branch-based workflow for testing schema changes before applying to production, and community confirms this pattern works well in practice (branch off main, test, reset). However there is no documented 'merge back' or schema-diff/merge tooling, no deploy-request workflow, and no explicit online-DDL/zero-downtime-migration guidance in the evidence. Missing for 10: explicit branch-merge or schema-diff tooling, deploy-request/approval workflow, documented online DDL or lock-free migration guarantees, and independent verification of safe production rollout beyond generic branching praise.

   • [claimed-docs] “Branching - Neon Docs”
   • [claimed-docs] “Instant restore”
   • [claimed-docs] “Instant restore - Neon Docs”
   • [community] “We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and per…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Neon
   Neon✓fullprobed8/10

   Neon publishes a full public API (openapi.json), an official CLI wrapping it, and a documented MCP server, covering project/branch/database management, auth, and most operations available in the UI (branching, autoscaling, connection pooling, restore, etc.). missing for 10: no explicit independent confirmation that every single UI action (e.g. billing/team management nuances) maps 1:1 to API endpoints, and no third-party audit of API completeness vs UI.

   • [claimed-docs] “Neon API”
   • [claimed-docs] “Neon API - Neon Docs”
   • [probe] “PROBE openapi: HTTP 200 at https://neon.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Neon CLI”
   • [claimed-docs] “Neon CLI - Neon Docs”
   • [probe] “official CLI documented at https://neon.com/docs/cli”
   • [claimed-docs] “Neon MCP Server overview”
   • [claimed-docs] “Neon MCP Server overview - Neon Docs”
   • [probe] “official MCP server documented at https://neon.com/docs/ai/neon-mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): the official Neon CLI ran keylessly from npm — `npx -y neon@latest --version` printed `4.14.1` with no …”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.neon.tech/mcp returned HTTP 401 w…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Neon
   Neon~partialclaimed5/10

   Neon is standard, open-source Postgres and can be accessed with any Postgres client (psql, dbeaver) or the Neon CLI/API, which implies standard export tooling like pg_dump works, and the open-source codebase (neon-gh-5/6) means self-hosting/leaving is possible in principle. However, there is no explicit vendor documentation of a one-click 'export all data' or full account/data-export feature, or specific pg_dump/backup-portability guide. Missing for 10: an explicit data-export/portability doc, evidence of exporting non-relational assets (e.g. object storage, auth records) in open formats, and confirmation of a smooth full account migration path.

   • [github] “connect to it with your preferred Postgres client (psql, dbeaver, etc) or use the online SQL Editor”
   • [github] “Neon is an open-source serverless Postgres database platform. It separates storage and compute”
   • [github] “Neon is an open-source serverless Postgres database platform.”
   • [claimed-docs] “Object Storage. S3-compatible blob storage that branches with your projects.”
   • [claimed-docs] “Managed Better Auth. Authentication with users and sessions stored in Postgres.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Neon
   Neon✓fullclaimed8/10

   The official GitHub repo is explicitly described as 'an open-source serverless Postgres database platform,' and instructions exist for compiling/running it locally, confirming the source is publicly available under an open license. Missing for 10: explicit citation of the specific license name (e.g., Apache-2.0) and independent confirmation of license terms beyond the repo's self-description.

   • [github] “Neon is an open-source serverless Postgres database platform. It separates storage and compute”
   • [github] “Neon is an open-source serverless Postgres database platform.”
   • [github] “Alternatively, compile and run the project locally.”
   • [github] “Alternatively, compile and run the project locally (#running-local-installation).”
   • [github] “Neon can be run on a workstation for small experiments and to test code changes”

   proof ↗⚑ flag

   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

4. ai-native userSelf-host the core product

   weight 3 · round to Turso
   Neon~partialcommunity6/10

   Neon's GitHub repo is explicitly open-source and documents that you can compile and run it locally, and that 'Neon can be run on a workstation for small experiments and to test code changes,' with a community comment confirming some users self-host the storage/compute architecture in production. However, the official docs and framing position self-hosting as workstation-scale testing rather than a fully supported production self-host path (no HA/scaling guide for self-hosted deployments). Missing for 10: production-grade self-hosting documentation, official support/guides for scaling a self-hosted cluster, and independent confirmation of large-scale self-hosted production use.

   • [github] “Neon can be run on a workstation for small experiments and to test code changes”
   • [github] “Alternatively, compile and run the project locally.”
   • [github] “Neon is an open-source serverless Postgres database platform. It separates storage and compute”
   • [github] “Alternatively, compile and run the project locally (#running-local-installation).”
   • [community] “For us that self-host, the architecture of building cold storage on top of Object Storage and warm storage on top of NVMEs is unbeatable. It…”

   proof ↗⚑ flag

   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

Cost controls

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

   weight 1 · round drawn
   Neon—none0/10

   No evidence pack item mentions spend caps, budget alerts, usage-based billing alerts, or any mechanism to cap or notify on cost overruns; pricing complaints in community citations discuss cost surprises but do not show Neon offering a cap/alert feature. This is a fair axis for a usage-billed cloud database service, so absence of evidence yields none rather than na.

   ⚑ flag

   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

Insights

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

   weight 2 · round drawn
   Neon—none0/10

   No evidence in the pack references a built-in insights view, slow query logging, index recommendations, or performance dashboards; documentation focuses on branching, scaling, connection pooling, and integrations instead. Neon does offer monitoring features per general knowledge, but this evidence pack contains no citation supporting the specific story.

   ⚑ flag

   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

Pricing

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

   weight 2 · round to Neon
   Neon✓fullcommunity8/10

   Neon's pricing docs explicitly promote a free tier with 'no time limits and no credit card required' and 100 projects allowed, and community comments corroborate quick provisioning for hobby/prototype use ('game-changer' for pay-per-call relational DB, fast to spin up databases). Missing for 10: independent evidence specifically confirming free-tier limits are sufficient for a 'real prototype' (e.g., storage/compute caps) and any hands-on account of hitting free-tier ceilings.

   • [claimed-docs] “Build and learn free with no time limits and no credit card required.”
   • [claimed-docs] “100 projects”
   • [community] “Having a relational database where you're charged purely for the calls you make is a game-changer. All of the relational databases I looked …”
   • [community] “Nice work Neon! I've used it a number of times and am impressed at how quickly databases become available. Leaps and bounds faster than RDS.…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Neon
   Neon!disputedcontradicted4/10

   Neon does publish a pricing page (docs-6,7,24) referencing tiers, projects, and team members, but the evidence pack contains no published per-unit rates for compute/storage/traffic that would let a founder predict a bill in advance. Community feedback directly contradicts predictability: users note pricing is based on 'CPU' that is 'never defined' (neon-comm-13), report surprise jumps to $69+/month after a pricing change (neon-comm-8), and question egress cost predictability for non-AWS clouds (neon-comm-12). Missing for 10: explicit per-unit $/compute-hour, $/GB-storage, $/GB-egress figures and independent confirmation that bills match expectations.

   • [claimed-docs] “100 projects”
   • [claimed-docs] “Unlimited team members”
   • [claimed-docs] “Build and learn free with no time limits and no credit card required.”
   • [community] “Is 5 a reference to how you naked the prices so Neon doesn't work for light-workload, moderate storage databases anymore? $69+ a month for a…”
   • [community] “Is it feasible to use Neon connecting from smaller clouds, such as Hetzner, DO, Linode, etc?... For small workloads egress cost doesn't matt…”
   • [community] “What is a CPU? If it's AWS hosted for example it can range from a t2 (low end) to c7a (high end) and have huge performance impacts... It's w…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Turso
   Neon—none0/10

   No evidence pack items mention region selection, data residency, or geographic deployment options for Neon projects; nothing addresses where data is physically stored.

   ⚑ flag

   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

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

   weight 3 · round drawn
   Neon—none0/10

   The evidence pack contains no mention of any AI-training opt-out, data-use policy for model training, or privacy controls governing whether customer data is used to train AI models; all evidence covers unrelated product features (branching, autoscaling, MCP server, CLI, pricing). Since Neon stores and processes user data and could plausibly offer such a privacy guarantee, the axis applies but is unaddressed. missing for 10: any documentation of an AI-training opt-out policy, data-processing/privacy terms addressing model training, or statements that customer data is excluded from AI training.

   ⚑ flag

   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

3. ai-native userControl data retention and deletion

   weight 2 · round to Turso
   Neon—none0/10

   The evidence pack shows Neon's general Postgres/branching/API/CLI capabilities but contains no documentation on data retention policies, deletion guarantees, or privacy-oriented data lifecycle controls (e.g., project/branch purge SLAs, GDPR-style deletion assurances). Missing for 10: any retention-policy docs, explicit deletion/purge guarantees, or compliance statements addressing data retention.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Neon—none0/10

   No evidence in the pack addresses telemetry collection or an opt-out mechanism for Neon's CLI, MCP server, or platform usage tracking; privacy/telemetry policy is simply not documented here.

   ⚑ flag

   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

Availability

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

   weight 2 · round drawn
   Neon~partialclaimed5/10

   Neon documents Read Replicas as a first-class feature (neon-docs-16/28), and its storage/compute separation architecture is described (neon-gh-5/6), but the evidence pack contains no explicit documentation of automated failover behavior or HA guarantees tied to replicas. Missing for 10: documented failover/HA SLAs, promotion-of-replica-to-primary process, and independent confirmation of failover behavior in production.

   • [claimed-docs] “Neon Read Replicas”
   • [claimed-docs] “Neon Read Replicas - Neon Docs”
   • [github] “Neon is an open-source serverless Postgres database platform. It separates storage and compute”
   • [github] “Neon is an open-source serverless Postgres database platform.”

   proof ↗⚑ flag

   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

Recovery

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

   weight 2 · round to Neon
   Neon~partialclaimed5/10

   Neon documents self-serve 'Instant restore' via branch/restore, which lets founders roll back a database without vendor support, satisfying the restore half of the story. However, there is no evidence of a traditional scheduled-backup mechanism with a visible/configurable schedule (Neon's architecture is continuous storage/branching rather than periodic backup jobs), so the 'schedule I can see and configure' part is unaddressed. Missing for 10: documentation of backup schedule visibility/configuration, retention policy controls, or backup frequency settings.

   • [claimed-docs] “Instant restore”
   • [claimed-docs] “Instant restore - Neon Docs”
   • [claimed-docs] “Branching - Neon Docs”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Neon✓fullcommunity8/10

   Neon documents Instant restore (point-in-time recovery within retention window) and Branching, and community evidence corroborates branch-and-reset workflows in production use. This directly matches the story of restoring/branching to a point in time to recover from bad writes. missing for 10: independent hands-on verification of exact restore-to-timestamp mechanics and retention-window limits beyond docs, and confirmation of behavior at scale/edge cases.

   • [claimed-docs] “Instant restore”
   • [claimed-docs] “Instant restore - Neon Docs”
   • [claimed-docs] “Branching - Neon Docs”
   • [community] “We use NeonDB in production and I the use of the term "branching" intuitive. We can branch off the main database to test things out, and per…”

   proof ↗⚑ flag

   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

Elasticity

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

   weight 2 · round to Neon
   Neon✓fullcommunity8/10

   Neon's docs explicitly document Autoscaling (compute scales with load automatically) and Scale to Zero (idle compute suspends), both core to serverless compute management without manual resizing, and community evidence corroborates fast/serverless provisioning behavior. Missing for 10: independent hands-on benchmarks proving no downtime during autoscale transitions and details on scaling limits/latency during scale-up events.

   • [claimed-docs] “Scale to Zero”
   • [claimed-docs] “Autoscaling”
   • [claimed-docs] “Autoscaling - Neon Docs”
   • [claimed-docs] “Scale to Zero - Neon Docs”
   • [community] “Nice work Neon! I've used it a number of times and am impressed at how quickly databases become available. Leaps and bounds faster than RDS.…”
   • [community] “Having a relational database where you're charged purely for the calls you make is a game-changer. All of the relational databases I looked …”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Neon
   Neon✓fullcommunity9/10

   Neon's docs explicitly document Scale to Zero (idle compute suspends) alongside durable storage separation (compute/storage split), and free tier/pricing pages confirm no-cost prototyping with no credit card required; community comments corroborate pay-per-use idle cost savings for hobby projects. missing for 10: independent verification of data durability specifically across scale-to-zero cycles (only vendor docs, no third-party confirmation of zero data loss).

   • [claimed-docs] “Scale to Zero”
   • [claimed-docs] “Scale to Zero - Neon Docs”
   • [claimed-docs] “Build and learn free with no time limits and no credit card required.”
   • [github] “Neon is an open-source serverless Postgres database platform. It separates storage and compute”
   • [community] “Having a relational database where you're charged purely for the calls you make is a game-changer. All of the relational databases I looked …”

   proof ↗⚑ flag

   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

Provisioning

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

   weight 3 · round drawn
   Neon✓fullprobed9/10

   Neon provides an official CLI and REST API (neon-docs-11, neon-docs-20, neon-probe-5, neon-probe-3), a free tier with instant serverless Postgres provisioning (neon-gh-2), and community testimony that databases become available very quickly without infra planning (neon-comm-6). Autoscaling and scale-to-zero eliminate manual capacity planning (neon-docs-9, neon-docs-10, neon-docs-26). Missing for 10: no independent benchmark timing the exact provisioning speed in seconds via CLI/API.

   • [claimed-docs] “Neon CLI”
   • [claimed-docs] “Neon API”
   • [github] “Try the Neon Free Tier to create a serverless Postgres instance.”
   • [community] “Nice work Neon! I've used it a number of times and am impressed at how quickly databases become available. Leaps and bounds faster than RDS.…”
   • [claimed-docs] “Scale to Zero”
   • [claimed-docs] “Autoscaling”
   • [probe] “official CLI documented at https://neon.com/docs/cli”
   • [probe] “PROBE openapi: HTTP 200 at https://neon.com/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

   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