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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   ClickHouse✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Neon✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   ClickHouse—none0/10

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

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Neon
   Neon~partialprobed6/10

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

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

   proof ↗⚑ flag

   ClickHouse—none0/10

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

   ⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Neon—none0/10

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

   ⚑ flag

   ClickHouse—none0/10

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

   ⚑ flag

Agentic features

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

   weight 2 · round to ClickHouse
   Neon—none0/10

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

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

   proof ↗⚑ flag

   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 ClickHouse
   Neon—none0/10

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

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

   proof ↗⚑ flag

   ClickHouse~partialclaimed4/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to ClickHouse
   Neon—none0/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Neon—none0/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Neon—none0/10

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

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

   proof ↗⚑ flag

   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
   Neon—none0/10

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

   ⚑ flag

   ClickHouse✓fullprobed7/10

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

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

   proof ↗⚑ flag

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

   weight 3 · round to ClickHouse
   Neon—none0/10

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

   ⚑ flag

   ClickHouse~partialclaimed4/10

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

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

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Neon—none0/10

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

   ⚑ flag

   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 drawn
   Neon—none0/10

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   ClickHouse—none0/10

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

   ⚑ flag

Drivers

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

   weight 2 · round to Neon
   Neon✓fullclaimed9/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Neon—none0/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   ClickHouse—none0/10

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

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

   proof ↗⚑ flag

Local loop

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

   weight 2 · round drawn
   Neon✓fullprobed8/10

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Neon—none0/10

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

   ⚑ flag

   ClickHouse—none0/10

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

   ⚑ flag

Migrations

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

   weight 1 · round to ClickHouse
   Neon—none0/10

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Neon—none0/10

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

   ⚑ flag

   ClickHouse~partialclaimed6/10

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

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

   proof ↗⚑ flag

Insights

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

   weight 2 · round to ClickHouse
   Neon—none0/10

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

   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
   Neon!disputedcontradicted4/10

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

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

   proof ↗⚑ flag

   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 drawn
   Neon—none0/10

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

   ⚑ flag

   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
   Neon—none0/10

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

   ⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

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

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

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

   proof ↗⚑ flag

   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