Turso vs PlanetScale

Agent ops

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

   weight 3 · round to Turso
   Turso✓fullprobed8/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialprobed7/10

   PlanetScale ships a CLI (pscale) explicitly designed for agent workflows—non-interactive `pscale sql`, a baked-in `--skill` guide, and `--format json` output for agents—plus a hosted MCP server for Claude/Cursor that exposes Insights and query execution, and docs on branching/schema deploy requests that agents could drive without the dashboard. However, the evidence never shows an explicit 'create database' or 'fetch connection string' CLI/API command, and the MCP server's insights-only variant explicitly excludes query execution, leaving a gap in the fully automated create→connect→schema→query chain. Missing for 10: explicit documented commands/API calls for database creation and connection-string retrieval, and confirmation that the primary MCP variant (not just insights-only) supports full query execution end-to-end.

   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Open a secure MySQL or PostgreSQL shell instance”
   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “Database branching, coupled with deploy requests, allows you to deploy non-blocking schema changes to your production database with zero dow…”
   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”
   • [probe] “official MCP server documented at https://planetscale.com/docs/mcp-server”
   • [probe] “official CLI documented at https://planetscale.com/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --version` printed `pscale version 0.329.0` keylessly after `brew install planetscale/tap/pscal…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.pscale.dev/mcp/planetscale return…”

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

   PlanetScale~partialprobed6/10

   PlanetScale ships an official hosted MCP server (verified live via OAuth handshake) plus a vendor-shipped CLI skill (`pscale --skill`) explicitly designed for agent consumption, and docs describe a separate insights-only MCP variant that excludes query execution — a concrete read/analysis-vs-execute scoping distinction. Agents can run non-interactive SQL (`pscale sql`) and review Insights to open PRs, showing real delegated database work. Missing for 10: explicit documentation of granular tool-level permissions distinguishing read-only SELECT/Insights tools from destructive DDL/DML tools within the full MCP server itself, and no independent hands-on report confirming an agent safely blocked from destructive actions.

   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”
   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Open a secure MySQL or PostgreSQL shell instance”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.pscale.dev/mcp/planetscale return…”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso✓fullprobed7/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialprobed5/10

   PlanetScale's branching model (docs-9,10,32) and CLI (docs-17,24; probe-5) let you programmatically create and manage isolated database/branch instances, which maps to the 'agent workflows' isolation story, and the CLI is explicitly designed for scripted/agent use (pscale sql, --skill). However, PlanetScale's product is architected around branches-per-database rather than truly independent databases, and community pricing feedback ($1.25/10GB storage, $15/100M rows) plus lack of a free tier (planetscale-comm-5, planetscale-comm-11) and a report of database creation being halted under load (planetscale-comm-12) undercut the 'cheaply create thousands' framing. Missing for 10: explicit documentation of per-tenant/per-agent database creation at scale, confirmed low/no-cost pricing for thousands of isolated instances, and evidence of fleet-level programmatic provisioning (bulk create/delete) beyond single branch/database CLI commands.

   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “Branches on PlanetScale Postgres are isolated database deployments that provide you with separate environments for development and testing, …”
   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Open a secure MySQL or PostgreSQL shell instance”
   • [probe] “official CLI documented at https://planetscale.com/docs/cli”
   • [community] “I really wish that the hobby tier hadn't gone but I also understand that planetscale is a b2b... I hope that planetscale's team doesn't get …”
   • [community] “The pricing gives me anxiety. $1.25/mo per 10GB storage, $15/mo per 100 Million rows read, $15/mo per 10 Million rows written. But I won't l…”
   • [community] “The site is experiencing higher than normal traffic and we have temporarily halted database creation. Ironic coming from the infinitely scal…”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   Turso✓fullprobed9/10

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

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

   proof ↗⚑ flag

   PlanetScale✓fullprobed9/10

   PlanetScale ships a live llms.txt (HTTP 200, confirmed by direct probe) plus extensive agent-oriented documentation: a dedicated ai-tooling doc, an MCP server doc, and a CLI --skill command that prints a vendor-authored agent guide baked into the binary. This goes beyond the minimal story requirement of just having llms.txt or agent docs. Missing for 10: independent/community confirmation that agents actually consume and act correctly on llms.txt in the wild (only vendor-side probes exist).

   • [probe] “PROBE llms.txt: HTTP 200 at https://planetscale.com/llms.txt # PlanetScale > PlanetScale is a relational database platform for MySQL and Po…”
   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --version` printed `pscale version 0.329.0` keylessly after `brew install planetscale/tap/pscal…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Turso✓fullprobed8/10

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

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

   proof ↗⚑ flag

   PlanetScale✓fullprobed8/10

   PlanetScale's CLI explicitly supports non-interactive, scriptable SQL execution and JSON-formatted output designed for agents/automation, and runtime probes confirm `pscale --skill` ships a vendor-authored agent/CI guide plus `--format json` flags for headless use, alongside service-token auth (docs-7) enabling non-interactive authentication in CI. missing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions workflow), and independent community confirmation of headless CI usage.

   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “You can now show a single service token by ID.”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --version` printed `pscale version 0.329.0` keylessly after `brew install planetscale/tap/pscal…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”
   • [probe] “official CLI documented at https://planetscale.com/docs/cli”

   proof ↗⚑ flag

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

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

   PlanetScale✓fullprobed9/10

   PlanetScale documents and hosts an official MCP server (mcp.pscale.dev) that connects Claude, Cursor, Notion, and other MCP-compatible tools to PlanetScale databases and Insights, and a runtime probe confirms the endpoint is live and correctly speaks the MCP OAuth handshake. Missing for 10: independent hands-on user reports of using the MCP server in practice beyond the vendor docs/probe.

   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”
   • [probe] “official MCP server documented at https://planetscale.com/docs/mcp-server”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.pscale.dev/mcp/planetscale return…”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   PlanetScale✓fullprobed9/10

   PlanetScale ships an official CLI (`pscale`) with explicit AI-agent affordances: non-interactive SQL execution, JSON output, an `--skill` subcommand that prints a vendor-authored agent prompt, and insights/analytics commands — all confirmed via live runtime probes, not just docs. Missing for 10: independent (non-vendor) hands-on community commentary specifically about CLI agentic usage beyond the runtime probes.

   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Open a secure MySQL or PostgreSQL shell instance”
   • [probe] “official CLI documented at https://planetscale.com/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --version` printed `pscale version 0.329.0` keylessly after `brew install planetscale/tap/pscal…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”

   proof ↗⚑ flag

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

   weight 3 · round to Turso
   Turso✓fullprobed8/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialprobed6/10

   PlanetScale ships a scriptable CLI (`pscale sql`, `--format json`, `--skill` agent guide) and a hosted MCP server for AI tools, which lets AI-native users drive the product programmatically, and docs explicitly target 'agents and scripts.' However, probes show no discoverable REST/GraphQL public API spec (openapi.json/swagger.json all 404, docs.md 404), so there's no traditional documented public API beyond the CLI/MCP surface. Missing for 10: a discoverable OpenAPI/REST API spec, independent confirmation that the CLI/MCP fully substitute for a public API in third-party integrations.

   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --version` printed `pscale version 0.329.0` keylessly after `brew install planetscale/tap/pscal…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.pscale.dev/mcp/planetscale return…”
   • [probe] “PROBE docs-md: HTTP 404 at https://planetscale.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://planetscale.com/openapi.json, https://planetscale.com/swagger.json, https://planetscale.com/…”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso✓fullprobed8/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialprobed6/10

   PlanetScale supports scoped service tokens (shown/managed via CLI) for API access, and its hosted MCP server explicitly ships a separate insights-only variant that excludes query execution, speaking full OAuth Bearer scoping for agent connections — direct evidence of least-privilege credentialing for AI agents. However, there's no first-party doc enumerating granular permission scopes for service tokens or explicit guidance on issuing agent-specific restricted tokens beyond the MCP insights/query split. Missing for 10: documented granular service-token scope/role list, explicit agent-token creation workflow docs, independent/hands-on confirmation of scope enforcement.

   • [claimed-docs] “You can now show a single service token by ID.”
   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.pscale.dev/mcp/planetscale return…”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Turso
   Turso✓fullprobed9/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   The evidence pack contains no mention of official SDKs or client libraries for building applications against PlanetScale programmatically—only CLI (pscale), MCP server, and webhook/API changelog items are documented. Since language SDKs are a fair and plausible offering for a database platform, the absence of any first-party SDK docs means this axis is unmet, not inapplicable. Missing for 10: any documentation of official SDKs/client libraries (Node, Go, Python, etc.), API reference tied to those SDKs, or independent confirmation of their existence.

   ⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   PlanetScale✓fullclaimed8/10

   PlanetScale documents webhook events (including backup.succeeded/backup.failed) with configurable Authorization headers, giving AI-native users a way to subscribe to and consume platform events programmatically. missing for 10: broader catalog of event types beyond backups, independent hands-on confirmation of webhook reliability from community sources.

   • [claimed-docs] “You can now set an Authorization header on webhooks. Pass the full value, scheme included, like Bearer <token>.”
   • [claimed-docs] “We've added backup.succeeded and backup.failed webhook events. You'll get notified when a backup finishes, whether it worked or not.”

   proof ↗⚑ flag

