PlanetScale vs ClickHouse

Agent ops

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

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

   ClickHouse~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialprobed4/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialprobed4/10

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

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

   proof ↗⚑ flag

Agent access

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

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

   ClickHouse✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse✓fullprobed8/10

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

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

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   ClickHouse✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse—none0/10

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

   ⚑ flag

7. ai-native userBuild against official SDKs

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

   ClickHouse—none0/10

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

   ⚑ flag

8. ai-native userSubscribe to events via webhooks

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

   ClickHouse—none0/10

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

   ⚑ flag

Agentic features

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

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

   ClickHouse~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialprobed5/10

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

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

   proof ↗⚑ flag

Api quality

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

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

   ClickHouse—none0/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse✓fullprobed9/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse—none0/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialclaimed4/10

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

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   ClickHouse—none0/10

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

   ⚑ flag

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

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

   ClickHouse—none0/10

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

   ⚑ flag

Branching

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

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

   ClickHouse—none0/10

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

   ⚑ flag

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

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

   ClickHouse—none0/10

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

   ⚑ flag

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

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

   ClickHouse—none0/10

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

   ⚑ flag

Drivers

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

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

   ClickHouse—none0/10

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

   ⚑ flag

Latency

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

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

   ClickHouse—none0/10

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

   ⚑ flag

Pooling

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

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

   ClickHouse—none0/10

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

   ⚑ flag

Ai data

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

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

   ClickHouse✓fullclaimed7/10

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

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

   proof ↗⚑ flag

Analytics

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

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

   ClickHouse✓fullcommunity8/10

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

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

   proof ↗⚑ flag

Compatibility

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

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

   ClickHouse—none0/10

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

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

   proof ↗⚑ flag

Local loop

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

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

   ClickHouse✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse✓fullcommunity9/10

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

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

   proof ↗⚑ flag

Integrations

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

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

   ClickHouse—none0/10

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

   ⚑ flag

Migrations

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

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

   ClickHouse~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse—none0/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialprobed6/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse✓fullprobed7/10

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

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

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

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

   ClickHouse✓fullprobed8/10

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

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

   proof ↗⚑ flag

Cost controls

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

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

   ClickHouse~partialclaimed6/10

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

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

   proof ↗⚑ flag

Insights

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

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

   ClickHouse~partialclaimed2/10

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

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

   proof ↗⚑ flag

Pricing

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

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

   ClickHouse~partialclaimed6/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse~partialclaimed5/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse—none0/10

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

   ⚑ flag

2. ai-native userControl data retention and deletion

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

   ClickHouse—none0/10

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

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

   proof ↗⚑ flag

Availability

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

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

   ClickHouse~partialcommunity3/10

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

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

   proof ↗⚑ flag

Recovery

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

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

   ClickHouse~partialclaimed3/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse—none0/10

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

   ⚑ flag

Elasticity

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

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

   ClickHouse✓fullcommunity7/10

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

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

   proof ↗⚑ flag

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

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

   ClickHouse✓fullclaimed8/10

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

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

   proof ↗⚑ flag

Provisioning

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

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

   ClickHouse✓fullclaimed8/10

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

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

   proof ↗⚑ flag