Agentic features

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

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

   PlanetScale✓fullprobed8/10

   PlanetScale's Insights feature provides server-side analysis of production traffic—aggregated query stats, failing query patterns, resource anomalies, and schema recommendations—directly inside the product (CLI/dashboard), and community evidence corroborates Insights surfacing actionable suggestions like missing indexes. This goes further into agentic territory with self-improving-database agents that review Insights and open PRs automatically, and MCP integration to expose Insights to AI tools. Missing for 10: independent verification of the self-improving-database agent's real-world accuracy/quality beyond vendor docs, and no direct hands-on user account of the AI-generated schema recommendations specifically (only the Insights index-suggestion anecdote).

   • [claimed-docs] “Surface PlanetScale's server-side analysis of a database: aggregated query statistics, failing query patterns, resource anomalies, and schem…”
   • [claimed-docs] “Surface PlanetScale’s server-side analysis of a database: aggregated query statistics, failing query patterns, resource anomalies, and schem…”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [claimed-docs] “an agent identifies the highest-impact performance issues, finds the relevant code, makes improvements, and opens a pull request”
   • [community] “We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty sm…”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.pscale.dev/mcp/planetscale return…”

   proof ↗⚑ flag

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

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

   PlanetScale✓fullclaimed7/10

   PlanetScale documents a 'self-improving database' feature where an agent autonomously reviews production Insights and schema recommendations on a recurring schedule, then opens pull requests with performance improvements, plus webhook events for automation triggers. This matches the story of autonomous background automation, but evidence is first-party only. missing for 10: independent/hands-on confirmation that the self-improving agent actually runs unattended in production, and details on configuring/scheduling the automation beyond the doc description.

   • [claimed-docs] “an agent identifies the highest-impact performance issues, finds the relevant code, makes improvements, and opens a pull request”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [claimed-docs] “We've added backup.succeeded and backup.failed webhook events. You'll get notified when a backup finishes, whether it worked or not.”

   proof ↗⚑ flag

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

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

   PlanetScale~partialprobed4/10

   PlanetScale's 'self-improving database' feature describes an agent that reviews production Insights/Schema Recommendations on a recurring schedule and opens pull requests with performance improvements, which resembles a delegated-task AI capability tied to the product. However, this appears to run through connected external agents (Claude, Cursor, etc.) via the MCP server rather than a distinct in-dashboard chat assistant, and there's no evidence of a UI-embedded assistant a user directly converses with inside the product. Missing for 10: a first-party in-app chat/assistant UI, independent hands-on confirmation of the self-improving-database feature actually running end-to-end, and clarity that it's not just MCP-enabled third-party agents.

   • [claimed-docs] “an agent identifies the highest-impact performance issues, finds the relevant code, makes improvements, and opens a pull request”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.pscale.dev/mcp/planetscale return…”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso✓fullprobed8/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialprobed6/10

   PlanetScale enables natural-language/agentic operation indirectly via MCP server integration (Claude, Cursor, etc.) and a CLI with an agent-oriented '--skill' guide and JSON output modes for scripts/agents, plus a self-improving-database agent that opens PRs from Insights data. However, this is not a native NL command interface within PlanetScale's own product surface — it relies on third-party AI tools (Claude, Cursor) interpreting natural language and calling MCP/CLI functions, and there's no evidence of a first-party natural-language console or chat within the PlanetScale dashboard itself. missing for 10: evidence of a native in-product NL interface, independent hands-on validation of the MCP/agent workflow beyond vendor docs and probes.

   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”
   • [claimed-docs] “an agent identifies the highest-impact performance issues, finds the relevant code, makes improvements, and opens a pull request”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --version` printed `pscale version 0.329.0` keylessly after `brew install planetscale/tap/pscal…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”
   • [probe] “PROBE runtime (recorded 2026-09-06): keyless JSON-RPC initialize POST to the hosted MCP server https://mcp.pscale.dev/mcp/planetscale return…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Turso—none0/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   Probes explicitly show no OpenAPI/interactive API reference exists (docs.md 404, all openapi.json candidate paths 404), and no evidence pack item describes a runnable-example API console; only static CLI/API docs and changelog entries are present.

   • [probe] “PROBE docs-md: HTTP 404 at https://planetscale.com/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://planetscale.com/openapi.json, https://planetscale.com/swagger.json, https://planetscale.com/…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Turso—none0/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   The probe explicitly checked for an OpenAPI/Swagger spec at all standard candidate paths and found only 404s, with no other evidence of a published machine-readable API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://planetscale.com/openapi.json, https://planetscale.com/swagger.json, https://planetscale.com/…”
   • [probe] “PROBE docs-md: HTTP 404 at https://planetscale.com/docs.md”

   proof ↗⚑ flag

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

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

   PlanetScale✓fullprobed9/10

   PlanetScale's core branching model explicitly provides isolated dev/test branches separate from production ('separate environments for development and testing'), with deploy-requests to safely promote schema changes without touching production data directly, and this is corroborated by community accounts of using branch-per-git-branch workflows for development/testing. The MCP server and CLI further enable AI agents to interact with branches programmatically rather than production. Missing for 10: no hands-on independent account specifically framing branch use as an 'AI agent sandbox test' scenario, though the underlying capability is well documented.

   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “Branches on PlanetScale Postgres are isolated database deployments that provide you with separate environments for development and testing, …”
   • [claimed-docs] “Database branching, coupled with deploy requests, allows you to deploy non-blocking schema changes to your production database with zero dow…”
   • [claimed-docs] “You can then create development branches that you can use for development before shipping schema changes to production.”
   • [community] “I have been using the beta version of PlanetScale for a while, and it is extremely cool... It will give you a database branch for each Git b…”
   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [probe] “official MCP server documented at https://planetscale.com/docs/mcp-server”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Turso—none0/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   No evidence pack items mention API versioning scheme or a documented deprecation policy; probes for OpenAPI specs return 404s and changelog entries are feature announcements, not API-version/deprecation documentation.

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

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialprobed5/10

   PlanetScale's CLI explicitly supports non-interactive, scriptable operation (`pscale sql`) with a vendor-shipped agent skill and JSON output modes clearly aimed at automation across many items, and its AI-tooling docs describe agents that recurringly review Insights/Schema Recommendations across a database and open PRs. However, there's no explicit documentation of true bulk/batch operations (e.g., batch branch creation/deletion, bulk import across many databases, multi-item API calls) — the CLI and API appear built around single-resource commands invoked repeatedly rather than a dedicated bulk-operation primitive. Missing for 10: explicit bulk/batch API or CLI commands operating on many items in one call, and independent hands-on evidence of large-scale automated bulk operations succeeding.

   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --version` printed `pscale version 0.329.0` keylessly after `brew install planetscale/tap/pscal…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”
   • [claimed-docs] “Connect Claude, Cursor, Notion, and other MCP-compatible tools to your PlanetScale databases and Insights”

   proof ↗⚑ flag

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

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

   PlanetScale~partialclaimed4/10

   PlanetScale supports webhook events (e.g., backup.succeeded/failed) with configurable authorization headers, letting users trigger external actions when specific system events occur, and its self-improving-database agent runs on a recurring schedule to open PRs based on Insights data. However, this is limited to a small set of predefined events (mainly backups) rather than a general-purpose rule engine for arbitrary triggers/actions. missing for 10: a documented rules/automation engine supporting custom trigger conditions across arbitrary event types, and evidence of user-defined conditional logic beyond fixed webhook events.

   • [claimed-docs] “We've added backup.succeeded and backup.failed webhook events. You'll get notified when a backup finishes, whether it worked or not.”
   • [claimed-docs] “You can now set an Authorization header on webhooks. Pass the full value, scheme included, like Bearer <token>.”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [claimed-docs] “an agent identifies the highest-impact performance issues, finds the relevant code, makes improvements, and opens a pull request”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   PlanetScale~partialclaimed5/10

   PlanetScale documents a specific recurring AI-driven workflow: agents reviewing Insights/Schema Recommendations and opening PRs 'on a recurring schedule' (docs-31, docs-20), plus daily scheduled backups (docs-12, docs-33). This is real recurring automation but narrow — it's tied to the self-improving-database feature, not a general-purpose job/workflow scheduler that AI-native users can configure for arbitrary tasks. Missing for 10: a documented mechanism for users to define/schedule arbitrary custom jobs or workflows (e.g., cron-style scheduling, workflow orchestration), and independent/community confirmation that the recurring-agent feature works in practice.

   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [claimed-docs] “an agent identifies the highest-impact performance issues, finds the relevant code, makes improvements, and opens a pull request”
   • [claimed-docs] “PlanetScale provides the ability to create, schedule, and restore backups for production and development database branches.”
   • [claimed-docs] “In addition to the daily default backups that PlanetScale schedules for your database branches, you can create additional manual backups.”

   proof ↗⚑ flag

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

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

   PlanetScale✓fullclaimed7/10

   PlanetScale's docs show agents opening pull requests for schema changes (docs-20, docs-31) that flow through deploy requests for review (docs-11, docs-27), with branching giving version isolation (docs-9, docs-10) and backups/point-in-time restore enabling rollback (docs-12, docs-5, docs-33). Together these cover the version/review/rollback lifecycle for AI-driven automations. missing for 10: independent/hands-on corroboration that agent-opened PRs are actually reviewed and rolled back in practice, and a dedicated audit/version history view specifically for automation runs rather than general schema branches.

   • [claimed-docs] “an agent identifies the highest-impact performance issues, finds the relevant code, makes improvements, and opens a pull request”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [claimed-docs] “Database branching, coupled with deploy requests, allows you to deploy non-blocking schema changes to your production database with zero dow…”
   • [claimed-docs] “deploy non-blocking schema changes to your production database with zero downtime”
   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “Branches on PlanetScale Postgres are isolated database deployments that provide you with separate environments for development and testing, …”
   • [claimed-docs] “PlanetScale provides the ability to create, schedule, and restore backups for production and development database branches.”
   • [claimed-docs] “You can now create a PostgreSQL branch restored to a point-in-time timestamp with --restore-point.”
   • [claimed-docs] “In addition to the daily default backups that PlanetScale schedules for your database branches, you can create additional manual backups.”
   • [claimed-docs] “After starting a switchover, you can now list switchovers for a branch and show one by ID.”

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

   PlanetScale~partialclaimed6/10

   Docs show branch restore capability via backups (create/schedule/restore backups for branches, docs-12/33) and Postgres branches support point-in-time restore with --restore-point (docs-5), plus branches described as providing 'restoring from backups' (docs-10). However, there's no explicit documentation of a 'reset branch to match parent' operation for the (MySQL/Vitess) branching model, and no independent/community confirmation of restoring a branch state without a full dump rebuild. Missing for 10: explicit 'reset to parent' semantics for MySQL branches, hands-on/community verification of restore workflow, and clarity on whether MySQL branches support point-in-time restore like Postgres.

   • [claimed-docs] “You can now create a PostgreSQL branch restored to a point-in-time timestamp with --restore-point.”
   • [claimed-docs] “Branches on PlanetScale Postgres are isolated database deployments that provide you with separate environments for development and testing, …”
   • [claimed-docs] “PlanetScale provides the ability to create, schedule, and restore backups for production and development database branches.”
   • [claimed-docs] “In addition to the daily default backups that PlanetScale schedules for your database branches, you can create additional manual backups.”
   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”

   proof ↗⚑ flag

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

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

   PlanetScale~partialprobed7/10

   PlanetScale's core product is branch-based schema workflows (branch per git branch, dev/test isolation, restore-point branches) and the CLI/API supports creating and deleting branches non-interactively, which platform engineers can script into CI. However, the evidence pack has no explicit CI/CD integration example (e.g., GitHub Action, deploy-platform webhook triggering branch creation/teardown per PR) — only generic webhook/backup events and CLI docs are shown. Missing for 10: a documented CI/CD or GitHub Actions integration showing automatic branch creation on PR-open and deletion on PR-close, and evidence of platform (e.g., Vercel/Netlify) preview-environment wiring.

   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “You can then create development branches that you can use for development before shipping schema changes to production.”
   • [claimed-docs] “You can now create a PostgreSQL branch restored to a point-in-time timestamp with --restore-point.”
   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [community] “I have been using the beta version of PlanetScale for a while, and it is extremely cool... It will give you a database branch for each Git b…”
   • [probe] “official CLI documented at https://planetscale.com/docs/cli”

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

   PlanetScale✓fullcommunity9/10

   PlanetScale's docs explicitly describe branching database schemas and data the same way as code branches, creating isolated dev/test environments from production-shaped branches (docs-9, docs-10, docs-32), corroborated by hands-on community use describing a database branch per git branch workflow (comm-9). Backups/restores and non-blocking schema deploys further support the workflow (docs-11, docs-12, docs-27). missing for 10: independent post-2021 hands-on confirmation of copy-on-write speed/isolation specifics, explicit copy-on-write terminology in docs.

   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “Branches on PlanetScale Postgres are isolated database deployments that provide you with separate environments for development and testing, …”
   • [claimed-docs] “Database branching, coupled with deploy requests, allows you to deploy non-blocking schema changes to your production database with zero dow…”
   • [claimed-docs] “You can then create development branches that you can use for development before shipping schema changes to production.”
   • [community] “I have been using the beta version of PlanetScale for a while, and it is extremely cool... It will give you a database branch for each Git b…”

   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 Turso
   Turso~partialprobed7/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   The evidence pack contains no mention of an HTTP- or WebSocket-based serverless/edge driver, connection pooling for short-lived connections, or any client library targeting edge runtimes; only CLI, MCP server, branching, backups, and general connectivity topics are covered. This axis clearly applies to a database platform aiming at modern app stacks, but no supporting evidence exists in the pack.

   ⚑ flag

Latency

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

   weight 2 · round to Turso
   Turso~partialcommunity6/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialclaimed5/10

   PlanetScale docs mention listing available regions for a database and configured Vitess read-only regions, implying support for placing read replicas in specific geographic regions to reduce latency, and Postgres replicas can offload reads from the primary. However, this is a single thin mention with no detail on how region selection is configured, no explicit multi-region replica setup guide, and no independent/community confirmation of real-world latency improvements from region placement. Missing for 10: detailed region-selection/configuration docs, benchmarks or community reports of latency reduction from region placement, and confirmation this works consistently across both MySQL/Vitess and Postgres offerings.

   • [claimed-docs] “You can now list the regions available to a database, and list configured Vitess read-only regions for the database's default branch.”
   • [claimed-docs] “Append `|replica` to the end of your username for the branch you want to target”
   • [claimed-docs] “They provide a way to reduce load on your primary instance by allowing you to read from a replica.”
   • [claimed-docs] “Postgres replicas can be used to read data and reduce load on the primary.”

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

   PlanetScale~partialclaimed6/10

   Docs confirm PlanetScale Postgres ships with a managed PgBouncer instance (with its own dashboard/graphs), meaning the platform-engineer doesn't need to deploy or operate a separate pooler themselves. However, there's no explicit documentation quantifying concurrent-connection capacity ('thousands of connections') or describing pooler configuration/tuning options, and MySQL/Vitess-side pooling (vttablet) isn't mentioned at all in the pack. Missing for 10: explicit connection-capacity claims/benchmarks, pooler configuration docs, and confirmation this applies to the MySQL/Vitess product line as well as Postgres.

   • [claimed-docs] “Postgres instance, storage, and PgBouncer graphs now live on their own tabs with shareable URLs.”

   proof ↗⚑ flag

Ai data

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

   weight 2 · round to Turso
   Turso✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   No evidence anywhere in the pack mentions vector data types, embeddings, or similarity search functionality in PlanetScale (MySQL or Postgres offerings); the pack covers branching, backups, scaling, MCP/CLI tooling, and pricing but nothing about vector storage/search.

   ⚑ flag

Analytics

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

   weight 2 · round drawn
   Turso—none0/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   PlanetScale's evidence pack shows a MySQL/Postgres OLTP platform (branching, backups, replicas, sharding, Metal for IOPS, Insights for query monitoring) but nothing about columnar storage, OLAP query engines, or analytical aggregation performance for dashboard workloads over large tables. No documentation or community evidence addresses running heavy analytical aggregations fast without exporting to a warehouse.

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

   PlanetScale!disputedcontradicted4/10

   PlanetScale markets itself as MySQL and Postgres compatible with branching, imports, and scaling docs, but hands-on community reports specifically state that PlanetScale's Vitess-based MySQL layer does not support foreign keys — a core MySQL feature many existing apps expect — making it a lookalike subset rather than full engine fidelity for that dialect. Missing for 10: any evidence resolving the FK limitation, independent confirmation of full Postgres extension/dialect parity, and SQLite compatibility is not addressed at all.

   • [community] “The referential integrity piece (otherwise known as Foreign Keys) will not be addressed and is a limitation - some might say feature - of Vi…”
   • [community] “To me, this means that planetscale (and vitess) immediately become less useful for a large class of applications: existing apps that use an …”
   • [community] “The boulder-sized caveat: PlanetScale's Non-Blocking Schema Changes' workflow doesn't support FOREIGN KEYs in users' databases.”
   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “PlanetScale provides an import tool in the dashboard that allows you to painlessly import an existing internet-accessible MySQL or MariaDB d…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://planetscale.com/llms.txt # PlanetScale > PlanetScale is a relational database platform for MySQL and Po…”

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

   PlanetScale~partialprobed7/10

   Docs confirm core CLI daily-loop pieces: opening a secure MySQL/Postgres shell (pscale shell), running non-interactive SQL for scripts/agents (pscale sql), listing/showing service tokens, regions, and switchovers, and enabling org SSO from the CLI — and a runtime probe confirms the CLI installs and works keylessly with agent-oriented help (`--skill`). However, explicit CLI-driven 'create database' and full branch-lifecycle commands aren't directly cited (only branching/backup docs, which are Vitess/Postgres feature docs rather than CLI command references). Missing for 10: explicit CLI create-database/create-branch command docs, and independent hands-on confirmation that inspect/connect flows fully replace the dashboard.

   • [claimed-docs] “Open a secure MySQL or PostgreSQL shell instance”
   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Organization administrators can now enable and manage SSO from the CLI with pscale org sso.”
   • [claimed-docs] “You can now show a single service token by ID.”
   • [claimed-docs] “You can now list the regions available to a database, and list configured Vitess read-only regions for the database's default branch.”
   • [claimed-docs] “After starting a switchover, you can now list switchovers for a branch and show one by ID.”
   • [probe] “official CLI documented at https://planetscale.com/docs/cli”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --version` printed `pscale version 0.329.0` keylessly after `brew install planetscale/tap/pscal…”
   • [probe] “PROBE runtime (recorded 2026-09-06): `pscale --skill` printed a complete vendor-shipped agent guide keylessly — Markdown frontmatter `name: …”

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

   PlanetScale—none0/10

   PlanetScale is a cloud-hosted database platform; there is no evidence of a downloadable/local engine that runs keylessly offline. Community evidence directly confirms this gap: a user explicitly asked whether PlanetScale can be installed locally, work offline, or is open source, and confirmed the answer to all three is no, calling it vendor lock-in.

   • [community] “Can I install this locally? Will it work without an internet connection? Is it fully open source? From what I can tell, the answer to all th…”

   proof ↗⚑ flag

Integrations

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

   weight 2 · round drawn
   Turso—none0/10

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

   ⚑ flag

   PlanetScale—none0/10

   The evidence pack contains extensive docs on branching, schema deploy requests, backups, imports, and CLI/MCP tooling, but nothing that specifically documents ORM or framework integration guides for Prisma, Drizzle, Django, or Rails. No citation mentions any of these named ORMs/frameworks or dedicated setup guides for them.

   ⚑ flag

Migrations

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

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

   PlanetScale✓fullcommunity8/10

   PlanetScale's docs explicitly describe a dashboard import tool for existing internet-accessible MySQL/MariaDB databases with 'no downtime' (planetscale-docs-13, planetscale-docs-21), giving a documented migration path. Community evidence corroborates smooth production migrations (e.g., Metal migration over the weekend with major improvements), though one user notes friction migrating from Heroku due to logical replication restrictions. Missing for 10: independent hands-on verification specifically of the MySQL/MariaDB import tool (vs. Postgres/Metal migrations), and no mention of Postgres import path with equivalent zero-downtime guarantee.

   • [claimed-docs] “PlanetScale provides an import tool in the dashboard that allows you to painlessly import an existing internet-accessible MySQL or MariaDB d…”
   • [claimed-docs] “PlanetScale provides an import tool in the dashboard that allows you to painlessly import an existing internet-accessible MySQL or MariaDB d…”
   • [community] “We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty sm…”
   • [community] “Just wish the migration path from Heroku was a tad easier (Heroku blocks logical replication on all instances) but pushing through anyway be…”

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

   PlanetScale~partialcommunity7/10

   PlanetScale's docs describe schema branching plus deploy requests as the core workflow for non-blocking, zero-downtime production schema changes, and community reports (e.g., smooth Metal migration, working Insights) corroborate real-world use. However, independent community reports flag a 'boulder-sized caveat' that the non-blocking schema-change workflow does not support foreign keys, which excludes many existing schemas from safe zero-downtime migrations. missing for 10: evidence of foreign-key support in the non-blocking DDL workflow, and independent verification of deploy-request behavior under load/failure scenarios.

   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “Database branching, coupled with deploy requests, allows you to deploy non-blocking schema changes to your production database with zero dow…”
   • [claimed-docs] “deploy non-blocking schema changes to your production database with zero downtime”
   • [claimed-docs] “You can then create development branches that you can use for development before shipping schema changes to production.”
   • [community] “The boulder-sized caveat: PlanetScale's Non-Blocking Schema Changes' workflow doesn't support FOREIGN KEYs in users' databases.”
   • [community] “The referential integrity piece (otherwise known as Foreign Keys) will not be addressed and is a limitation - some might say feature - of Vi…”
   • [community] “To me, this means that planetscale (and vitess) immediately become less useful for a large class of applications: existing apps that use an …”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Turso~partialprobed6/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialprobed6/10

   The CLI/API surface is broad — SSO management, service tokens, backups, webhooks, regions, switchovers, branching, insights, sql shell — mirroring most dashboard actions (planetscale-docs-3,4,6,7,8,17,24,26). However the import tool is explicitly described as living 'in the dashboard' (planetscale-docs-13/21), suggesting at least one UI-only capability, and probes show no discoverable OpenAPI/REST spec (planetscale-probe-3), only CLI-level parity documented. Missing for 10: confirmed feature-for-feature parity (e.g. import via CLI/API), a documented formal API spec, and independent hands-on confirmation that nothing requires the UI.

   • [claimed-docs] “Organization administrators can now enable and manage SSO from the CLI with pscale org sso.”
   • [claimed-docs] “We've added backup.succeeded and backup.failed webhook events. You'll get notified when a backup finishes, whether it worked or not.”
   • [claimed-docs] “After starting a switchover, you can now list switchovers for a branch and show one by ID.”
   • [claimed-docs] “You can now show a single service token by ID.”
   • [claimed-docs] “You can now list the regions available to a database, and list configured Vitess read-only regions for the database's default branch.”
   • [claimed-docs] “PlanetScale provides an import tool in the dashboard that allows you to painlessly import an existing internet-accessible MySQL or MariaDB d…”
   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Open a secure MySQL or PostgreSQL shell instance”
   • [probe] “PROBE openapi: all candidate paths 404 (https://planetscale.com/openapi.json, https://planetscale.com/swagger.json, https://planetscale.com/…”
   • [probe] “official CLI documented at https://planetscale.com/docs/cli”

   proof ↗⚑ flag

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

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

   PlanetScale—none0/10

   The evidence pack shows no vendor documentation of a bulk data-export feature or open-format dump/leave workflow (only an import tool for MySQL/MariaDB is documented). Community commentary directly states PlanetScale is not open source, can't run locally/offline, and is 'yet another example of vendor lock-in,' reinforcing the absence of a documented exit/export path.

   • [claimed-docs] “PlanetScale provides an import tool in the dashboard that allows you to painlessly import an existing internet-accessible MySQL or MariaDB d…”
   • [community] “Can I install this locally? Will it work without an internet connection? Is it fully open source? From what I can tell, the answer to all th…”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso~partialprobed5/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   PlanetScale is a closed, proprietary hosted database platform; no evidence pack item claims open-licensed source code, and community evidence explicitly states it is not open source ('Is it fully open source? ... the answer ... is no').

   • [community] “Can I install this locally? Will it work without an internet connection? Is it fully open source? From what I can tell, the answer to all th…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

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

   PlanetScale—none0/10

   PlanetScale is a fully-hosted cloud database platform with no documented self-host/on-prem option; community evidence explicitly confirms it cannot be installed locally or run offline and is not open source ('Can I install this locally?... the answer to all three questions is no'), contradicting the self-hosting story entirely.

   • [community] “Can I install this locally? Will it work without an internet connection? Is it fully open source? From what I can tell, the answer to all th…”

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

   PlanetScale—none0/10

   Docs show only that founders can view current/previous usage per database (planetscale-docs-25), not that they can set spend caps or configure usage alerts to prevent surprise bills. No evidence pack item describes budget limits, alert thresholds, or automatic throttling tied to spend.

   • [claimed-docs] “View your current and previous usage per database”

   proof ↗⚑ flag

Insights

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

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

   PlanetScale✓fullcommunity9/10

   PlanetScale's Insights feature surfaces aggregated query statistics, failing query patterns, resource anomalies, and schema recommendations computed from production traffic, including ranking top queries by performance metric — directly matching the story's slow-query, index-recommendation, and performance-metrics asks. A hands-on HN report independently corroborates that the Insights tab surfaced missing indexes that sped up queries after migration. Missing for 10: broader independent corroboration beyond a single community post and more detail on the dashboard UI itself (docs focus mostly on CLI insights commands).

   • [claimed-docs] “Surface PlanetScale's server-side analysis of a database: aggregated query statistics, failing query patterns, resource anomalies, and schem…”
   • [claimed-docs] “Surface PlanetScale’s server-side analysis of a database: aggregated query statistics, failing query patterns, resource anomalies, and schem…”
   • [claimed-docs] “List top queries ranked by a performance metric”
   • [claimed-docs] “Agents can review production Insights data and Schema Recommendations, then open pull requests with performance improvements — on a recurrin…”
   • [community] “We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty sm…”

   proof ↗⚑ flag

Pricing

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

   weight 2 · round to Turso
   Turso✓fullcommunity7/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   Community evidence explicitly states PlanetScale removed its free/hobby tier and users now face pay-as-you-go pricing with per-row and per-storage charges, with no vendor docs describing any current free tier for prototyping. No evidence contradicts this or shows a usable free option today.

   • [community] “I really wish that the hobby tier hadn't gone but I also understand that planetscale is a b2b... I hope that planetscale's team doesn't get …”
   • [community] “The pricing gives me anxiety. $1.25/mo per 10GB storage, $15/mo per 100 Million rows read, $15/mo per 10 Million rows written. But I won't l…”

   proof ↗⚑ flag

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

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

   PlanetScale~partialcommunity4/10

   Community evidence cites specific per-unit rates (storage, rows read, rows written) suggesting granular usage-based pricing exists, and docs mention a usage dashboard for tracking consumption, but there is no first-party pricing page or rate card in the evidence pack confirming these figures are current or comprehensive across compute, storage, and traffic. missing for 10: an official pricing page with per-unit rates, confirmation the cited 2021 rates are current, and any breakdown of compute pricing specifically.

   • [community] “The pricing gives me anxiety. $1.25/mo per 10GB storage, $15/mo per 100 Million rows read, $15/mo per 10 Million rows written. But I won't l…”
   • [claimed-docs] “View your current and previous usage per database”
   • [community] “I really wish that the hobby tier hadn't gone but I also understand that planetscale is a b2b... I hope that planetscale's team doesn't get …”

   proof ↗⚑ flag

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

   weight 2 · round to Turso
   Turso~partialclaimed6/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialclaimed4/10

   Docs mention listing regions available to a database and configuring read-only regions (planetscale-docs-8), implying region selection is possible, but there's no explicit documentation of choosing a primary region at database creation, data residency guarantees, or compliance certifications. missing for 10: explicit region-selection-at-creation docs, data residency/compliance statements, independent confirmation of region choice.

   • [claimed-docs] “You can now list the regions available to a database, and list configured Vitess read-only regions for the database's default branch.”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Turso
   Turso~partialclaimed6/10

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

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

   proof ↗⚑ flag

   PlanetScale—none0/10

   The evidence pack covers backups, branching, replicas, and MCP/CLI tooling but contains no documentation of data-retention policies, backup-retention windows, or explicit data-deletion/purge controls (e.g., how long backups are kept, how to fully delete a database or purge branch data) that would let an AI-native user govern retention and deletion.

   ⚑ flag

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

   weight 2 · round drawn
   Turso—none0/10

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

   ⚑ flag

   PlanetScale—none0/10

   No evidence pack item mentions telemetry, usage tracking, or an opt-out setting for PlanetScale's CLI, dashboard, or MCP server; the closest related item (usage billing view) concerns cost tracking, not telemetry.

   ⚑ flag

Availability

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

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

   PlanetScale✓fullcommunity7/10

   PlanetScale documents read replicas (Postgres and Vitess read-only regions), branch switchovers with list/show by ID, scheduled/manual backups, and backup success/failure webhook events, covering the core reliability and failover lifecycle. Community evidence (comm-1, comm-2) corroborates responsive incident handling, though it's not a rigorous documented failover SLA or independent chaos-test report. Missing for 10: an explicit HA/failover SLA or uptime guarantee, and independent verification of automatic failover behavior under real outages.

   • [claimed-docs] “You can now list the regions available to a database, and list configured Vitess read-only regions for the database's default branch.”
   • [claimed-docs] “Append `|replica` to the end of your username for the branch you want to target”
   • [claimed-docs] “They provide a way to reduce load on your primary instance by allowing you to read from a replica.”
   • [claimed-docs] “Postgres replicas can be used to read data and reduce load on the primary.”
   • [claimed-docs] “After starting a switchover, you can now list switchovers for a branch and show one by ID.”
   • [claimed-docs] “PlanetScale provides the ability to create, schedule, and restore backups for production and development database branches.”
   • [claimed-docs] “In addition to the daily default backups that PlanetScale schedules for your database branches, you can create additional manual backups.”
   • [claimed-docs] “We've added backup.succeeded and backup.failed webhook events. You'll get notified when a backup finishes, whether it worked or not.”
   • [community] “We just migrated to PlanetScale Postgres Metal over the weekend. We are already seeing major query improvements. The migration was pretty sm…”
   • [community] “We were in the beta for this and they've been great... Had one incident during the beta which we believed we caused on our own but within 5 …”

   proof ↗⚑ flag

Recovery

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

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

   PlanetScale✓fullclaimed7/10

   Docs explicitly state PlanetScale lets users create, schedule, and restore backups for branches, with daily default backups plus manual backups, point-in-time restore for Postgres branches, and webhook notifications (backup.succeeded/failed) for visibility into backup status. This covers scheduled, visible, self-serve backup/restore workflows for both MySQL/Vitess and Postgres branches. Missing for 10: no independent/hands-on community confirmation of the backup/restore UX specifically, and no detail on how granular the schedule configuration UI is beyond 'daily default'.

   • [claimed-docs] “PlanetScale provides the ability to create, schedule, and restore backups for production and development database branches.”
   • [claimed-docs] “In addition to the daily default backups that PlanetScale schedules for your database branches, you can create additional manual backups.”
   • [claimed-docs] “You can now create a PostgreSQL branch restored to a point-in-time timestamp with --restore-point.”
   • [claimed-docs] “We've added backup.succeeded and backup.failed webhook events. You'll get notified when a backup finishes, whether it worked or not.”
   • [claimed-docs] “Branches on PlanetScale Postgres are isolated database deployments that provide you with separate environments for development and testing, …”

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

   PlanetScale✓fullclaimed8/10

   PlanetScale docs explicitly support point-in-time restore branches for Postgres (--restore-point), scheduled/manual backups for Vitess branches, and branching that includes restoring from backups, directly matching the platform-engineer's recovery workflow. missing for 10: independent/hands-on verification of an actual PITR recovery from a bad write, and explicit documentation of the retention window length/limits.

   • [claimed-docs] “You can now create a PostgreSQL branch restored to a point-in-time timestamp with --restore-point.”
   • [claimed-docs] “Branches on PlanetScale Postgres are isolated database deployments that provide you with separate environments for development and testing, …”
   • [claimed-docs] “PlanetScale provides the ability to create, schedule, and restore backups for production and development database branches.”
   • [claimed-docs] “In addition to the daily default backups that PlanetScale schedules for your database branches, you can create additional manual backups.”
   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”

   proof ↗⚑ flag

Elasticity

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

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

   PlanetScale~partialcommunity4/10

   A community comment describes the platform scaling an instance from zero to handling massive load automatically, but this is an old beta anecdote rather than current vendor documentation, and the docs pack mostly describes read replicas, sharding, and dedicated 'Metal' instances (which imply manual provisioning, not automatic compute autoscaling). Missing for 10: official docs describing automatic vertical/horizontal compute scaling triggers, confirmation of zero-downtime resizing for the current Postgres/Metal offering, and independent hands-on verification of autoscale behavior under load.

   • [community] “I have been using the beta version of PlanetScale for a while, and it is extremely cool... It will give you a database branch for each Git b…”
   • [claimed-docs] “Metal is an excellent choice for high-IOPS and other performance-critical workloads. With Metal, your database now has the ability to use mo…”
   • [claimed-docs] “You can now list the regions available to a database, and list configured Vitess read-only regions for the database's default branch.”
   • [claimed-docs] “They provide a way to reduce load on your primary instance by allowing you to read from a replica.”

   proof ↗⚑ flag

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

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

   PlanetScale~partialcommunity3/10

   Only a single old community comment (from the 2020 beta) claims the database 'cost scale to 0, so it is perfect for small projects,' and no current vendor docs in the pack describe a scale-to-zero or free-tier mechanism; another community comment notes the hobby/free tier was later removed, casting doubt on whether idle prototypes truly cost nothing today. missing for 10: current first-party documentation describing scale-to-zero billing/behavior, confirmation that idle databases remain durable while scaled down, and evidence of an active free/hobby tier for side projects.

   • [community] “I have been using the beta version of PlanetScale for a while, and it is extremely cool... It will give you a database branch for each Git b…”
   • [community] “I really wish that the hobby tier hadn't gone but I also understand that planetscale is a b2b... I hope that planetscale's team doesn't get …”
   • [community] “The pricing gives me anxiety. $1.25/mo per 10GB storage, $15/mo per 100 Million rows read, $15/mo per 10 Million rows written. But I won't l…”

   proof ↗⚑ flag

Provisioning

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

   weight 3 · round to Turso
   Turso✓fullprobed9/10

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

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

   proof ↗⚑ flag

   PlanetScale~partialcommunity6/10

   Docs and community evidence support serverless, scale-to-zero database provisioning and branching (e.g., 'database branch for each Git branch... cost scale to 0... will scale to support massive load') and PlanetScale's CLI is documented for schema branching, SQL execution, and shell access, implying rapid setup without manual capacity planning. However, no evidence explicitly documents a 'create database' CLI/API command or confirms 'ready in seconds' timing, and one community report notes a past incident where database creation was temporarily halted due to traffic. missing for 10: explicit CLI/API docs for database creation command, quantified provisioning time, and independent verification of instant readiness.

   • [community] “I have been using the beta version of PlanetScale for a while, and it is extremely cool... It will give you a database branch for each Git b…”
   • [claimed-docs] “PlanetScale allows you to branch database schemas the same way you branch your code.”
   • [claimed-docs] “Run non-interactive SQL for agents and scripts (`pscale sql`)”
   • [claimed-docs] “Open a secure MySQL or PostgreSQL shell instance”
   • [community] “The site is experiencing higher than normal traffic and we have temporarily halted database creation. Ironic coming from the infinitely scal…”

   proof ↗⚑ flag