[ { "productId": "clickhouse", "storyId": "agent-provisions-database", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-17", "clickhouse-docs-20", "clickhouse-docs-31", "clickhouse-docs-32", "clickhouse-docs-5", "clickhouse-docs-6", "clickhouse-probe-3", "clickhouse-probe-4", "clickhouse-probe-5" ] }, { "productId": "clickhouse", "storyId": "agent-safe-sql-operations", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-5", "clickhouse-docs-6", "clickhouse-probe-4", "clickhouse-docs-4" ] }, { "productId": "clickhouse", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "clickhouse-probe-1", "clickhouse-docs-4", "clickhouse-docs-5" ] }, { "productId": "clickhouse", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-33", "clickhouse-docs-38" ] }, { "productId": "clickhouse", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-9", "clickhouse-docs-18", "clickhouse-docs-28", "clickhouse-docs-5", "clickhouse-docs-6", "clickhouse-docs-4", "clickhouse-docs-33" ] }, { "productId": "clickhouse", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-33", "clickhouse-docs-38", "clickhouse-docs-39" ] }, { "productId": "clickhouse", "storyId": "agentic-headless", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-1", "clickhouse-docs-15", "clickhouse-docs-23", "clickhouse-docs-27", "clickhouse-docs-14", "clickhouse-docs-19", "clickhouse-gh-1", "clickhouse-probe-5" ] }, { "productId": "clickhouse", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "ClickHouse is a database/analytics platform, not an agent or assistant that consumes external tools; the evidence shows ClickHouse *provides* an MCP server so AI assistants can query ClickHouse (the reverse direction), not that ClickHouse itself plugs in and uses external MCP servers as tools. This axis is a category mismatch for a database product.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-5", "clickhouse-docs-6", "clickhouse-probe-4" ] }, { "productId": "clickhouse", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-4", "clickhouse-docs-5", "clickhouse-docs-6", "clickhouse-docs-33", "clickhouse-probe-4" ] }, { "productId": "clickhouse", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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).", "evidenceIds": [ "clickhouse-docs-2", "clickhouse-docs-4", "clickhouse-docs-16", "clickhouse-docs-29", "clickhouse-docs-42", "clickhouse-probe-5" ] }, { "productId": "clickhouse", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "clickhouse-probe-1", "clickhouse-probe-3", "clickhouse-probe-4", "clickhouse-probe-5", "clickhouse-docs-5", "clickhouse-docs-6" ] }, { "productId": "clickhouse", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "analytical-queries", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-9", "clickhouse-docs-18", "clickhouse-docs-12", "clickhouse-comm-18", "clickhouse-comm-20", "clickhouse-comm-12", "clickhouse-comm-13", "clickhouse-comm-15", "clickhouse-comm-11", "clickhouse-comm-19" ] }, { "productId": "clickhouse", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-probe-3" ] }, { "productId": "clickhouse", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "clickhouse-probe-3", "clickhouse-probe-1" ] }, { "productId": "clickhouse", "storyId": "api-sandbox", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-1", "clickhouse-docs-15", "clickhouse-docs-16", "clickhouse-docs-29", "clickhouse-docs-35", "clickhouse-docs-27", "clickhouse-probe-5" ] }, { "productId": "clickhouse", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-13", "clickhouse-docs-14", "clickhouse-docs-19", "clickhouse-probe-3" ] }, { "productId": "clickhouse", "storyId": "automated-backups", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-22" ] }, { "productId": "clickhouse", "storyId": "automation-bulk-operations", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-10", "clickhouse-docs-13", "clickhouse-docs-18", "clickhouse-comm-18", "clickhouse-comm-19", "clickhouse-probe-4", "clickhouse-probe-5" ] }, { "productId": "clickhouse", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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).", "evidenceIds": [ "clickhouse-docs-9", "clickhouse-docs-18" ] }, { "productId": "clickhouse", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "autoscaling-under-load", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "clickhouse-docs-40", "clickhouse-docs-11", "clickhouse-docs-25", "clickhouse-docs-41", "clickhouse-docs-26", "clickhouse-docs-21", "clickhouse-comm-8", "clickhouse-comm-9" ] }, { "productId": "clickhouse", "storyId": "branch-reset-restore", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "builtin-connection-pooling", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "ci-preview-branches", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "cli-daily-workflow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-16", "clickhouse-docs-29", "clickhouse-docs-31", "clickhouse-docs-32", "clickhouse-docs-17", "clickhouse-docs-42", "clickhouse-probe-5", "clickhouse-docs-15", "clickhouse-docs-23" ] }, { "productId": "clickhouse", "storyId": "database-branching", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "engine-compatibility", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-20", "clickhouse-docs-31", "clickhouse-comm-19" ] }, { "productId": "clickhouse", "storyId": "fleet-per-agent-databases", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-3", "clickhouse-docs-20", "clickhouse-docs-25", "clickhouse-docs-41", "clickhouse-probe-5" ] }, { "productId": "clickhouse", "storyId": "free-tier-depth", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-23", "clickhouse-docs-27", "clickhouse-docs-35", "clickhouse-docs-25", "clickhouse-docs-41", "clickhouse-docs-11", "clickhouse-docs-26" ] }, { "productId": "clickhouse", "storyId": "global-low-latency", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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'.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "import-existing-database", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-7", "clickhouse-docs-28", "clickhouse-docs-43", "clickhouse-docs-31" ] }, { "productId": "clickhouse", "storyId": "instant-provisioning", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-3", "clickhouse-docs-17", "clickhouse-docs-20", "clickhouse-docs-26", "clickhouse-docs-40", "clickhouse-docs-41", "clickhouse-docs-11" ] }, { "productId": "clickhouse", "storyId": "local-keyless-engine", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-23", "clickhouse-docs-27", "clickhouse-docs-15", "clickhouse-docs-1", "clickhouse-gh-1", "clickhouse-comm-4" ] }, { "productId": "clickhouse", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-16", "clickhouse-docs-17", "clickhouse-docs-20", "clickhouse-docs-28", "clickhouse-docs-31", "clickhouse-docs-32", "clickhouse-docs-14", "clickhouse-docs-19", "clickhouse-probe-3", "clickhouse-docs-38", "clickhouse-docs-39" ] }, { "productId": "clickhouse", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-14", "clickhouse-docs-19", "clickhouse-docs-22", "clickhouse-docs-7", "clickhouse-docs-15", "clickhouse-docs-27" ] }, { "productId": "clickhouse", "storyId": "openness-open-license", "verdict": "full", "quality": 7, "confidence": "high", "rationale": "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'.", "evidenceIds": [ "clickhouse-probe-1", "clickhouse-gh-1" ] }, { "productId": "clickhouse", "storyId": "openness-self-host", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-23", "clickhouse-docs-27", "clickhouse-gh-1", "clickhouse-probe-1", "clickhouse-comm-9", "clickhouse-comm-10", "clickhouse-comm-19" ] }, { "productId": "clickhouse", "storyId": "orm-framework-compat", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "point-in-time-recovery", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "ClickHouse is a database/analytics engine, not an AI model provider or a service that trains models on user data; there is no evidence of any AI-training opt-out setting or policy in the pack, and this axis is a category mismatch for a database product rather than a gap it fails to fill.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-comm-19", "clickhouse-docs-22" ] }, { "productId": "clickhouse", "storyId": "privacy-telemetry-optout", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "ClickHouse is a database engine, not a SaaS/vendor service that phones home telemetry to the vendor by default; the evidence pack contains no mention of telemetry/usage-tracking settings at all, and this axis (opting out of vendor telemetry collection) is not a natural fit for an open-source, self-hosted-first database product's documented capabilities in this pack.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "query-insights", "verdict": "partial", "quality": 2, "confidence": "low", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-33", "clickhouse-docs-39" ] }, { "productId": "clickhouse", "storyId": "replicas-failover", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-44", "clickhouse-comm-2", "clickhouse-comm-13" ] }, { "productId": "clickhouse", "storyId": "safe-schema-changes", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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'.", "evidenceIds": [ "clickhouse-comm-16", "clickhouse-comm-19" ] }, { "productId": "clickhouse", "storyId": "scale-to-zero-idle", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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).", "evidenceIds": [ "clickhouse-docs-11", "clickhouse-docs-25", "clickhouse-docs-40", "clickhouse-docs-41", "clickhouse-docs-26" ] }, { "productId": "clickhouse", "storyId": "serverless-edge-driver", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "clickhouse", "storyId": "spend-caps-alerts", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-21", "clickhouse-docs-11", "clickhouse-docs-40", "clickhouse-docs-41" ] }, { "productId": "clickhouse", "storyId": "transparent-usage-pricing", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-11", "clickhouse-docs-21", "clickhouse-docs-25", "clickhouse-docs-40", "clickhouse-docs-41" ] }, { "productId": "clickhouse", "storyId": "vector-embeddings", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "clickhouse-docs-8", "clickhouse-docs-24", "clickhouse-docs-30", "clickhouse-docs-34" ] }, { "productId": "cockroachdb", "storyId": "agent-provisions-database", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Local provisioning and full SQL schema/query workflows are verified end-to-end via CLI (`cockroach demo` booted a keyless cluster and executed a real CREATE TABLE/INSERT/SELECT roundtrip with no cloud account), and CockroachDB Cloud has a dedicated `ccloud` CLI for creating/connecting clusters plus an official MCP server that supports natural-language table listing, statement execution, and row inserts. However, the managed MCP endpoint is OAuth-gated (401 requiring bearer auth against a protected resource), meaning cloud provisioning via MCP/API isn't fully dashboard-free without an auth setup step, and no REST/API spec was found (openapi probes all 404'd). Missing for 10: a demonstrated single continuous agent flow (create→connect→schema→query) purely through API or MCP without any OAuth/dashboard touchpoint, and a documented REST API surface.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-docs-10", "cockroachdb-docs-17", "cockroachdb-probe-rt-2", "cockroachdb-probe-rt-3", "cockroachdb-probe-3" ] }, { "productId": "cockroachdb", "storyId": "agent-safe-sql-operations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "CockroachDB Cloud ships an official MCP server (confirmed live and OAuth-gated in probe) that lets an agent run natural-language-driven SQL operations including listing tables, executing statements, and inserting rows, which supports the 'agent runs SQL via tools' half of the story. However, no evidence describes distinct scoped tools separating read-only from destructive/write actions, or any safety controls for delegation. Missing for 10: documented read-only vs. write/destructive tool separation, permission scoping or confirmation gates for destructive operations, and any independent hands-on account of using these MCP tools safely.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-probe-4", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "CockroachDB serves a working llms.txt at docs.cockroachlabs.com/llms.txt (HTTP 200, indexing 6364 pages) plus a docs/.md agent-oriented endpoint, both confirmed live via direct probes rather than just vendor claims. missing for 10: no independent/community confirmation that agents actually consume these endpoints successfully, and no OpenAPI spec (404s) to complement the docs for agent tooling.", "evidenceIds": [ "cockroachdb-probe-1", "cockroachdb-probe-2" ] }, { "productId": "cockroachdb", "storyId": "agentic-ai-insights", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "CockroachDB Cloud's official MCP server lets users issue natural-language prompts to query and manipulate data, and a runtime probe confirms the endpoint is live and OAuth-gated as documented, which enables AI-agent-driven exploration of data. However, this is a natural-language query interface, not a native AI insights/suggestions engine (e.g., automatic anomaly detection, recommended optimizations, or generated summaries) built into the product. Missing for 10: evidence of built-in generative insights/analytics beyond NL query passthrough, and independent hands-on validation of insight quality.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-probe-4", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "CockroachDB documents background data mechanisms like changefeeds and backups, but there is no evidence of an AI-native automation framework where an agent can configure tasks that run autonomously in the background; the MCP server evidence only covers interactive read/write operations, not scheduled or persistent automations.", "evidenceIds": [ "cockroachdb-docs-5", "cockroachdb-docs-6", "cockroachdb-docs-4", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence only shows CockroachDB Cloud's MCP server, which lets external AI agents connect to and query CockroachDB using natural language — this is CockroachDB acting as a tool for outside AI agents, not a built-in assistant inside the product to which a user delegates tasks. No evidence of an in-console AI assistant/copilot feature exists in the pack.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "The `cockroach demo` and `cockroach start-single-node` commands can run entirely headlessly with no interactive shell or account (verified by a runtime probe executing SQL via `-e` flag, offline, insecure mode), and CockroachDB installs via simple package managers (brew) suitable for CI pipelines. missing for 10: no explicit CI recipe/Docker/GitHub Actions example in docs, and no independent CI-integration case study.", "evidenceIds": [ "cockroachdb-probe-rt-1", "cockroachdb-probe-rt-2", "cockroachdb-docs-1", "cockroachdb-docs-2", "cockroachdb-docs-21" ] }, { "productId": "cockroachdb", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "CockroachDB is a database; the evidence shows it ships an MCP *server* (docs-4, probe-4, probe-rt-3) so AI agents can call into CockroachDB Cloud, which is the opposite direction of this story (the product acting as an MCP *client* that plugs in and consumes other servers' tools). Databases are not agentic actors that consume MCP tool servers, so this axis is a category error for this product type.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-probe-4", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "CockroachDB Cloud offers an official, documented MCP server enabling natural-language agent interactions (listing tables, executing statements, inserting rows), and a runtime probe confirms the endpoint is live and OAuth-gated exactly as documented. Missing for 10: independent/community hands-on validation of agent workflows beyond first-party docs and probes, and details on feature completeness/limits of the MCP server's tool surface.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-probe-4", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "CockroachDB Cloud ships an official MCP server that explicitly lets users issue natural-language prompts to list tables, execute statements, and insert rows, and a runtime probe confirms the documented MCP endpoint is live and OAuth-gated exactly as described. This is a direct, first-party natural-language interface to database operations rather than just NL-to-SQL translation elsewhere. Missing for 10: independent/hands-on evidence of an actual successful NL command being executed end-to-end (beyond auth handshake), and confirmation that this capability extends to self-hosted (non-Cloud) CockroachDB deployments.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-probe-4", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-official-cli", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "CockroachDB ships an official `cockroach` CLI (demo, start, sql shell) verified via runtime probes performing real SQL roundtrips, plus a separate `ccloud` CLI for cloud cluster management, both documented and hands-on confirmed. This is a general-purpose DB CLI rather than one purpose-built for AI-native/agentic workflows, though the product does offer an MCP server for natural-language agent interaction as a complementary path. Missing for 10: CLI features explicitly marketed toward AI-agent automation (e.g., structured/JSON output modes tailored for agent consumption, agent-specific CLI subcommands) and independent third-party corroboration of ccloud CLI usage.", "evidenceIds": [ "cockroachdb-docs-5", "cockroachdb-docs-10", "cockroachdb-docs-17", "cockroachdb-probe-5", "cockroachdb-probe-rt-1", "cockroachdb-probe-rt-2" ] }, { "productId": "cockroachdb", "storyId": "agentic-public-api", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "CockroachDB exposes a well-documented, driver-agnostic PostgreSQL wire protocol (verified live via `cockroach demo` running real SQL) plus a documented MCP server for natural-language driving of read/write operations, both confirmed live in the probes. However, there is no discoverable OpenAPI/REST spec (all candidate paths 404), so a fully machine-readable HTTP API for cloud/cluster management is absent — missing for 10: a public OpenAPI/REST spec for cluster administration, independent hands-on confirmation of the MCP server's read/write actions beyond the documented claim.", "evidenceIds": [ "cockroachdb-gh-1", "cockroachdb-docs-4", "cockroachdb-probe-3", "cockroachdb-probe-4", "cockroachdb-probe-rt-1", "cockroachdb-probe-rt-2", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-scoped-keys", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence shows CockroachDB's Cloud MCP server is gated by OAuth (401 + WWW-Authenticate Bearer, resource_metadata endpoint) and that SQL-level roles exist in general, but nothing in the pack documents an actual mechanism for issuing scoped, least-privilege API credentials specifically for an AI agent (e.g., agent-specific API keys, granular OAuth scopes, or role templates for automated clients). Missing for 10: documentation of scoped credential/token issuance workflow for agents, evidence of least-privilege role templates tied to the MCP/API surface, and any hands-on confirmation that such scoping works as intended.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-probe-rt-3" ] }, { "productId": "cockroachdb", "storyId": "agentic-sdks", "verdict": "partial", "quality": 3, "confidence": "medium", "rationale": "CockroachDB doesn't maintain distinct official SDKs; it relies on PostgreSQL wire-protocol compatibility so any standard Postgres client library works, which is documented, but there is no evidence of CockroachDB-branded official SDKs for Python/Go/Java/etc. or AI-agent-specific SDK tooling. missing for 10: dedicated first-party SDKs beyond Postgres driver compatibility, independent corroboration of official SDK maintenance, and any SDK docs targeting AI-native/agentic use cases.", "evidenceIds": [ "cockroachdb-gh-1", "cockroachdb-comm-13" ] }, { "productId": "cockroachdb", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence only shows CockroachDB changefeeds with at-least-once delivery guarantees (cockroachdb-docs-5), but no citation explicitly confirms webhook sinks or a webhook subscription mechanism as part of the changefeed feature; older community comments even note the lack of a 'change notification' mechanism. Missing for 10: explicit documentation of webhook sink configuration, webhook payload/auth setup, and any hands-on confirmation of webhook delivery.", "evidenceIds": [ "cockroachdb-docs-5", "cockroachdb-comm-12" ] }, { "productId": "cockroachdb", "storyId": "analytical-queries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers CockroachDB's OLTP features (ACID transactions, backups, changefeeds, multi-region, vector indexes) but contains no mention of analytical/OLAP acceleration, columnar execution, materialized views, or benchmarks showing fast large-table aggregation performance suitable for dashboards. Nothing addresses avoiding a separate warehouse for analytics. missing for 10: any documentation of analytical query performance, columnar/vectorized execution engine, dashboard-scale aggregation benchmarks, or HTAP-specific tooling.", "evidenceIds": [] }, { "productId": "cockroachdb", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "CockroachDB documents SQL reference, quickstarts, and an interactive `cockroach demo` shell, but there is no evidence of an interactive API reference (e.g., an OpenAPI/Swagger-style explorer with runnable examples) — the openapi probe explicitly found all candidate spec paths returning 404. This axis is plausible for a database's developer docs site, so the absence of evidence yields 'none' rather than 'na'.", "evidenceIds": [ "cockroachdb-probe-3" ] }, { "productId": "cockroachdb", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "CockroachDB Cloud does offer a management API/CLI, but the evidence pack shows an explicit probe for a machine-readable API spec (openapi.json, swagger.json, etc.) at the docs domain returning 404 on every candidate path, and no other citation surfaces an OpenAPI or equivalent spec anywhere in the docs or cloud console.", "evidenceIds": [ "cockroachdb-probe-3" ] }, { "productId": "cockroachdb", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "`cockroach demo` spins up a temporary, in-memory, single-node/multi-node cluster with a real interactive SQL shell that runs entirely offline with no cloud account, letting an AI-native user run test queries/CRUD without touching production data — confirmed by both docs and a hands-on runtime probe showing a full CREATE/INSERT/SELECT roundtrip. missing for 10: independent third-party corroboration beyond vendor docs/probe, and explicit documentation tying this sandbox workflow specifically to AI-agent/MCP-driven testing rather than manual SQL shell use.", "evidenceIds": [ "cockroachdb-docs-1", "cockroachdb-docs-2", "cockroachdb-probe-rt-2" ] }, { "productId": "cockroachdb", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no documentation of API versioning schemes or a deprecation policy for CockroachDB's SQL/client APIs, MCP server, or Cloud APIs. While such a policy is plausible for a database product (SQL compatibility, wire protocol versions, Cloud API), nothing in the provided evidence addresses it, so it cannot be credited.", "evidenceIds": [] }, { "productId": "cockroachdb", "storyId": "automated-backups", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Docs describe full/incremental backups and point-in-time restore as available features (cockroachdb-docs-6, cockroachdb-docs-15), but there's no evidence of a visible/configurable backup schedule UI or self-serve founder-facing controls, and community reports concretely contradict self-serve availability: 'backup/restore feature... is currently locked behind their enterprise version' and 'the old licensing model was pretty brutal if you required any enterprise features (ex: incremental backup)' — meaning for a founder on the free/core tier, backups may not be truly self-serve or automatic. Missing for 10: evidence of a schedule visibility/config UI, confirmation that free-tier founders get automatic scheduled backups without enterprise licensing, and independent hands-on confirmation of restore self-service.", "evidenceIds": [ "cockroachdb-docs-6", "cockroachdb-docs-15", "cockroachdb-comm-8", "cockroachdb-comm-1" ] }, { "productId": "cockroachdb", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "CockroachDB is a distributed SQL database and standard SQL/Postgres-compatible clients naturally support batch INSERTs, transactions, and bulk import/export via backup-restore, but the evidence pack has no explicit documentation of bulk/batch operations (e.g., IMPORT, multi-row INSERT, bulk API) and the MCP server docs only mention inserting single rows via natural language rather than bulk multi-item operations. Missing for 10: explicit bulk-insert/IMPORT documentation, evidence of the MCP or CLI performing multi-item bulk operations in one call, and independent confirmation of bulk-operation performance at scale.", "evidenceIds": [ "cockroachdb-docs-4", "cockroachdb-docs-6", "cockroachdb-gh-1" ] }, { "productId": "cockroachdb", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "CockroachDB offers changefeeds (CDC) that emit ordered, at-least-once delivery events to external systems, which can be used to build event-driven automation outside the database, but there is no evidence of a native rule/trigger engine that itself defines conditions and executes actions in response to events. missing for 10: native trigger/rule syntax, conditional action execution inside CockroachDB, documented automation examples beyond raw change-event streaming.", "evidenceIds": [ "cockroachdb-docs-5" ] }, { "productId": "cockroachdb", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers backups, restore, changefeeds, MCP connectivity, and cluster management, but nothing describes a scheduling mechanism for recurring jobs or workflows (e.g., cron-like scheduled SQL/backup jobs) that an AI-native user could invoke. Since database products plausibly could offer such scheduling (e.g., scheduled backups), the axis applies, but no evidence documents it here.", "evidenceIds": [] }, { "productId": "cockroachdb", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "cockroachdb", "storyId": "autoscaling-under-load", "verdict": "partial", "quality": 5, "confidence": "low", "rationale": "CockroachDB Cloud's Serverless/Basic tier documents automatic request-unit scaling, including scale-to-zero on inactivity, which aligns with autoscaling compute without manual resizing. However, evidence is thin on how it scales up under load or guarantees against downtime, and CockroachDB's core distributed architecture (self-hosted) generally requires manual node provisioning for scaling, so this capability is specific to the managed cloud tier only. missing for 10: detailed scale-up mechanics/limits, evidence of zero-downtime during scale events, independent/hands-on confirmation of autoscaling behavior under real load.", "evidenceIds": [ "cockroachdb-docs-18", "cockroachdb-docs-22", "cockroachdb-docs-9", "cockroachdb-docs-19" ] }, { "productId": "cockroachdb", "storyId": "branch-reset-restore", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack covers CockroachDB's backup/restore and point-in-time restore features but contains no mention of a 'branch' concept, branch creation, or resetting a branch from its parent — capabilities central to this story. Since database branching is a reasonable feature category for a modern SQL database to offer, its total absence here means the story is unmet rather than out-of-category.", "evidenceIds": [ "cockroachdb-docs-6", "cockroachdb-docs-15" ] }, { "productId": "cockroachdb", "storyId": "builtin-connection-pooling", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows CockroachDB supports the Postgres wire protocol and various client drivers, but nowhere documents a built-in connection pooler (equivalent to pgbouncer) that manages thousands of concurrent client connections. No mention of connection pooling, session multiplexing, or proxy-replacement architecture appears in any docs, community, or probe items.", "evidenceIds": [ "cockroachdb-gh-1", "cockroachdb-docs-13" ] }, { "productId": "cockroachdb", "storyId": "ci-preview-branches", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a branching feature (e.g., copy-on-write database branches per PR) or CI/deploy-platform integration for automated branch creation/teardown; only unrelated capabilities like `cockroach demo` (ephemeral in-memory instance) and ccloud cluster creation are documented, neither of which supports per-PR branch lifecycle automation.", "evidenceIds": [ "cockroachdb-docs-1", "cockroachdb-docs-10", "cockroachdb-docs-17" ] }, { "productId": "cockroachdb", "storyId": "cli-daily-workflow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "The `cockroach` CLI covers the daily loop: `cockroach demo`/`cockroach start-single-node` create and connect to a cluster with an interactive SQL shell, verified hands-on via runtime probes showing a keyless install and real SQL roundtrip entirely offline. Docs and probes confirm install (brew), demo/shell, and Postgres-wire-protocol connectivity for inspection via any SQL client. Missing for 10: independent (non-vendor) third-party validation of the full CLI daily loop beyond the single runtime probe, and explicit CLI subcommand documentation for 'inspect' beyond SQL shell usage.", "evidenceIds": [ "cockroachdb-docs-1", "cockroachdb-docs-2", "cockroachdb-docs-21", "cockroachdb-probe-5", "cockroachdb-probe-rt-1", "cockroachdb-probe-rt-2" ] }, { "productId": "cockroachdb", "storyId": "database-branching", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a copy-on-write branching feature for schema+data in CockroachDB; the pack only shows backups/restores, demo clusters, and single-node dev instances, none of which provide instant branchable copies of production data.", "evidenceIds": [] }, { "productId": "cockroachdb", "storyId": "engine-compatibility", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "CockroachDB documents and demonstrates real PostgreSQL wire-protocol compatibility (standard pg drivers work, `cockroach demo` runs actual SQL round-trips) rather than a toy subset, but hands-on community reports concretely contradict 'full' Postgres compatibility — e.g. missing array columns ('it lacks array columns, which Postgres supports') and, historically, missing change-notification/CDC — meaning code written against real Postgres dialect features can break. There is no MySQL or SQLite dialect compatibility at all, only Postgres. Missing for 10: MySQL/SQLite compatibility, resolution of the array-column and other documented Postgres feature gaps, and independent verification that these gaps are now closed.", "evidenceIds": [ "cockroachdb-gh-1", "cockroachdb-docs-13", "cockroachdb-probe-rt-2", "cockroachdb-comm-13", "cockroachdb-comm-12" ] }, { "productId": "cockroachdb", "storyId": "fleet-per-agent-databases", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "CockroachDB Cloud offers a programmatic CLI (`ccloud`) for creating/managing clusters and serverless billing that scales to zero when idle, which could support cost-efficient per-tenant provisioning, and `cockroach demo`/single-node clusters show lightweight instance creation is possible. However there is no evidence of a purpose-built mechanism for creating thousands of cheap, isolated databases (e.g., per-agent/tenant sandboxes) or bulk/programmatic fleet management at that scale. Missing for 10: evidence of bulk/batch database creation APIs, per-database cost/isolation guarantees at thousands-scale, and documented tenant-isolation patterns for AI-agent workflows.", "evidenceIds": [ "cockroachdb-docs-10", "cockroachdb-docs-17", "cockroachdb-docs-18", "cockroachdb-docs-1", "cockroachdb-probe-rt-2" ] }, { "productId": "cockroachdb", "storyId": "free-tier-depth", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "CockroachDB offers a genuinely free local path (open-source binary, `cockroach demo` running real SQL with no account per probe-rt-1/rt-2) plus a Cloud free trial with $400 credit and serverless scale-to-zero billing (docs-8, docs-25, docs-18), which supports real prototyping. However, community reports concretely contradict full 'free tier usability' — free/core users still need an annual license key, and key features prototypers would want (incremental backup/restore, CDC, follower-reads) are locked behind the paid Enterprise tier, pushing some users back to Postgres (comm-4, comm-8, comm-9). missing for 10: evidence that backup/restore, CDC, and other blocked features are truly available for free, and confirmation the license-key requirement doesn't undermine 'free' framing.", "evidenceIds": [ "cockroachdb-docs-8", "cockroachdb-docs-25", "cockroachdb-docs-18", "cockroachdb-probe-rt-1", "cockroachdb-probe-rt-2", "cockroachdb-comm-4", "cockroachdb-comm-8", "cockroachdb-comm-9" ] }, { "productId": "cockroachdb", "storyId": "global-low-latency", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "CockroachDB's docs describe explicit multi-region primitives—survival goals and table locality—for placing data/replicas close to users to reduce latency, plus survives datacenter failures with minimal latency disruption, directly matching the story. Missing for 10: independent latency benchmarks confirming real-world regional read-latency improvements, and community comments (comm-2) note multi-region can be restricted under certain licensing tiers, which is a real-world caveat on availability of the feature.", "evidenceIds": [ "cockroachdb-docs-7", "cockroachdb-docs-16", "cockroachdb-docs-24", "cockroachdb-docs-14", "cockroachdb-docs-20", "cockroachdb-comm-2" ] }, { "productId": "cockroachdb", "storyId": "import-existing-database", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "The docs index references a dedicated 'Migrate' / migration-overview page (MOLT) suggesting a documented migration path exists, but the evidence pack contains no actual content describing minimal-downtime steps, replication/cutover tooling, or verified success stories. Missing for 10: detailed migration guide content, explanation of minimal-downtime mechanics (e.g., live migration/replication tooling), and independent/hands-on confirmation of a low-downtime cutover.", "evidenceIds": [ "cockroachdb-docs-12" ] }, { "productId": "cockroachdb", "storyId": "instant-provisioning", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "CockroachDB ships both `cockroach demo` (verified live in a runtime probe to instantly spin up a keyless in-memory cluster with real SQL roundtrip) and the `ccloud quickstart` CLI which interactively creates a CockroachDB Serverless/Basic cluster with request-unit billing that scales to zero, removing the need for capacity planning. Docs also describe a free-trial quickstart flow for going from zero to a connected cluster in seconds via CLI. missing for 10: no runtime probe verifying the cloud `ccloud quickstart` actually provisions a ready-to-connect serverless cluster (only local `cockroach demo` was runtime-tested), and no first-class REST/API path for cluster creation beyond the CLI is evidenced.", "evidenceIds": [ "cockroachdb-docs-17", "cockroachdb-docs-18", "cockroachdb-docs-10", "cockroachdb-docs-8", "cockroachdb-probe-rt-2", "cockroachdb-docs-2" ] }, { "productId": "cockroachdb", "storyId": "local-keyless-engine", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "CockroachDB ships as a downloadable binary (brew install) and `cockroach demo`/single-node start modes that spin up a full in-memory or local cluster with an interactive SQL shell, requiring no account, license key entry, or cloud dependency; a runtime probe confirms a keyless offline SQL roundtrip actually executed. This directly satisfies local/offline dev and CI use since the same open-source engine runs identically to production.\n\nmissing for 10: explicit first-party documentation or example of wiring `cockroach demo`/single-node mode into a CI pipeline, and independent (non-vendor) confirmation of CI usage.", "evidenceIds": [ "cockroachdb-docs-1", "cockroachdb-docs-2", "cockroachdb-docs-21", "cockroachdb-probe-rt-1", "cockroachdb-probe-rt-2" ] }, { "productId": "cockroachdb", "storyId": "openness-api-parity", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "CockroachDB exposes core capabilities via SQL (Postgres wire protocol), a CLI (`ccloud`) for cluster creation/management, and an MCP server for natural-language read/write operations, giving API-level parity for data operations and basic cluster admin. However the evidence pack shows Cloud Console-specific features (cost estimation, resource-usage dashboards, cluster overview page) documented only as UI pages with no confirmed API/CLI equivalent, and no general REST/OpenAPI surface was found (probe for openapi.json returned 404s). Missing for 10: documented Cloud API/REST parity for console-only features like billing/cost estimates and resource monitoring, and confirmation that all UI actions are scriptable via API.", "evidenceIds": [ "cockroachdb-docs-10", "cockroachdb-docs-17", "cockroachdb-docs-4", "cockroachdb-probe-rt-3", "cockroachdb-probe-3", "cockroachdb-docs-9", "cockroachdb-docs-19" ] }, { "productId": "cockroachdb", "storyId": "openness-full-export", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "CockroachDB docs describe full/incremental backup and restore plus PostgreSQL wire-protocol compatibility, which could support exporting data in open, portable formats, but community hands-on reports state the backup/restore feature (needed to actually get data out) was 'locked behind their enterprise version' for non-paying users, directly undercutting a free, no-strings ability to export and leave. Additional community feedback notes real PostgreSQL-compatibility gaps (e.g., no array columns) limiting true open-format portability. Missing for 10: a documented open/standard export format (e.g., SQL dump, CSV) freely available without enterprise licensing, and confirmation that exports are usable outside CockroachDB without vendor lock-in.", "evidenceIds": [ "cockroachdb-docs-6", "cockroachdb-docs-15", "cockroachdb-comm-8", "cockroachdb-comm-13", "cockroachdb-gh-1" ] }, { "productId": "cockroachdb", "storyId": "openness-open-license", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "CockroachDB's source is published on GitHub (cockroachdb-gh-1), which superficially satisfies 'read the source', but community evidence indicates the licensing model is restrictive rather than a clean open license — users report needing an annual license key even as free users and enterprise features gated behind licensing (cockroachdb-comm-4, cockroachdb-comm-1, cockroachdb-comm-8). This contradicts a straightforward 'open license' claim. Missing for 10: explicit license text/OSI-approval evidence, confirmation that ALL source (not just visible code) is under a recognized open-source license, and resolution of the license-key requirement contradiction.", "evidenceIds": [ "cockroachdb-gh-1", "cockroachdb-comm-1", "cockroachdb-comm-4", "cockroachdb-comm-8" ] }, { "productId": "cockroachdb", "storyId": "openness-self-host", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "CockroachDB core is open-source and can be installed and run entirely locally without any cloud account, verified by runtime probes showing brew install and cockroach demo/single-node clusters running full SQL workloads offline and keylessly. Docs also describe single-node and multi-node self-hosted deployment options. missing for 10: independent third-party confirmation of full multi-node self-hosted cluster beyond demo mode, and clarity on which enterprise features require licensing when self-hosted (per community complaints about backup/CDC being enterprise-gated).", "evidenceIds": [ "cockroachdb-probe-rt-1", "cockroachdb-probe-rt-2", "cockroachdb-docs-2", "cockroachdb-docs-21", "cockroachdb-docs-1" ] }, { "productId": "cockroachdb", "storyId": "orm-framework-compat", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "CockroachDB advertises PostgreSQL wire-protocol compatibility, implying general compatibility with Postgres-based ORMs/drivers, but the evidence pack contains no documented, ORM-specific guides (Prisma, Drizzle, Django, Rails) and one community report notes incompatibilities (missing array columns) that break real-world Postgres-client usage. missing for 10: dedicated official guides for Prisma, Drizzle, Django, and Rails integration, and confirmation that ORM-specific features work without workarounds.", "evidenceIds": [ "cockroachdb-gh-1", "cockroachdb-comm-13" ] }, { "productId": "cockroachdb", "storyId": "point-in-time-recovery", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm full/incremental backups with revision history enabling restore to an arbitrary point in time within the backup window (docs-6, docs-15), directly matching the 'restore to any point in time' part of the story. However, there is no evidence of a database-branching capability (e.g., cloning a live copy at a timestamp for testing), and community reports note that backup/restore (and other reliability features) are gated behind enterprise licensing, adding a real cost/access caveat (comm-8, comm-1). Missing for 10: evidence of branching/cloning functionality, and confirmation that PITR restore is available outside enterprise tier.", "evidenceIds": [ "cockroachdb-docs-6", "cockroachdb-docs-15", "cockroachdb-comm-8", "cockroachdb-comm-1" ] }, { "productId": "cockroachdb", "storyId": "privacy-data-residency", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "CockroachDB's multi-region docs (survival goals, table locality) explicitly let you place data by region, which is what data residency requires — but community reports (comm-2) note that region/residency-only features have at times been gated to enterprise/paid tiers, adding a real caveat that data residency 'is the whole point' but can be restricted depending on license/tier. Missing for 10: independent/hands-on confirmation of granular region pinning in practice, and clarity on which specific product tier includes full multi-region/residency controls.", "evidenceIds": [ "cockroachdb-docs-7", "cockroachdb-docs-16", "cockroachdb-docs-24", "cockroachdb-comm-2" ] }, { "productId": "cockroachdb", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of any AI-model-training opt-out, data-usage policy, or privacy commitment regarding customer data being used to train AI models. CockroachDB Cloud does handle customer data and has AI-adjacent features (natural-language MCP interface), so the axis is a fair question for the product, but no documentation or community evidence addresses this specific privacy control. missing for 10: any documented policy on AI-training data usage, opt-out mechanism, or explicit privacy statement about model training.", "evidenceIds": [] }, { "productId": "cockroachdb", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Evidence shows backup/restore and point-in-time restore capabilities (cockroachdb-docs-6, cockroachdb-docs-15), and standard SQL access via Postgres wire protocol implies DELETE/DROP support (cockroachdb-gh-1), but there is no explicit documentation in this pack of retention policies, row-level TTL, or data deletion/purge controls tailored for AI-native privacy needs. missing for 10: explicit TTL/retention-policy docs, GDPR-style delete-on-request tooling, data lifecycle management guidance.", "evidenceIds": [ "cockroachdb-docs-6", "cockroachdb-docs-15", "cockroachdb-gh-1" ] }, { "productId": "cockroachdb", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence in the pack shows a documented telemetry opt-out mechanism; instead, community feedback explicitly states the telemetry is mandatory ('the only thing I don't like is the mandatory telemetry'), indicating no user-facing opt-out exists.", "evidenceIds": [ "cockroachdb-comm-3" ] }, { "productId": "cockroachdb", "storyId": "query-insights", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Docs reference a resource-usage page that helps 'find and optimize queries and processes that may be consuming excessive resources' and a Clusters overview page, hinting at some performance monitoring, but there's no evidence of a dedicated built-in insights view naming slow queries or explicit index recommendations. Missing for 10: documentation of a specific 'Insights' or performance-insights UI, evidence of index recommendation output, and independent/hands-on confirmation of these features actually surfacing in the console.", "evidenceIds": [ "cockroachdb-docs-11", "cockroachdb-docs-19" ] }, { "productId": "cockroachdb", "storyId": "replicas-failover", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "CockroachDB's docs clearly document automatic replication and failover: it 'survives disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention,' with configurable multi-region survival goals and table locality, which functions as its answer to read-replica/HA needs. However, CockroachDB is architecturally a distributed consensus database rather than a primary/read-replica system, and community reports note that follower-reads (the closest analog to 'read replicas' for read scaling) were moved behind an enterprise license, which a platform engineer would need to navigate. Missing for 10: explicit 'read replica' terminology/setup guide, independent verification of failover behavior in production, and clarity on which HA/read-scaling features require paid tiers.", "evidenceIds": [ "cockroachdb-docs-14", "cockroachdb-docs-20", "cockroachdb-docs-7", "cockroachdb-docs-16", "cockroachdb-comm-9" ] }, { "productId": "cockroachdb", "storyId": "safe-schema-changes", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of online DDL, schema-change safety, migration tooling, or branch/merge workflows for schema changes — topics like backups, changefeeds, multiregion survival, and MCP/CLI tools are covered but schema migration safety is entirely absent. Missing for 10: any documentation or community evidence of online/non-blocking schema changes, migration CLI/tooling, or safe rollout mechanisms for DDL.", "evidenceIds": [] }, { "productId": "cockroachdb", "storyId": "scale-to-zero-idle", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "CockroachDB Cloud's Serverless/Basic tier explicitly scales Request Unit consumption to zero when idle, while data remains durably stored and billed only for storage, directly matching the story of a free-when-idle prototype database. Docs also show a $400 free trial credit and cluster management dashboards for tracking usage, reinforcing the cost-to-zero model for founders/side projects.\n\nMissing for 10: independent/hands-on confirmation of actual $0 billing behavior during idle periods, and no community reports validating the scale-to-zero claim in practice (only docs-level evidence).", "evidenceIds": [ "cockroachdb-docs-18", "cockroachdb-docs-22", "cockroachdb-docs-8", "cockroachdb-docs-25", "cockroachdb-docs-9" ] }, { "productId": "cockroachdb", "storyId": "serverless-edge-driver", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "CockroachDB supports the standard PostgreSQL wire protocol via TCP connections and any Postgres driver, but there is no evidence of an official HTTP/WebSocket driver designed for stateless, short-lived serverless/edge function connections (unlike e.g. Neon's serverless driver). No documentation or product mentions this capability.", "evidenceIds": [ "cockroachdb-gh-1", "cockroachdb-comm-13" ] }, { "productId": "cockroachdb", "storyId": "spend-caps-alerts", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "CockroachDB Cloud provides Request Unit usage monitoring and a monthly cost estimate/extrapolation tool, plus a 'diagnose and optimize resource consumption' guide, giving founders some visibility into spend before a bill arrives. However, there is no evidence of an actual configurable spend cap or proactive usage alert/notification mechanism (e.g., budget thresholds that trigger emails or auto-throttling) — the pack only shows passive dashboards and estimates. Missing for 10: documented spend-cap/budget-limit feature, documented usage-threshold alerting/notifications, and any hands-on confirmation these prevent runaway bills.", "evidenceIds": [ "cockroachdb-docs-9", "cockroachdb-docs-11", "cockroachdb-docs-22", "cockroachdb-docs-18" ] }, { "productId": "cockroachdb", "storyId": "transparent-usage-pricing", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Evidence shows CockroachDB Cloud tracks Request Unit usage and provides a monthly cost *estimate* tool, plus free trial credits, but no evidence pack item publishes actual per-unit dollar rates for compute, storage, or traffic that a founder could use to predict a bill in advance. Community comments even highlight surprise/confusion about cost (e.g., being quoted 10x pricier than alternatives), suggesting pricing isn't transparently published upfront.", "evidenceIds": [ "cockroachdb-docs-9", "cockroachdb-docs-18", "cockroachdb-docs-22", "cockroachdb-comm-5" ] }, { "productId": "cockroachdb", "storyId": "vector-embeddings", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "CockroachDB documents a native VECTOR type and vector indexes supporting efficient approximate nearest neighbor (ANN) search on high-dimensional columns, compatible with the pgvector extension, meaning developers can store embeddings and run similarity search directly in CockroachDB without a separate vector DB. Missing for 10: hands-on/independent corroboration of vector search performance or real-world usage reports, and no community discussion validating this feature in practice.", "evidenceIds": [ "cockroachdb-docs-3", "cockroachdb-docs-23" ] }, { "productId": "neon", "storyId": "agent-provisions-database", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-11", "neon-docs-12", "neon-docs-20", "neon-probe-3", "neon-probe-4", "neon-probe-5", "neon-probe-rt-1", "neon-probe-rt-2" ] }, { "productId": "neon", "storyId": "agent-safe-sql-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-12", "neon-docs-33", "neon-probe-4", "neon-probe-rt-2", "neon-docs-11", "neon-probe-rt-1" ] }, { "productId": "neon", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-probe-1", "neon-probe-2" ] }, { "productId": "neon", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-5", "neon-docs-15", "neon-docs-33" ] }, { "productId": "neon", "storyId": "agentic-autonomous-automation", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-3", "neon-docs-12", "neon-probe-rt-2" ] }, { "productId": "neon", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-5", "neon-docs-21", "neon-docs-12", "neon-docs-33" ] }, { "productId": "neon", "storyId": "agentic-headless", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-11", "neon-docs-34", "neon-docs-20", "neon-docs-38", "neon-docs-18", "neon-docs-35", "neon-probe-5", "neon-probe-rt-1" ] }, { "productId": "neon", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Neon is a database platform, not an agentic client application — the story asks whether Neon can consume external MCP servers' tools, which is a category mismatch. Evidence instead shows Neon ships an official MCP *server* (neon-docs-12/33, neon-probe-4) for other agents to use, i.e. the reverse role, so this client-side axis does not apply.", "evidenceIds": [] }, { "productId": "neon", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-12", "neon-docs-33", "neon-probe-4", "neon-probe-rt-2" ] }, { "productId": "neon", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-33", "neon-docs-34", "neon-probe-4", "neon-probe-5", "neon-probe-rt-1", "neon-probe-rt-2" ] }, { "productId": "neon", "storyId": "agentic-official-cli", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-11", "neon-docs-34", "neon-probe-5", "neon-probe-rt-1" ] }, { "productId": "neon", "storyId": "agentic-public-api", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-20", "neon-docs-38", "neon-probe-3", "neon-probe-1", "neon-probe-2" ] }, { "productId": "neon", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "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.", "evidenceIds": [ "neon-probe-rt-2", "neon-docs-22", "neon-docs-20", "neon-docs-33" ] }, { "productId": "neon", "storyId": "agentic-sdks", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-14", "neon-docs-20", "neon-probe-3", "neon-docs-11", "neon-docs-12" ] }, { "productId": "neon", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "analytical-queries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-16", "neon-docs-10", "neon-docs-13", "neon-comm-2", "neon-comm-3" ] }, { "productId": "neon", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-20", "neon-docs-38", "neon-probe-3" ] }, { "productId": "neon", "storyId": "api-machine-spec", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-probe-3", "neon-docs-20", "neon-docs-38" ] }, { "productId": "neon", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-25", "neon-comm-10", "neon-docs-8", "neon-docs-22", "neon-docs-1" ] }, { "productId": "neon", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-20", "neon-docs-38", "neon-probe-3" ] }, { "productId": "neon", "storyId": "automated-backups", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-8", "neon-docs-29", "neon-docs-25" ] }, { "productId": "neon", "storyId": "automation-bulk-operations", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "automation-versioned-workflows", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "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.)", "evidenceIds": [] }, { "productId": "neon", "storyId": "autoscaling-under-load", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-9", "neon-docs-10", "neon-docs-26", "neon-docs-27", "neon-comm-6", "neon-comm-1" ] }, { "productId": "neon", "storyId": "branch-reset-restore", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-8", "neon-docs-29", "neon-docs-25", "neon-comm-10" ] }, { "productId": "neon", "storyId": "builtin-connection-pooling", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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).", "evidenceIds": [ "neon-docs-13", "neon-docs-30" ] }, { "productId": "neon", "storyId": "ci-preview-branches", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-25", "neon-docs-18", "neon-docs-20", "neon-docs-11", "neon-comm-10" ] }, { "productId": "neon", "storyId": "cli-daily-workflow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-11", "neon-docs-34", "neon-probe-5", "neon-probe-rt-1", "neon-gh-1" ] }, { "productId": "neon", "storyId": "database-branching", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-25", "neon-docs-8", "neon-docs-1", "neon-comm-10" ] }, { "productId": "neon", "storyId": "engine-compatibility", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-gh-1", "neon-gh-5", "neon-docs-15", "neon-comm-11", "neon-comm-2", "neon-comm-3" ] }, { "productId": "neon", "storyId": "fleet-per-agent-databases", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-25", "neon-docs-22", "neon-docs-20", "neon-docs-11", "neon-docs-9", "neon-docs-6", "neon-comm-6", "neon-comm-10" ] }, { "productId": "neon", "storyId": "free-tier-depth", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-24", "neon-docs-6", "neon-comm-1", "neon-comm-6" ] }, { "productId": "neon", "storyId": "global-low-latency", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "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.", "evidenceIds": [ "neon-docs-16", "neon-docs-28", "neon-comm-2", "neon-comm-3" ] }, { "productId": "neon", "storyId": "import-existing-database", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "instant-provisioning", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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.", "evidenceIds": [ "neon-docs-11", "neon-docs-20", "neon-gh-2", "neon-comm-6", "neon-docs-9", "neon-docs-10", "neon-probe-5", "neon-probe-3" ] }, { "productId": "neon", "storyId": "local-keyless-engine", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-gh-3", "neon-gh-4", "neon-gh-8", "neon-gh-5", "neon-docs-17", "neon-docs-36" ] }, { "productId": "neon", "storyId": "openness-api-parity", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-20", "neon-docs-38", "neon-probe-3", "neon-docs-11", "neon-docs-34", "neon-probe-5", "neon-docs-12", "neon-docs-33", "neon-probe-4", "neon-probe-rt-1", "neon-probe-rt-2" ] }, { "productId": "neon", "storyId": "openness-full-export", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-gh-1", "neon-gh-5", "neon-gh-6", "neon-docs-4", "neon-docs-2" ] }, { "productId": "neon", "storyId": "openness-open-license", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-gh-5", "neon-gh-6", "neon-gh-4", "neon-gh-8", "neon-gh-3" ] }, { "productId": "neon", "storyId": "openness-self-host", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-gh-3", "neon-gh-4", "neon-gh-5", "neon-gh-8", "neon-comm-7" ] }, { "productId": "neon", "storyId": "orm-framework-compat", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "point-in-time-recovery", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "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.\n\nmissing 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.", "evidenceIds": [ "neon-docs-8", "neon-docs-29", "neon-docs-25", "neon-comm-10" ] }, { "productId": "neon", "storyId": "privacy-data-residency", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack items mention region selection, data residency, or geographic deployment options for Neon projects; nothing addresses where data is physically stored.", "evidenceIds": [] }, { "productId": "neon", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack contains no mention of any AI-training opt-out, data-use policy for model training, or privacy controls governing whether customer data is used to train AI models; all evidence covers unrelated product features (branching, autoscaling, MCP server, CLI, pricing). Since Neon stores and processes user data and could plausibly offer such a privacy guarantee, the axis applies but is unaddressed. missing for 10: any documentation of an AI-training opt-out policy, data-processing/privacy terms addressing model training, or statements that customer data is excluded from AI training.", "evidenceIds": [] }, { "productId": "neon", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence in the pack addresses telemetry collection or an opt-out mechanism for Neon's CLI, MCP server, or platform usage tracking; privacy/telemetry policy is simply not documented here.", "evidenceIds": [] }, { "productId": "neon", "storyId": "query-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "replicas-failover", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-16", "neon-docs-28", "neon-gh-5", "neon-gh-6" ] }, { "productId": "neon", "storyId": "safe-schema-changes", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-25", "neon-docs-8", "neon-docs-29", "neon-comm-10" ] }, { "productId": "neon", "storyId": "scale-to-zero-idle", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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).", "evidenceIds": [ "neon-docs-9", "neon-docs-27", "neon-docs-24", "neon-gh-5", "neon-comm-1" ] }, { "productId": "neon", "storyId": "serverless-edge-driver", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "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).", "evidenceIds": [ "neon-docs-14", "neon-docs-31", "neon-docs-13", "neon-docs-30", "neon-docs-9" ] }, { "productId": "neon", "storyId": "spend-caps-alerts", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "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.", "evidenceIds": [] }, { "productId": "neon", "storyId": "transparent-usage-pricing", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-6", "neon-docs-7", "neon-docs-24", "neon-comm-8", "neon-comm-12", "neon-comm-13" ] }, { "productId": "neon", "storyId": "vector-embeddings", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "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.", "evidenceIds": [ "neon-docs-15", "neon-docs-32" ] }, { "productId": "planetscale", "storyId": "agent-provisions-database", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "PlanetScale ships a CLI (pscale) explicitly designed for agent workflows—non-interactive `pscale sql`, a baked-in `--skill` guide, and `--format json` output for agents—plus a hosted MCP server for Claude/Cursor that exposes Insights and query execution, and docs on branching/schema deploy requests that agents could drive without the dashboard. However, the evidence never shows an explicit 'create database' or 'fetch connection string' CLI/API command, and the MCP server's insights-only variant explicitly excludes query execution, leaving a gap in the fully automated create→connect→schema→query chain. Missing for 10: explicit documented commands/API calls for database creation and connection-string retrieval, and confirmation that the primary MCP variant (not just insights-only) supports full query execution end-to-end.", "evidenceIds": [ "planetscale-docs-17", "planetscale-docs-24", "planetscale-docs-9", "planetscale-docs-11", "planetscale-docs-19", "planetscale-probe-4", "planetscale-probe-5", "planetscale-probe-rt-1", "planetscale-probe-rt-2", "planetscale-probe-rt-3" ] }, { "productId": "planetscale", "storyId": "agent-safe-sql-operations", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlanetScale ships an official hosted MCP server (verified live via OAuth handshake) plus a vendor-shipped CLI skill (`pscale --skill`) explicitly designed for agent consumption, and docs describe a separate insights-only MCP variant that excludes query execution — a concrete read/analysis-vs-execute scoping distinction. Agents can run non-interactive SQL (`pscale sql`) and review Insights to open PRs, showing real delegated database work. Missing for 10: explicit documentation of granular tool-level permissions distinguishing read-only SELECT/Insights tools from destructive DDL/DML tools within the full MCP server itself, and no independent hands-on report confirming an agent safely blocked from destructive actions.", "evidenceIds": [ "planetscale-docs-19", "planetscale-docs-17", "planetscale-docs-24", "planetscale-docs-31", "planetscale-probe-rt-2", "planetscale-probe-rt-3" ] }, { "productId": "planetscale", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PlanetScale ships a live llms.txt (HTTP 200, confirmed by direct probe) plus extensive agent-oriented documentation: a dedicated ai-tooling doc, an MCP server doc, and a CLI --skill command that prints a vendor-authored agent guide baked into the binary. This goes beyond the minimal story requirement of just having llms.txt or agent docs. Missing for 10: independent/community confirmation that agents actually consume and act correctly on llms.txt in the wild (only vendor-side probes exist).", "evidenceIds": [ "planetscale-probe-1", "planetscale-docs-19", "planetscale-docs-31", "planetscale-probe-rt-2", "planetscale-probe-rt-1" ] }, { "productId": "planetscale", "storyId": "agentic-ai-insights", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlanetScale's Insights feature provides server-side analysis of production traffic—aggregated query stats, failing query patterns, resource anomalies, and schema recommendations—directly inside the product (CLI/dashboard), and community evidence corroborates Insights surfacing actionable suggestions like missing indexes. This goes further into agentic territory with self-improving-database agents that review Insights and open PRs automatically, and MCP integration to expose Insights to AI tools. Missing for 10: independent verification of the self-improving-database agent's real-world accuracy/quality beyond vendor docs, and no direct hands-on user account of the AI-generated schema recommendations specifically (only the Insights index-suggestion anecdote).", "evidenceIds": [ "planetscale-docs-18", "planetscale-docs-26", "planetscale-docs-31", "planetscale-docs-20", "planetscale-comm-1", "planetscale-probe-rt-3" ] }, { "productId": "planetscale", "storyId": "agentic-autonomous-automation", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "PlanetScale documents a 'self-improving database' feature where an agent autonomously reviews production Insights and schema recommendations on a recurring schedule, then opens pull requests with performance improvements, plus webhook events for automation triggers. This matches the story of autonomous background automation, but evidence is first-party only.\n\nmissing for 10: independent/hands-on confirmation that the self-improving agent actually runs unattended in production, and details on configuring/scheduling the automation beyond the doc description.", "evidenceIds": [ "planetscale-docs-20", "planetscale-docs-31", "planetscale-docs-4" ] }, { "productId": "planetscale", "storyId": "agentic-builtin-assistant", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "PlanetScale's 'self-improving database' feature describes an agent that reviews production Insights/Schema Recommendations on a recurring schedule and opens pull requests with performance improvements, which resembles a delegated-task AI capability tied to the product. However, this appears to run through connected external agents (Claude, Cursor, etc.) via the MCP server rather than a distinct in-dashboard chat assistant, and there's no evidence of a UI-embedded assistant a user directly converses with inside the product. Missing for 10: a first-party in-app chat/assistant UI, independent hands-on confirmation of the self-improving-database feature actually running end-to-end, and clarity that it's not just MCP-enabled third-party agents.", "evidenceIds": [ "planetscale-docs-20", "planetscale-docs-31", "planetscale-docs-19", "planetscale-probe-rt-3" ] }, { "productId": "planetscale", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlanetScale's CLI explicitly supports non-interactive, scriptable SQL execution and JSON-formatted output designed for agents/automation, and runtime probes confirm `pscale --skill` ships a vendor-authored agent/CI guide plus `--format json` flags for headless use, alongside service-token auth (docs-7) enabling non-interactive authentication in CI.\n\nmissing for 10: explicit CI/CD pipeline examples (e.g., GitHub Actions workflow), and independent community confirmation of headless CI usage.", "evidenceIds": [ "planetscale-docs-17", "planetscale-docs-7", "planetscale-probe-rt-1", "planetscale-probe-rt-2", "planetscale-probe-5" ] }, { "productId": "planetscale", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PlanetScale is a database platform whose MCP role is to be the server that other AI tools (Claude, Cursor, etc.) connect to and use for its own tools/Insights (docs-19, probe-4, probe-rt-3) — not to act as an MCP client that consumes external MCP servers' tools. This client-side capability is a different axis reserved for agent/assistant-type products, so it does not apply to a database backend service like PlanetScale.", "evidenceIds": [ "planetscale-docs-19", "planetscale-probe-4", "planetscale-probe-rt-3" ] }, { "productId": "planetscale", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PlanetScale documents and hosts an official MCP server (mcp.pscale.dev) that connects Claude, Cursor, Notion, and other MCP-compatible tools to PlanetScale databases and Insights, and a runtime probe confirms the endpoint is live and correctly speaks the MCP OAuth handshake. Missing for 10: independent hands-on user reports of using the MCP server in practice beyond the vendor docs/probe.", "evidenceIds": [ "planetscale-docs-19", "planetscale-probe-4", "planetscale-probe-rt-3" ] }, { "productId": "planetscale", "storyId": "agentic-nl-commands", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlanetScale enables natural-language/agentic operation indirectly via MCP server integration (Claude, Cursor, etc.) and a CLI with an agent-oriented '--skill' guide and JSON output modes for scripts/agents, plus a self-improving-database agent that opens PRs from Insights data. However, this is not a native NL command interface within PlanetScale's own product surface — it relies on third-party AI tools (Claude, Cursor) interpreting natural language and calling MCP/CLI functions, and there's no evidence of a first-party natural-language console or chat within the PlanetScale dashboard itself. missing for 10: evidence of a native in-product NL interface, independent hands-on validation of the MCP/agent workflow beyond vendor docs and probes.", "evidenceIds": [ "planetscale-docs-17", "planetscale-docs-19", "planetscale-docs-20", "planetscale-docs-31", "planetscale-probe-rt-1", "planetscale-probe-rt-2", "planetscale-probe-rt-3" ] }, { "productId": "planetscale", "storyId": "agentic-official-cli", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PlanetScale ships an official CLI (`pscale`) with explicit AI-agent affordances: non-interactive SQL execution, JSON output, an `--skill` subcommand that prints a vendor-authored agent prompt, and insights/analytics commands — all confirmed via live runtime probes, not just docs. Missing for 10: independent (non-vendor) hands-on community commentary specifically about CLI agentic usage beyond the runtime probes.", "evidenceIds": [ "planetscale-docs-17", "planetscale-docs-24", "planetscale-probe-5", "planetscale-probe-rt-1", "planetscale-probe-rt-2" ] }, { "productId": "planetscale", "storyId": "agentic-public-api", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlanetScale ships a scriptable CLI (`pscale sql`, `--format json`, `--skill` agent guide) and a hosted MCP server for AI tools, which lets AI-native users drive the product programmatically, and docs explicitly target 'agents and scripts.' However, probes show no discoverable REST/GraphQL public API spec (openapi.json/swagger.json all 404, docs.md 404), so there's no traditional documented public API beyond the CLI/MCP surface. Missing for 10: a discoverable OpenAPI/REST API spec, independent confirmation that the CLI/MCP fully substitute for a public API in third-party integrations.", "evidenceIds": [ "planetscale-docs-17", "planetscale-docs-19", "planetscale-probe-rt-1", "planetscale-probe-rt-2", "planetscale-probe-rt-3", "planetscale-probe-2", "planetscale-probe-3" ] }, { "productId": "planetscale", "storyId": "agentic-scoped-keys", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "PlanetScale supports scoped service tokens (shown/managed via CLI) for API access, and its hosted MCP server explicitly ships a separate insights-only variant that excludes query execution, speaking full OAuth Bearer scoping for agent connections — direct evidence of least-privilege credentialing for AI agents. However, there's no first-party doc enumerating granular permission scopes for service tokens or explicit guidance on issuing agent-specific restricted tokens beyond the MCP insights/query split. Missing for 10: documented granular service-token scope/role list, explicit agent-token creation workflow docs, independent/hands-on confirmation of scope enforcement.", "evidenceIds": [ "planetscale-docs-7", "planetscale-docs-19", "planetscale-probe-rt-3", "planetscale-docs-31" ] }, { "productId": "planetscale", "storyId": "agentic-sdks", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of official SDKs or client libraries for building applications against PlanetScale programmatically—only CLI (pscale), MCP server, and webhook/API changelog items are documented. Since language SDKs are a fair and plausible offering for a database platform, the absence of any first-party SDK docs means this axis is unmet, not inapplicable. Missing for 10: any documentation of official SDKs/client libraries (Node, Go, Python, etc.), API reference tied to those SDKs, or independent confirmation of their existence.", "evidenceIds": [] }, { "productId": "planetscale", "storyId": "agentic-webhooks", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlanetScale documents webhook events (including backup.succeeded/backup.failed) with configurable Authorization headers, giving AI-native users a way to subscribe to and consume platform events programmatically. missing for 10: broader catalog of event types beyond backups, independent hands-on confirmation of webhook reliability from community sources.", "evidenceIds": [ "planetscale-docs-1", "planetscale-docs-4" ] }, { "productId": "planetscale", "storyId": "analytical-queries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "PlanetScale's evidence pack shows a MySQL/Postgres OLTP platform (branching, backups, replicas, sharding, Metal for IOPS, Insights for query monitoring) but nothing about columnar storage, OLAP query engines, or analytical aggregation performance for dashboard workloads over large tables. No documentation or community evidence addresses running heavy analytical aggregations fast without exporting to a warehouse.", "evidenceIds": [] }, { "productId": "planetscale", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Probes explicitly show no OpenAPI/interactive API reference exists (docs.md 404, all openapi.json candidate paths 404), and no evidence pack item describes a runnable-example API console; only static CLI/API docs and changelog entries are present.", "evidenceIds": [ "planetscale-probe-2", "planetscale-probe-3" ] }, { "productId": "planetscale", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "The probe explicitly checked for an OpenAPI/Swagger spec at all standard candidate paths and found only 404s, with no other evidence of a published machine-readable API spec.", "evidenceIds": [ "planetscale-probe-3", "planetscale-probe-2" ] }, { "productId": "planetscale", "storyId": "api-sandbox", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PlanetScale's core branching model explicitly provides isolated dev/test branches separate from production ('separate environments for development and testing'), with deploy-requests to safely promote schema changes without touching production data directly, and this is corroborated by community accounts of using branch-per-git-branch workflows for development/testing. The MCP server and CLI further enable AI agents to interact with branches programmatically rather than production. Missing for 10: no hands-on independent account specifically framing branch use as an 'AI agent sandbox test' scenario, though the underlying capability is well documented.", "evidenceIds": [ "planetscale-docs-9", "planetscale-docs-10", "planetscale-docs-11", "planetscale-docs-32", "planetscale-comm-9", "planetscale-docs-17", "planetscale-probe-4" ] }, { "productId": "planetscale", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack items mention API versioning scheme or a documented deprecation policy; probes for OpenAPI specs return 404s and changelog entries are feature announcements, not API-version/deprecation documentation.", "evidenceIds": [ "planetscale-probe-3" ] }, { "productId": "planetscale", "storyId": "automated-backups", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Docs explicitly state PlanetScale lets users create, schedule, and restore backups for branches, with daily default backups plus manual backups, point-in-time restore for Postgres branches, and webhook notifications (backup.succeeded/failed) for visibility into backup status. This covers scheduled, visible, self-serve backup/restore workflows for both MySQL/Vitess and Postgres branches. Missing for 10: no independent/hands-on community confirmation of the backup/restore UX specifically, and no detail on how granular the schedule configuration UI is beyond 'daily default'.", "evidenceIds": [ "planetscale-docs-12", "planetscale-docs-33", "planetscale-docs-5", "planetscale-docs-4", "planetscale-docs-10" ] }, { "productId": "planetscale", "storyId": "automation-bulk-operations", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PlanetScale's CLI explicitly supports non-interactive, scriptable operation (`pscale sql`) with a vendor-shipped agent skill and JSON output modes clearly aimed at automation across many items, and its AI-tooling docs describe agents that recurringly review Insights/Schema Recommendations across a database and open PRs. However, there's no explicit documentation of true bulk/batch operations (e.g., batch branch creation/deletion, bulk import across many databases, multi-item API calls) — the CLI and API appear built around single-resource commands invoked repeatedly rather than a dedicated bulk-operation primitive. Missing for 10: explicit bulk/batch API or CLI commands operating on many items in one call, and independent hands-on evidence of large-scale automated bulk operations succeeding.", "evidenceIds": [ "planetscale-docs-17", "planetscale-docs-31", "planetscale-probe-rt-1", "planetscale-probe-rt-2", "planetscale-docs-19" ] }, { "productId": "planetscale", "storyId": "automation-rules-engine", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "PlanetScale supports webhook events (e.g., backup.succeeded/failed) with configurable authorization headers, letting users trigger external actions when specific system events occur, and its self-improving-database agent runs on a recurring schedule to open PRs based on Insights data. However, this is limited to a small set of predefined events (mainly backups) rather than a general-purpose rule engine for arbitrary triggers/actions.\nmissing for 10: a documented rules/automation engine supporting custom trigger conditions across arbitrary event types, and evidence of user-defined conditional logic beyond fixed webhook events.", "evidenceIds": [ "planetscale-docs-4", "planetscale-docs-1", "planetscale-docs-31", "planetscale-docs-20" ] }, { "productId": "planetscale", "storyId": "automation-scheduled-jobs", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PlanetScale documents a specific recurring AI-driven workflow: agents reviewing Insights/Schema Recommendations and opening PRs 'on a recurring schedule' (docs-31, docs-20), plus daily scheduled backups (docs-12, docs-33). This is real recurring automation but narrow — it's tied to the self-improving-database feature, not a general-purpose job/workflow scheduler that AI-native users can configure for arbitrary tasks. Missing for 10: a documented mechanism for users to define/schedule arbitrary custom jobs or workflows (e.g., cron-style scheduling, workflow orchestration), and independent/community confirmation that the recurring-agent feature works in practice.", "evidenceIds": [ "planetscale-docs-31", "planetscale-docs-20", "planetscale-docs-12", "planetscale-docs-33" ] }, { "productId": "planetscale", "storyId": "automation-versioned-workflows", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "PlanetScale's docs show agents opening pull requests for schema changes (docs-20, docs-31) that flow through deploy requests for review (docs-11, docs-27), with branching giving version isolation (docs-9, docs-10) and backups/point-in-time restore enabling rollback (docs-12, docs-5, docs-33). Together these cover the version/review/rollback lifecycle for AI-driven automations. missing for 10: independent/hands-on corroboration that agent-opened PRs are actually reviewed and rolled back in practice, and a dedicated audit/version history view specifically for automation runs rather than general schema branches.", "evidenceIds": [ "planetscale-docs-20", "planetscale-docs-31", "planetscale-docs-11", "planetscale-docs-27", "planetscale-docs-9", "planetscale-docs-10", "planetscale-docs-12", "planetscale-docs-5", "planetscale-docs-33", "planetscale-docs-6" ] }, { "productId": "planetscale", "storyId": "autoscaling-under-load", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "A community comment describes the platform scaling an instance from zero to handling massive load automatically, but this is an old beta anecdote rather than current vendor documentation, and the docs pack mostly describes read replicas, sharding, and dedicated 'Metal' instances (which imply manual provisioning, not automatic compute autoscaling). Missing for 10: official docs describing automatic vertical/horizontal compute scaling triggers, confirmation of zero-downtime resizing for the current Postgres/Metal offering, and independent hands-on verification of autoscale behavior under load.", "evidenceIds": [ "planetscale-comm-9", "planetscale-docs-16", "planetscale-docs-8", "planetscale-docs-22" ] }, { "productId": "planetscale", "storyId": "branch-reset-restore", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs show branch restore capability via backups (create/schedule/restore backups for branches, docs-12/33) and Postgres branches support point-in-time restore with --restore-point (docs-5), plus branches described as providing 'restoring from backups' (docs-10). However, there's no explicit documentation of a 'reset branch to match parent' operation for the (MySQL/Vitess) branching model, and no independent/community confirmation of restoring a branch state without a full dump rebuild. Missing for 10: explicit 'reset to parent' semantics for MySQL branches, hands-on/community verification of restore workflow, and clarity on whether MySQL branches support point-in-time restore like Postgres.", "evidenceIds": [ "planetscale-docs-5", "planetscale-docs-10", "planetscale-docs-12", "planetscale-docs-33", "planetscale-docs-9" ] }, { "productId": "planetscale", "storyId": "builtin-connection-pooling", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs confirm PlanetScale Postgres ships with a managed PgBouncer instance (with its own dashboard/graphs), meaning the platform-engineer doesn't need to deploy or operate a separate pooler themselves. However, there's no explicit documentation quantifying concurrent-connection capacity ('thousands of connections') or describing pooler configuration/tuning options, and MySQL/Vitess-side pooling (vttablet) isn't mentioned at all in the pack. Missing for 10: explicit connection-capacity claims/benchmarks, pooler configuration docs, and confirmation this applies to the MySQL/Vitess product line as well as Postgres.", "evidenceIds": [ "planetscale-docs-2" ] }, { "productId": "planetscale", "storyId": "ci-preview-branches", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "PlanetScale's core product is branch-based schema workflows (branch per git branch, dev/test isolation, restore-point branches) and the CLI/API supports creating and deleting branches non-interactively, which platform engineers can script into CI. However, the evidence pack has no explicit CI/CD integration example (e.g., GitHub Action, deploy-platform webhook triggering branch creation/teardown per PR) — only generic webhook/backup events and CLI docs are shown. Missing for 10: a documented CI/CD or GitHub Actions integration showing automatic branch creation on PR-open and deletion on PR-close, and evidence of platform (e.g., Vercel/Netlify) preview-environment wiring.", "evidenceIds": [ "planetscale-docs-9", "planetscale-docs-32", "planetscale-docs-5", "planetscale-docs-17", "planetscale-comm-9", "planetscale-probe-5" ] }, { "productId": "planetscale", "storyId": "cli-daily-workflow", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Docs confirm core CLI daily-loop pieces: opening a secure MySQL/Postgres shell (pscale shell), running non-interactive SQL for scripts/agents (pscale sql), listing/showing service tokens, regions, and switchovers, and enabling org SSO from the CLI — and a runtime probe confirms the CLI installs and works keylessly with agent-oriented help (`--skill`). However, explicit CLI-driven 'create database' and full branch-lifecycle commands aren't directly cited (only branching/backup docs, which are Vitess/Postgres feature docs rather than CLI command references). Missing for 10: explicit CLI create-database/create-branch command docs, and independent hands-on confirmation that inspect/connect flows fully replace the dashboard.", "evidenceIds": [ "planetscale-docs-24", "planetscale-docs-17", "planetscale-docs-3", "planetscale-docs-7", "planetscale-docs-8", "planetscale-docs-6", "planetscale-probe-5", "planetscale-probe-rt-1", "planetscale-probe-rt-2" ] }, { "productId": "planetscale", "storyId": "database-branching", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PlanetScale's docs explicitly describe branching database schemas and data the same way as code branches, creating isolated dev/test environments from production-shaped branches (docs-9, docs-10, docs-32), corroborated by hands-on community use describing a database branch per git branch workflow (comm-9). Backups/restores and non-blocking schema deploys further support the workflow (docs-11, docs-12, docs-27). missing for 10: independent post-2021 hands-on confirmation of copy-on-write speed/isolation specifics, explicit copy-on-write terminology in docs.", "evidenceIds": [ "planetscale-docs-9", "planetscale-docs-10", "planetscale-docs-11", "planetscale-docs-32", "planetscale-comm-9" ] }, { "productId": "planetscale", "storyId": "engine-compatibility", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "PlanetScale markets itself as MySQL and Postgres compatible with branching, imports, and scaling docs, but hands-on community reports specifically state that PlanetScale's Vitess-based MySQL layer does not support foreign keys — a core MySQL feature many existing apps expect — making it a lookalike subset rather than full engine fidelity for that dialect. Missing for 10: any evidence resolving the FK limitation, independent confirmation of full Postgres extension/dialect parity, and SQLite compatibility is not addressed at all.", "evidenceIds": [ "planetscale-comm-7", "planetscale-comm-8", "planetscale-comm-10", "planetscale-docs-9", "planetscale-docs-13", "planetscale-probe-1" ] }, { "productId": "planetscale", "storyId": "fleet-per-agent-databases", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PlanetScale's branching model (docs-9,10,32) and CLI (docs-17,24; probe-5) let you programmatically create and manage isolated database/branch instances, which maps to the 'agent workflows' isolation story, and the CLI is explicitly designed for scripted/agent use (pscale sql, --skill). However, PlanetScale's product is architected around branches-per-database rather than truly independent databases, and community pricing feedback ($1.25/10GB storage, $15/100M rows) plus lack of a free tier (planetscale-comm-5, planetscale-comm-11) and a report of database creation being halted under load (planetscale-comm-12) undercut the 'cheaply create thousands' framing. Missing for 10: explicit documentation of per-tenant/per-agent database creation at scale, confirmed low/no-cost pricing for thousands of isolated instances, and evidence of fleet-level programmatic provisioning (bulk create/delete) beyond single branch/database CLI commands.", "evidenceIds": [ "planetscale-docs-9", "planetscale-docs-10", "planetscale-docs-17", "planetscale-docs-24", "planetscale-probe-5", "planetscale-comm-5", "planetscale-comm-11", "planetscale-comm-12" ] }, { "productId": "planetscale", "storyId": "free-tier-depth", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "Community evidence explicitly states PlanetScale removed its free/hobby tier and users now face pay-as-you-go pricing with per-row and per-storage charges, with no vendor docs describing any current free tier for prototyping. No evidence contradicts this or shows a usable free option today.", "evidenceIds": [ "planetscale-comm-5", "planetscale-comm-11" ] }, { "productId": "planetscale", "storyId": "global-low-latency", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "PlanetScale docs mention listing available regions for a database and configured Vitess read-only regions, implying support for placing read replicas in specific geographic regions to reduce latency, and Postgres replicas can offload reads from the primary. However, this is a single thin mention with no detail on how region selection is configured, no explicit multi-region replica setup guide, and no independent/community confirmation of real-world latency improvements from region placement. Missing for 10: detailed region-selection/configuration docs, benchmarks or community reports of latency reduction from region placement, and confirmation this works consistently across both MySQL/Vitess and Postgres offerings.", "evidenceIds": [ "planetscale-docs-8", "planetscale-docs-14", "planetscale-docs-22", "planetscale-docs-34" ] }, { "productId": "planetscale", "storyId": "import-existing-database", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlanetScale's docs explicitly describe a dashboard import tool for existing internet-accessible MySQL/MariaDB databases with 'no downtime' (planetscale-docs-13, planetscale-docs-21), giving a documented migration path. Community evidence corroborates smooth production migrations (e.g., Metal migration over the weekend with major improvements), though one user notes friction migrating from Heroku due to logical replication restrictions. Missing for 10: independent hands-on verification specifically of the MySQL/MariaDB import tool (vs. Postgres/Metal migrations), and no mention of Postgres import path with equivalent zero-downtime guarantee.", "evidenceIds": [ "planetscale-docs-13", "planetscale-docs-21", "planetscale-comm-1", "planetscale-comm-3" ] }, { "productId": "planetscale", "storyId": "instant-provisioning", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Docs and community evidence support serverless, scale-to-zero database provisioning and branching (e.g., 'database branch for each Git branch... cost scale to 0... will scale to support massive load') and PlanetScale's CLI is documented for schema branching, SQL execution, and shell access, implying rapid setup without manual capacity planning. However, no evidence explicitly documents a 'create database' CLI/API command or confirms 'ready in seconds' timing, and one community report notes a past incident where database creation was temporarily halted due to traffic. missing for 10: explicit CLI/API docs for database creation command, quantified provisioning time, and independent verification of instant readiness.", "evidenceIds": [ "planetscale-comm-9", "planetscale-docs-9", "planetscale-docs-17", "planetscale-docs-24", "planetscale-comm-12" ] }, { "productId": "planetscale", "storyId": "local-keyless-engine", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "PlanetScale is a cloud-hosted database platform; there is no evidence of a downloadable/local engine that runs keylessly offline. Community evidence directly confirms this gap: a user explicitly asked whether PlanetScale can be installed locally, work offline, or is open source, and confirmed the answer to all three is no, calling it vendor lock-in.", "evidenceIds": [ "planetscale-comm-13" ] }, { "productId": "planetscale", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "The CLI/API surface is broad — SSO management, service tokens, backups, webhooks, regions, switchovers, branching, insights, sql shell — mirroring most dashboard actions (planetscale-docs-3,4,6,7,8,17,24,26). However the import tool is explicitly described as living 'in the dashboard' (planetscale-docs-13/21), suggesting at least one UI-only capability, and probes show no discoverable OpenAPI/REST spec (planetscale-probe-3), only CLI-level parity documented. Missing for 10: confirmed feature-for-feature parity (e.g. import via CLI/API), a documented formal API spec, and independent hands-on confirmation that nothing requires the UI.", "evidenceIds": [ "planetscale-docs-3", "planetscale-docs-4", "planetscale-docs-6", "planetscale-docs-7", "planetscale-docs-8", "planetscale-docs-13", "planetscale-docs-17", "planetscale-docs-24", "planetscale-probe-3", "planetscale-probe-5" ] }, { "productId": "planetscale", "storyId": "openness-full-export", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows no vendor documentation of a bulk data-export feature or open-format dump/leave workflow (only an import tool for MySQL/MariaDB is documented). Community commentary directly states PlanetScale is not open source, can't run locally/offline, and is 'yet another example of vendor lock-in,' reinforcing the absence of a documented exit/export path.", "evidenceIds": [ "planetscale-docs-13", "planetscale-comm-13" ] }, { "productId": "planetscale", "storyId": "openness-open-license", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "PlanetScale is a closed, proprietary hosted database platform; no evidence pack item claims open-licensed source code, and community evidence explicitly states it is not open source ('Is it fully open source? ... the answer ... is no').", "evidenceIds": [ "planetscale-comm-13" ] }, { "productId": "planetscale", "storyId": "openness-self-host", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "PlanetScale is a fully-hosted cloud database platform with no documented self-host/on-prem option; community evidence explicitly confirms it cannot be installed locally or run offline and is not open source ('Can I install this locally?... the answer to all three questions is no'), contradicting the self-hosting story entirely.", "evidenceIds": [ "planetscale-comm-13" ] }, { "productId": "planetscale", "storyId": "orm-framework-compat", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains extensive docs on branching, schema deploy requests, backups, imports, and CLI/MCP tooling, but nothing that specifically documents ORM or framework integration guides for Prisma, Drizzle, Django, or Rails. No citation mentions any of these named ORMs/frameworks or dedicated setup guides for them.", "evidenceIds": [] }, { "productId": "planetscale", "storyId": "point-in-time-recovery", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "PlanetScale docs explicitly support point-in-time restore branches for Postgres (--restore-point), scheduled/manual backups for Vitess branches, and branching that includes restoring from backups, directly matching the platform-engineer's recovery workflow. missing for 10: independent/hands-on verification of an actual PITR recovery from a bad write, and explicit documentation of the retention window length/limits.", "evidenceIds": [ "planetscale-docs-5", "planetscale-docs-10", "planetscale-docs-12", "planetscale-docs-33", "planetscale-docs-9" ] }, { "productId": "planetscale", "storyId": "privacy-data-residency", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Docs mention listing regions available to a database and configuring read-only regions (planetscale-docs-8), implying region selection is possible, but there's no explicit documentation of choosing a primary region at database creation, data residency guarantees, or compliance certifications. missing for 10: explicit region-selection-at-creation docs, data residency/compliance statements, independent confirmation of region choice.", "evidenceIds": [ "planetscale-docs-8" ] }, { "productId": "planetscale", "storyId": "privacy-no-training", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "PlanetScale is a database infrastructure platform, not an AI model provider or AI product that trains models on user data; 'prevent data from being used to train AI models' is not a fair axis for this kind of product — no evidence pack item even addresses AI training use of customer data.", "evidenceIds": [] }, { "productId": "planetscale", "storyId": "privacy-retention-controls", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers backups, branching, replicas, and MCP/CLI tooling but contains no documentation of data-retention policies, backup-retention windows, or explicit data-deletion/purge controls (e.g., how long backups are kept, how to fully delete a database or purge branch data) that would let an AI-native user govern retention and deletion.", "evidenceIds": [] }, { "productId": "planetscale", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item mentions telemetry, usage tracking, or an opt-out setting for PlanetScale's CLI, dashboard, or MCP server; the closest related item (usage billing view) concerns cost tracking, not telemetry.", "evidenceIds": [] }, { "productId": "planetscale", "storyId": "query-insights", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "PlanetScale's Insights feature surfaces aggregated query statistics, failing query patterns, resource anomalies, and schema recommendations computed from production traffic, including ranking top queries by performance metric — directly matching the story's slow-query, index-recommendation, and performance-metrics asks. A hands-on HN report independently corroborates that the Insights tab surfaced missing indexes that sped up queries after migration. Missing for 10: broader independent corroboration beyond a single community post and more detail on the dashboard UI itself (docs focus mostly on CLI insights commands).", "evidenceIds": [ "planetscale-docs-18", "planetscale-docs-26", "planetscale-docs-30", "planetscale-docs-31", "planetscale-comm-1" ] }, { "productId": "planetscale", "storyId": "replicas-failover", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "PlanetScale documents read replicas (Postgres and Vitess read-only regions), branch switchovers with list/show by ID, scheduled/manual backups, and backup success/failure webhook events, covering the core reliability and failover lifecycle. Community evidence (comm-1, comm-2) corroborates responsive incident handling, though it's not a rigorous documented failover SLA or independent chaos-test report. Missing for 10: an explicit HA/failover SLA or uptime guarantee, and independent verification of automatic failover behavior under real outages.", "evidenceIds": [ "planetscale-docs-8", "planetscale-docs-14", "planetscale-docs-22", "planetscale-docs-34", "planetscale-docs-6", "planetscale-docs-12", "planetscale-docs-33", "planetscale-docs-4", "planetscale-comm-1", "planetscale-comm-2" ] }, { "productId": "planetscale", "storyId": "safe-schema-changes", "verdict": "partial", "quality": 7, "confidence": "high", "rationale": "PlanetScale's docs describe schema branching plus deploy requests as the core workflow for non-blocking, zero-downtime production schema changes, and community reports (e.g., smooth Metal migration, working Insights) corroborate real-world use. However, independent community reports flag a 'boulder-sized caveat' that the non-blocking schema-change workflow does not support foreign keys, which excludes many existing schemas from safe zero-downtime migrations. missing for 10: evidence of foreign-key support in the non-blocking DDL workflow, and independent verification of deploy-request behavior under load/failure scenarios.", "evidenceIds": [ "planetscale-docs-9", "planetscale-docs-11", "planetscale-docs-27", "planetscale-docs-32", "planetscale-comm-10", "planetscale-comm-7", "planetscale-comm-8" ] }, { "productId": "planetscale", "storyId": "scale-to-zero-idle", "verdict": "partial", "quality": 3, "confidence": "low", "rationale": "Only a single old community comment (from the 2020 beta) claims the database 'cost scale to 0, so it is perfect for small projects,' and no current vendor docs in the pack describe a scale-to-zero or free-tier mechanism; another community comment notes the hobby/free tier was later removed, casting doubt on whether idle prototypes truly cost nothing today. missing for 10: current first-party documentation describing scale-to-zero billing/behavior, confirmation that idle databases remain durable while scaled down, and evidence of an active free/hobby tier for side projects.", "evidenceIds": [ "planetscale-comm-9", "planetscale-comm-5", "planetscale-comm-11" ] }, { "productId": "planetscale", "storyId": "serverless-edge-driver", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of an HTTP- or WebSocket-based serverless/edge driver, connection pooling for short-lived connections, or any client library targeting edge runtimes; only CLI, MCP server, branching, backups, and general connectivity topics are covered. This axis clearly applies to a database platform aiming at modern app stacks, but no supporting evidence exists in the pack.", "evidenceIds": [] }, { "productId": "planetscale", "storyId": "spend-caps-alerts", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Docs show only that founders can view current/previous usage per database (planetscale-docs-25), not that they can set spend caps or configure usage alerts to prevent surprise bills. No evidence pack item describes budget limits, alert thresholds, or automatic throttling tied to spend.", "evidenceIds": [ "planetscale-docs-25" ] }, { "productId": "planetscale", "storyId": "transparent-usage-pricing", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Community evidence cites specific per-unit rates (storage, rows read, rows written) suggesting granular usage-based pricing exists, and docs mention a usage dashboard for tracking consumption, but there is no first-party pricing page or rate card in the evidence pack confirming these figures are current or comprehensive across compute, storage, and traffic. missing for 10: an official pricing page with per-unit rates, confirmation the cited 2021 rates are current, and any breakdown of compute pricing specifically.", "evidenceIds": [ "planetscale-comm-11", "planetscale-docs-25", "planetscale-comm-5" ] }, { "productId": "planetscale", "storyId": "vector-embeddings", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack mentions vector data types, embeddings, or similarity search functionality in PlanetScale (MySQL or Postgres offerings); the pack covers branching, backups, scaling, MCP/CLI tooling, and pricing but nothing about vector storage/search.", "evidenceIds": [] }, { "productId": "turso", "storyId": "agent-provisions-database", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Turso documents and runtime-probes confirm a full non-dashboard provisioning path: the API can create/token-scope/tear down a database per agent (turso-docs-8), the CLI can create a db and shell into it (turso-docs-14/15/40, turso-probe-5), and the official MCP server (docs-9/37, turso-probe-4) lets any MCP-capable agent manage orgs/databases/groups and run SQL with no token copy-paste — independently verified live and returning a real OAuth challenge (turso-probe-rt-3), plus a keyless local libSQL server actually executing CREATE TABLE/INSERT/SELECT via CLI (turso-probe-rt-2). Schema/data operations are covered via SDK push()/pull() (docs-7/20/43) and CLI shell/.dump (docs-47). Missing for 10: a single documented end-to-end example chaining API-create→connection-string→schema-apply→query in one flow, and independent (non-vendor) confirmation of the full agent-driven MCP workflow beyond the auth handshake.", "evidenceIds": [ "turso-docs-8", "turso-docs-9", "turso-docs-37", "turso-docs-14", "turso-docs-15", "turso-docs-40", "turso-docs-7", "turso-docs-20", "turso-probe-4", "turso-probe-5", "turso-probe-rt-2", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "agent-safe-sql-operations", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Turso ships an official MCP server (turso-docs-9, turso-docs-37, turso-probe-rt-3) that lets any MCP-capable agent run SQL and manage databases, and token-scoped per-agent database provisioning (turso-docs-8) exists, but there is no evidence the MCP tool set distinguishes read-only query tools from destructive/schema-mutating ones (e.g. no documented tool scoping, permission tiers, or dry-run/confirmation gating for DDL/DML vs SELECT).", "evidenceIds": [ "turso-docs-9", "turso-docs-37", "turso-docs-8", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "agentic-agent-docs", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Turso hosts a live llms.txt index (HTTP 200) that links to markdown docs pages, exactly matching the agent-oriented docs pattern, and this was independently confirmed via probe. Missing for 10: no independent/community corroboration that agents actually use this llms.txt file successfully in practice.", "evidenceIds": [ "turso-probe-1", "turso-probe-2" ] }, { "productId": "turso", "storyId": "agentic-ai-insights", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Turso provides infrastructure primitives (native vector search, MCP integration for agents to run SQL) but no evidence of a built-in feature that itself generates AI insights or suggestions about the user's stored data — it merely provides raw building blocks for others to build such features on top.", "evidenceIds": [] }, { "productId": "turso", "storyId": "agentic-autonomous-automation", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Turso provides infrastructure that supports agent-driven automation — a documented MCP server that lets any MCP-capable agent autonomously manage the Turso Cloud account, provision/branch databases and run SQL (turso-docs-9, turso-docs-37, verified live in turso-probe-rt-3), plus an API for programmatically provisioning per-agent isolated databases (turso-docs-8, turso-docs-12) and automating branch creation for CI/CD pipelines (turso-docs-11). However, Turso itself has no native scheduler, trigger, or cron/background-job engine — the 'automation' must be built externally by the agent/orchestrator calling Turso's API/MCP, not something Turso runs autonomously on its own. Missing for 10: a built-in scheduled/triggered job or workflow engine, and independent/hands-on evidence of an agent actually running unattended background automations against Turso.", "evidenceIds": [ "turso-docs-9", "turso-docs-37", "turso-docs-8", "turso-docs-11", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "agentic-builtin-assistant", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Turso's evidence only shows an MCP server letting external AI agents connect to and manage Turso (agent-as-client), not a built-in AI assistant embedded within the Turso product itself that users could delegate tasks to. No CLI, dashboard, or SDK feature describes an in-product AI assistant.", "evidenceIds": [] }, { "productId": "turso", "storyId": "agentic-headless", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Turso ships a scriptable CLI (turso db create/shell), local dev server (turso dev / sqld) that runs keylessly with no account, and SDK push/pull automation, all confirmed by hands-on probes showing real SQL roundtrips headlessly on port 8085 — ideal for CI pipelines and PR-based branch automation. missing for 10: no explicit CI recipe/example (e.g. GitHub Actions workflow) in the evidence, and no independent community report specifically confirming CI usage.", "evidenceIds": [ "turso-docs-14", "turso-docs-15", "turso-docs-17", "turso-docs-11", "turso-docs-20", "turso-probe-rt-1", "turso-probe-rt-2", "turso-probe-5" ] }, { "productId": "turso", "storyId": "agentic-mcp-client", "verdict": "na", "quality": 0, "confidence": "high", "rationale": "Turso is a database platform, not an agent or orchestrator that itself consumes MCP servers' tools; the evidence entirely concerns Turso exposing its own official MCP server for AI agents to connect to and manage Turso resources (turso-docs-9, turso-docs-37, turso-probe-4, turso-probe-rt-3), which is the reverse (server) role, not the client-side 'plug MCP servers into this product' story.", "evidenceIds": [] }, { "productId": "turso", "storyId": "agentic-mcp-server", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Turso ships an official hosted MCP server (mcp.turso.ai) that lets any MCP-capable agent manage databases, branches, and run SQL without manual token handling, documented at docs.turso.tech/integrations/mcp and confirmed live via a runtime probe returning the expected OAuth challenge from the real endpoint. Missing for 10: independent/community hands-on validation of the MCP server specifically (all community evidence concerns core DB features, not MCP usage).", "evidenceIds": [ "turso-docs-9", "turso-docs-21", "turso-docs-37", "turso-probe-4", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "agentic-nl-commands", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Turso ships an official, documented MCP integration that lets any MCP-capable AI agent manage the Turso Cloud account (create/branch databases, groups) and run SQL directly via natural-language agent commands, with no manual API token handling — and a runtime probe confirms the hosted MCP endpoint (mcp.turso.ai) is live and enforces the documented OAuth flow. This directly satisfies the AI-native/agentic natural-language operation story. Missing for 10: independent/community hands-on validation of the MCP agent workflow itself (evidence pack has no third-party reports specifically using the MCP interface, only vendor docs and a runtime auth probe).", "evidenceIds": [ "turso-docs-9", "turso-docs-21", "turso-docs-37", "turso-probe-4", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "agentic-official-cli", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Turso ships an official CLI (documented at docs.turso.tech/cli/introduction, used throughout quickstart for db create, shell, dump) and this was independently verified at runtime (installed via get.tur.so, `turso --version` worked, and `turso dev` booted a real local libSQL server with a working SQL roundtrip). It also integrates with AI agents via an official MCP server, reinforcing agenticness. missing for 10: no independent community commentary specifically praising/critiquing the CLI's AI-native workflow ergonomics beyond vendor docs and probes.", "evidenceIds": [ "turso-probe-5", "turso-probe-rt-1", "turso-probe-rt-2", "turso-docs-14", "turso-docs-15", "turso-docs-40", "turso-probe-4" ] }, { "productId": "turso", "storyId": "agentic-public-api", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Turso documents and exposes a public API (database provisioning, token-scoping, SQL execution) per turso-docs-8/12, plus SDKs in multiple languages (turso-docs-13) and a live Hrana HTTP API confirmed via runtime probe (turso-probe-rt-2), and a hosted MCP endpoint for agent-driven control (turso-docs-9, turso-probe-rt-3). No formal OpenAPI/Swagger spec was found (turso-probe-3), and community evidence doesn't specifically corroborate API completeness beyond SDK usage. missing for 10: a discoverable OpenAPI/swagger spec, independent hands-on confirmation of the REST/management API beyond SQL execution.", "evidenceIds": [ "turso-docs-8", "turso-docs-9", "turso-docs-12", "turso-docs-13", "turso-probe-3", "turso-probe-4", "turso-probe-rt-2", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "agentic-scoped-keys", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Docs explicitly describe provisioning a dedicated, isolated database per AI agent that you 'create, token-scope, and tear down via the API' (turso-docs-8), directly matching least-privilege per-agent credentials, and the MCP integration uses OAuth-based auth rather than shared static tokens (turso-docs-9/37, confirmed live via turso-probe-rt-3). Missing for 10: detailed documentation of fine-grained permission scopes (e.g., read-only vs write, table-level scopes) and independent/hands-on validation of the token-scoping API itself.", "evidenceIds": [ "turso-docs-8", "turso-docs-9", "turso-docs-37", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "agentic-sdks", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Turso documents official SDKs in TypeScript, Python, Rust, and Go with concrete quickstart usage (push/pull, embedded replicas), and this is corroborated by a CLI/local-dev runtime probe showing real SQL execution over a supported protocol. This directly satisfies 'build against official SDKs' for AI-native/agentic use, including per-agent database provisioning via API and MCP integration for agent-driven management. Missing for 10: independent hands-on validation of the non-TS SDKs (Python/Rust/Go) specifically, beyond the TS quickstart and vendor docs.", "evidenceIds": [ "turso-docs-13", "turso-docs-7", "turso-docs-20", "turso-docs-8", "turso-probe-rt-2", "turso-probe-4", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "agentic-webhooks", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence anywhere in the pack of webhook support or event subscription mechanisms; Turso's documented integration surface is CLI, SDKs, API, and MCP, not webhooks. This is a fair capability to ask of a cloud database (e.g., change-data-capture notifications), so absence is 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "turso", "storyId": "analytical-queries", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Turso's docs focus on SQLite-compatible OLTP features (embedded replicas, branching, PITR, vector search) with no mention of analytical/OLAP optimizations, columnar storage, or dashboard-scale aggregation performance. Community evidence actually points the other way: users report missing window functions and 'deeply nested joins which overflow something,' both core to heavy analytical aggregations, suggesting the product is not built or proven for this workload.", "evidenceIds": [ "turso-comm-2", "turso-comm-9" ] }, { "productId": "turso", "storyId": "api-interactive-docs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Turso has API reference docs (turso-docs-8) but no evidence of an interactive, runnable-example reference; a direct probe for OpenAPI/Swagger interactive docs returned 404 on all candidate paths, indicating no such interactive reference is exposed.", "evidenceIds": [ "turso-docs-8", "turso-probe-3" ] }, { "productId": "turso", "storyId": "api-machine-spec", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "A direct probe for OpenAPI/swagger spec files at Turso's docs domain returned 404 on all candidate paths, and no other evidence shows a downloadable machine-readable API spec despite Turso having an API reference and CLI/SDK docs.", "evidenceIds": [ "turso-probe-3", "turso-docs-8" ] }, { "productId": "turso", "storyId": "api-sandbox", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Turso's branching feature explicitly creates a separate database instance from production for dev/testing without affecting the original, and local development (turso dev, local file DBs, dump-and-use-locally) plus PITR further support safe sandbox testing away from production; runtime probes confirm branching and local dev commands actually work. Missing for 10: no independent hands-on evidence of branch-based testing workflows specifically (only local-dev CLI was runtime-verified), and no documented automatic data-masking/anonymization when branching from production data.", "evidenceIds": [ "turso-docs-3", "turso-docs-18", "turso-docs-32", "turso-docs-41", "turso-docs-11", "turso-docs-29", "turso-probe-rt-2" ] }, { "productId": "turso", "storyId": "api-versioning-policy", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "No evidence pack item mentions API versioning scheme or a deprecation policy for Turso's APIs, SDKs, or CLI; probes even show no OpenAPI spec discoverable at expected paths. This is a fair axis for a cloud API/database product, so absence of evidence yields 'none'.", "evidenceIds": [ "turso-probe-3" ] }, { "productId": "turso", "storyId": "automated-backups", "verdict": "partial", "quality": 4, "confidence": "medium", "rationale": "Turso documents point-in-time recovery (PITR) that lets you restore to a specific timestamp, which covers the recovery half of the story, and Pro/Enterprise customers can bring their own S3 buckets for backup storage. However there is no evidence of a visible, configurable backup schedule (frequency, retention window shown/editable) or a self-serve restore UI/CLI walkthrough — PITR is presented as continuous rather than a schedule you configure and see. Missing for 10: a documented backup schedule dashboard/config, explicit retention settings, and a concrete self-serve restore command/flow example.", "evidenceIds": [ "turso-docs-4", "turso-docs-33", "turso-docs-42", "turso-docs-27" ] }, { "productId": "turso", "storyId": "automation-bulk-operations", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Turso explicitly documents provisioning thousands/millions of isolated databases programmatically via API for per-user/per-agent use cases, which directly supports bulk automation for AI-native workflows (turso-docs-8, turso-docs-12, turso-docs-13). Missing for 10: independent/hands-on corroboration of large-scale bulk provisioning, and explicit documentation of bulk row-level SQL batch operations (e.g. batch insert/update APIs) beyond database-level scale.", "evidenceIds": [ "turso-docs-8", "turso-docs-12", "turso-docs-13" ] }, { "productId": "turso", "storyId": "automation-rules-engine", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no mention of SQL triggers, webhooks, change-data-capture, or any event-driven rule/action mechanism built into Turso. The closest mention (turso-docs-11, automating branch creation per pull request) describes external CI automation, not a rules engine that fires actions on database events, so this applicable axis (SQLite-based DBs commonly support CREATE TRIGGER) has no supporting evidence.", "evidenceIds": [ "turso-docs-11" ] }, { "productId": "turso", "storyId": "automation-scheduled-jobs", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "Turso's evidence pack covers database provisioning, branching, replication, vector search, and MCP-based agent management, but nothing describes any capability to schedule recurring jobs, cron-like tasks, or workflow automation triggers within Turso itself. As a database platform this axis is plausible (e.g., scheduled queries/maintenance jobs), so absence of evidence means 'none' rather than 'na'.", "evidenceIds": [] }, { "productId": "turso", "storyId": "automation-versioned-workflows", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Turso provides branching (versioning of schema/data changes, including automating a new branch per PR) and point-in-time recovery (rollback for user errors), and its MCP integration lets an AI agent create/manage these branches and run SQL directly. However, there is no documented 'review' mechanism (e.g., diffing or approval workflow before merging a branch back), so the story's review component is unevidenced. Missing for 10: explicit review/diff/approval tooling for automation changes, and independent confirmation that AI agents actually use branching+PITR as a version-control workflow in practice.", "evidenceIds": [ "turso-docs-3", "turso-docs-11", "turso-docs-18", "turso-docs-4", "turso-docs-33", "turso-docs-42", "turso-docs-9", "turso-probe-4", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "autoscaling-under-load", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack describes database provisioning at scale (thousands/millions of isolated databases), branching, replication, and durability, but contains no claim or documentation that per-database compute automatically scales up/down with load without manual resizing or downtime. Missing for 10: any docs on compute/resource autoscaling, load-based scaling triggers, or zero-downtime resize behavior.", "evidenceIds": [ "turso-docs-12", "turso-docs-13" ] }, { "productId": "turso", "storyId": "branch-reset-restore", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Turso docs show branches can be created fresh from a parent (`turso db create ... --from-db`) and databases can be restored to an earlier point via PITR, both without needing a SQL dump/reload, which covers the two halves of the story. However, there's no documented in-place 'reset this existing branch to its parent' command — you'd recreate/delete-and-recreate the branch — and PITR is described as whole-database recovery, not branch-specific reset. Missing for 10: an explicit branch-reset API/CLI command, and documentation tying PITR restore to a specific branch rather than the whole database.", "evidenceIds": [ "turso-docs-18", "turso-docs-32", "turso-docs-41", "turso-docs-33", "turso-docs-42", "turso-docs-29" ] }, { "productId": "turso", "storyId": "builtin-connection-pooling", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "Turso's evidence describes SQLite/libSQL architecture (embedded replicas, multi-writer without locking, HTTP/Hrana protocol) but nowhere documents a built-in connection pooler analogous to pgbouncer or claims about handling thousands of concurrent raw connections without such a proxy. Since Turso is not Postgres-based, the pgbouncer-specific framing doesn't map cleanly, but the general concern (many concurrent clients without an external pooler) is a fair question for any hosted DB and is simply unaddressed in the evidence pack.", "evidenceIds": [] }, { "productId": "turso", "storyId": "ci-preview-branches", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Turso documents branch creation via CLI (`turso db create ... --from-db`) and explicitly calls out automating branching for per-pull-request databases, plus API-driven provisioning/teardown of isolated databases, which platform engineers could wire into CI. However, there's no first-party CI/CD integration (e.g., GitHub Action, deploy-platform plugin) or documented teardown API call/webhook example, and no independent/hands-on evidence of a real CI pipeline doing this end-to-end. missing for 10: a documented CI/CD integration or GitHub Action for PR-branch lifecycle, an explicit teardown API example/webhook, and independent verification of the automated per-PR workflow in practice.", "evidenceIds": [ "turso-docs-11", "turso-docs-18", "turso-docs-8", "turso-docs-12", "turso-probe-5" ] }, { "productId": "turso", "storyId": "cli-daily-workflow", "verdict": "full", "quality": 8, "confidence": "high", "rationale": "Docs and a runtime probe confirm the official `turso` CLI covers create (`turso db create`), connect/shell (`turso db shell`), and inspect (`.dump`) without needing the dashboard, and a live CLI install was verified running a local libSQL server keylessly. Missing for 10: independent/hands-on third-party confirmation of the full daily loop (beyond vendor docs) and more inspection commands (e.g. schema/list) shown in action.", "evidenceIds": [ "turso-docs-14", "turso-docs-15", "turso-docs-31", "turso-docs-40", "turso-docs-47", "turso-probe-5", "turso-probe-rt-1", "turso-probe-rt-2" ] }, { "productId": "turso", "storyId": "database-branching", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Turso's docs directly document creating a branch from an existing database with schema and data (`turso db create my-new-database-branch --from-db my-existing-database`), explicitly framed for dev/test isolation without affecting the original, and even automating per-PR branch creation. Community evidence corroborates general reliability of the platform, though no independent hands-on report specifically validates branch creation. Missing for 10: independent/community confirmation of the branching feature itself (only vendor docs cover it).", "evidenceIds": [ "turso-docs-3", "turso-docs-18", "turso-docs-32", "turso-docs-41", "turso-docs-11" ] }, { "productId": "turso", "storyId": "engine-compatibility", "verdict": "disputed", "quality": 4, "confidence": "high", "rationale": "Turso's docs claim full SQLite compatibility ('Fully backwards compatible with SQLite', 'SQLite-compatible' SDKs, dump/shell/CLI tooling that mirrors SQLite), but hands-on community reports directly contradict this: using Turso/libSQL extensions breaks file-format compatibility so the standard SQLite CLI, Litestream, sqlite_rsync, recovery tools and SQLite UIs stop working, WAL-mode multi-process reads behave differently (exclusive lock errors), and important SQL features like savepoints, window functions, and ATTACH DATABASE are reported missing. Missing for 10: verified parity testing against the full SQLite feature/extension surface, resolution of the savepoints/windows/attach gaps, and independent confirmation that 'compatible' claims hold once libSQL-specific features are used.", "evidenceIds": [ "turso-docs-24", "turso-docs-13", "turso-docs-30", "turso-comm-4", "turso-comm-8", "turso-comm-9", "turso-comm-7", "turso-comm-12" ] }, { "productId": "turso", "storyId": "fleet-per-agent-databases", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "First-party docs explicitly describe provisioning a dedicated isolated SQLite database per user/agent, creating/token-scoping/tearing down via API, and spinning up 'thousands or millions' of isolated databases programmatically as core architecture, plus branch-per-PR automation and CLI/API creation flows. Missing for 10: independent/hands-on evidence of actually managing a large fleet (thousands) at scale, and concrete cost data proving 'cheap' bulk provisioning.", "evidenceIds": [ "turso-docs-8", "turso-docs-12", "turso-docs-11", "turso-docs-18", "turso-probe-5" ] }, { "productId": "turso", "storyId": "free-tier-depth", "verdict": "full", "quality": 7, "confidence": "medium", "rationale": "Turso's pricing page explicitly lists a Free plan alongside paid tiers (turso-docs-45, turso-docs-46), and independent community testimony confirms real production-adjacent use without needing to upgrade: \"Super fast and cheap, haven't had to need more than the free tier\" (turso-comm-2), plus another builder describing building an internal tool entirely on Turso (turso-comm-1). Missing for 10: explicit documentation of free-tier limits (storage/row/request caps) and more independent reports specifically stress-testing the free tier for prototyping at scale.", "evidenceIds": [ "turso-docs-45", "turso-docs-46", "turso-comm-2", "turso-comm-1" ] }, { "productId": "turso", "storyId": "global-low-latency", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Turso's Embedded Replicas feature directly supports placing local read replicas near users, with reads served in microseconds from the replica and writes syncing to the cloud primary — this is well documented across multiple sources. However, the evidence pack lacks explicit documentation of choosing/configuring specific regions for primary or replica placement (e.g., a region-selection API/flag), and a community report notes a real-world multi-day latency spike tied to a regional networking issue on Turso's infrastructure, tempering confidence in worldwide low-latency guarantees. Missing for 10: explicit region-selection tooling/docs for placing databases or replicas in specific geographies, and independent benchmark confirmation of low latency across regions.", "evidenceIds": [ "turso-docs-5", "turso-docs-19", "turso-docs-34", "turso-docs-35", "turso-comm-5" ] }, { "productId": "turso", "storyId": "import-existing-database", "verdict": "partial", "quality": 4, "confidence": "low", "rationale": "Turso docs show some building blocks for migration — opening existing SQLite files directly (turso-docs-30), dumping a production DB for local use (turso-docs-29, turso-docs-47), and creating a new DB branch `--from-db` an existing database (turso-docs-18) — but there is no dedicated, documented end-to-end migration guide addressing downtime, cutover, or importing from non-Turso production systems (e.g., Postgres/MySQL). Missing for 10: a documented step-by-step production migration/cutover guide, downtime guarantees or minimization strategy, and any independent/hands-on report of a real production migration succeeding.", "evidenceIds": [ "turso-docs-18", "turso-docs-29", "turso-docs-30", "turso-docs-47" ] }, { "productId": "turso", "storyId": "instant-provisioning", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Docs and runtime probes show `turso db create` plus `turso db shell` for instant cloud DB creation, and `turso dev` spinning up a fully keyless local libSQL server with a real SQL roundtrip in seconds — no capacity planning, provisioning API for programmatic per-user/agent DB creation, and self-serve signup-to-production flow are all documented and probe-verified. missing for 10: independent (non-vendor) benchmark or user account specifically confirming 'seconds-to-ready' timing for cloud creation beyond docs/probe.", "evidenceIds": [ "turso-docs-1", "turso-docs-14", "turso-docs-15", "turso-docs-8", "turso-docs-13", "turso-probe-rt-1", "turso-probe-rt-2", "turso-docs-12" ] }, { "productId": "turso", "storyId": "local-keyless-engine", "verdict": "full", "quality": 9, "confidence": "high", "rationale": "Turso's docs and CLI explicitly support a local, server-less libSQL database file with no account needed (turso-docs-2, turso-docs-16, turso-docs-17, turso-docs-30), and a hands-on runtime probe confirms `turso dev` boots a keyless local libSQL server and successfully executes real SQL without any cloud or account dependency (turso-probe-rt-1, turso-probe-rt-2). This directly satisfies offline/local dev and CI use cases keylessly. Missing for 10: an explicit first-party CI pipeline example/tutorial demonstrating this in an automated test suite context.", "evidenceIds": [ "turso-docs-2", "turso-docs-16", "turso-docs-17", "turso-docs-30", "turso-probe-rt-1", "turso-probe-rt-2" ] }, { "productId": "turso", "storyId": "openness-api-parity", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Turso's Platform API and CLI let you create/manage databases, branches, tokens, and even tear down resources programmatically (turso-docs-8, turso-docs-14, turso-docs-18), and the official MCP server lets an AI agent manage organizations, databases, groups, and run SQL without manual tokens (turso-docs-9, turso-probe-rt-3), suggesting broad API/UI parity. However there is no explicit documentation stating full feature parity between dashboard and API, and a discoverable OpenAPI/swagger spec could not be found (turso-probe-3 all 404), leaving some doubt about completeness for every UI feature (e.g., billing, VPC allow-list config in turso-docs-22/46 aren't shown as API-controllable). missing for 10: explicit UI/API parity statement, a public OpenAPI spec, evidence that dashboard-only settings (billing, VPC allow lists) are also API-manageable.", "evidenceIds": [ "turso-docs-8", "turso-docs-9", "turso-docs-14", "turso-docs-18", "turso-probe-3", "turso-probe-rt-3" ] }, { "productId": "turso", "storyId": "openness-full-export", "verdict": "disputed", "quality": 4, "confidence": "medium", "rationale": "Turso documents a straightforward export path (`turso db shell .dump > dump.sql`, docs-47) and markets itself as fully SQLite-compatible (docs-24, docs-13), which would let a user take a clean SQL dump and leave. However hands-on community reports directly contradict full openness: once any Turso-specific feature (vector search, replication, etc.) is used, the file is no longer plain-SQLite compatible — 'the SQLite CLI no longer works, Litestream doesn't work, sqlite_rsync doesn't work, recovery tools don't work, SQLite UIs don't work' (comm-8), undermining the 'export in open formats and leave' promise for any non-trivial schema. Missing for 10: vendor documentation acknowledging or addressing this compatibility caveat, and evidence of successful re-import of a dumped Turso database (with extensions) into vanilla SQLite/another engine.", "evidenceIds": [ "turso-docs-47", "turso-docs-29", "turso-docs-24", "turso-docs-13", "turso-comm-8", "turso-comm-7" ] }, { "productId": "turso", "storyId": "openness-open-license", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "A Turso engineer confirms that libSQL — the SQLite fork underlying Turso — is open source under the MIT license, and the CLI/local dev tooling is documented and runtime-verified as freely usable. However, there's no first-party documentation pack entry confirming the full Turso Cloud service or its newer Rust-based core is open-licensed, only a community aside. Missing for 10: an official first-party source-availability/license statement covering the whole product (cloud service, Rust rewrite), and independent corroboration beyond one community comment.", "evidenceIds": [ "turso-comm-10", "turso-probe-5", "turso-probe-rt-1" ] }, { "productId": "turso", "storyId": "openness-self-host", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Turso's core engine, libSQL/sqld, is open source (MIT) and can be run entirely locally with no cloud dependency — confirmed by docs (turso-docs-16/17/30) and a hands-on probe showing a real keyless local libSQL server handling SQL round-trips (turso-probe-rt-1/rt-2). However, most of Turso's advanced product surface (branching, PITR, embedded replicas sync, hosted MCP, dashboards, BYOC S3) is tied to Turso Cloud rather than a fully self-hostable platform, and community comments raise real compatibility/feature caveats on the libSQL fork (turso-comm-8, turso-comm-9, turso-comm-12). Missing for 10: first-party docs/guide for self-hosting the full platform (not just dev-mode server), and independent reports of production self-hosted deployments at scale.", "evidenceIds": [ "turso-docs-16", "turso-docs-17", "turso-docs-30", "turso-comm-10", "turso-probe-rt-1", "turso-probe-rt-2", "turso-comm-8", "turso-comm-9" ] }, { "productId": "turso", "storyId": "orm-framework-compat", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack shows Turso's own CLI, SDKs, branching, embedded replicas, and MCP integration, but contains no mention of Prisma, Drizzle, Django, or Rails integration guides or documented ORM support. A database product could reasonably be expected to publish such guides, so the axis applies, but no evidence confirms it here.", "evidenceIds": [] }, { "productId": "turso", "storyId": "point-in-time-recovery", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Turso documents explicit PITR (\"restore a database to a specific point in time... recovering from user errors, such as dropping a table by mistake\") and branching from any existing database (`turso db create ... --from-db`), directly covering both restore and branch-for-recovery workflows within a retention window. Docs also describe automating branch creation, giving platform engineers a scriptable recovery/testing path. Missing for 10: no explicit documentation of the retention window length/configurability, no independent/hands-on report confirming a PITR restore actually worked in production.", "evidenceIds": [ "turso-docs-4", "turso-docs-33", "turso-docs-42", "turso-docs-18", "turso-docs-32", "turso-docs-11" ] }, { "productId": "turso", "storyId": "privacy-data-residency", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Turso's docs explicitly promise data-residency control — 'Bring-your-own-cloud deployment. Data residency you control' and the ability for Pro/Enterprise customers to use their own S3 buckets so 'data lives inside their infrastructure,' plus VPC allow-lists for network isolation. These are first-party claims only, gated to paid tiers, and the evidence pack lacks concrete detail on region selection at database-creation time or independent verification of BYOC/residency in practice. Missing for 10: independent/hands-on confirmation of residency controls, explicit region-picker mechanism in CLI/API docs, and clarity on free-tier residency options.", "evidenceIds": [ "turso-docs-27", "turso-docs-28", "turso-docs-22", "turso-docs-46" ] }, { "productId": "turso", "storyId": "privacy-no-training", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence pack contains no policy statement, terms-of-service excerpt, or documentation addressing whether Turso uses customer database content to train AI models — despite Turso being a data-storage platform with AI-agent integrations (MCP) where such a privacy assurance would be a reasonable buyer question. No mention of data-training opt-out, model-training exclusion, or similar privacy commitment appears anywhere in the docs, pricing, or community evidence.", "evidenceIds": [] }, { "productId": "turso", "storyId": "privacy-retention-controls", "verdict": "partial", "quality": 6, "confidence": "medium", "rationale": "Turso lets users provision and 'tear down via the API' isolated per-user/per-agent databases (docs-8), supports full dump/export for data portability (docs-29/47), and offers PITR for recovery windows plus customer-held encryption keys and BYOC/data-residency controls (docs-27, docs-28) — all relevant to retention/deletion posture. However there is no explicit documentation of configurable retention periods, GDPR-style deletion guarantees, or backup-purge behavior after deletion. Missing for 10: explicit retention-period configuration, documented deletion/purge guarantees for backups and replicas, and independent verification that tear-down fully erases data.", "evidenceIds": [ "turso-docs-8", "turso-docs-27", "turso-docs-28", "turso-docs-29", "turso-docs-42" ] }, { "productId": "turso", "storyId": "privacy-telemetry-optout", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "No evidence pack item addresses telemetry, analytics, or usage-tracking opt-out settings for Turso's CLI, SDKs, or cloud platform — the question is a fair one for a developer tool/CLI product but nothing in docs, pricing, or community discussion confirms or denies a telemetry opt-out mechanism.", "evidenceIds": [] }, { "productId": "turso", "storyId": "query-insights", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence of a built-in insights/observability view covering slow queries, index recommendations, or performance metrics; docs focus on branching, replication, durability, MCP, and CLI, with no mention of query analytics dashboards.", "evidenceIds": [] }, { "productId": "turso", "storyId": "replicas-failover", "verdict": "partial", "quality": 5, "confidence": "medium", "rationale": "Turso documents embedded (read) replicas with clear push/pull replication behavior and durability guarantees (11 nines, sub-10ms), giving platform engineers some operational detail, but the evidence pack has no explicit documentation of failover/promotion behavior if the primary fails, multi-region HA topology, or replica-to-primary promotion procedures. Missing for 10: documented automatic failover/promotion process, multi-region HA architecture details, and independent verification of failover behavior under primary outage.", "evidenceIds": [ "turso-docs-5", "turso-docs-19", "turso-docs-34", "turso-docs-35", "turso-docs-10", "turso-docs-23", "turso-docs-26" ] }, { "productId": "turso", "storyId": "safe-schema-changes", "verdict": "disputed", "quality": 5, "confidence": "medium", "rationale": "Turso documents branch creation from an existing database and automated per-PR branches for schema experimentation, plus PITR for rollback after bad migrations, giving developers a partial branch-based schema workflow — but there is no documented 'merge back' step, no online-DDL/zero-downtime migration tooling, and the vendor's 'Multiple writers, zero conflicts, without locking' claim is directly contradicted by hands-on community reports of WAL exclusive-lock errors and an admitted 'conflict resolution is not yet implemented' in Turso's newer engine. missing for 10: explicit branch-merge/schema-diff tooling, documented zero-downtime DDL mechanism, resolution of the locking/conflict contradictions.", "evidenceIds": [ "turso-docs-3", "turso-docs-11", "turso-docs-18", "turso-docs-32", "turso-docs-41", "turso-docs-25", "turso-docs-33", "turso-docs-42", "turso-comm-4", "turso-comm-12" ] }, { "productId": "turso", "storyId": "scale-to-zero-idle", "verdict": "none", "quality": 0, "confidence": "low", "rationale": "The evidence pack covers durability, branching, embedded replicas, vector search, and pricing tiers, but nowhere states that idle Turso databases scale to zero or that idle usage incurs no cost while data remains durable. Without explicit documentation or community confirmation of scale-to-zero behavior, this story is unsupported by the given evidence.", "evidenceIds": [] }, { "productId": "turso", "storyId": "serverless-edge-driver", "verdict": "partial", "quality": 7, "confidence": "medium", "rationale": "Turso's docs and probes confirm an HTTP-based protocol (Hrana) with a real SQL roundtrip over the HTTP pipeline API, and official SDKs in TypeScript/Python/Rust/Go built on a stateless client model suited to short-lived connections. However, the evidence pack never explicitly discusses WebSocket transport or edge/serverless deployment targeting, so only part of the story is directly evidenced. Missing for 10: explicit documentation of WebSocket driver mode, explicit serverless/edge runtime guidance (e.g. Vercel/Cloudflare Workers examples), and independent hands-on confirmation of edge usage.", "evidenceIds": [ "turso-docs-13", "turso-probe-rt-2", "turso-docs-24" ] }, { "productId": "turso", "storyId": "spend-caps-alerts", "verdict": "none", "quality": 0, "confidence": "high", "rationale": "No evidence pack item mentions spend caps, budget limits, billing alerts, or usage-threshold notifications; pricing page references only mention plan tiers and VPC allow lists, not cost-control tooling. This is an applicable axis for a usage-billed cloud database, but nothing in the docs or community evidence shows Turso offers alerting or spend-capping features.", "evidenceIds": [ "turso-docs-22", "turso-docs-46" ] }, { "productId": "turso", "storyId": "transparent-usage-pricing", "verdict": "none", "quality": 0, "confidence": "medium", "rationale": "The evidence only shows a pricing page exists with tier names and feature toggles (e.g., 'AWS VPC Allow Lists', 'Free', 'Developer') but no per-unit rates for compute, storage, or traffic (e.g., $/GB, $/row-read, $/egress) are cited anywhere in the pack, so a founder cannot predict a bill from this evidence.", "evidenceIds": [ "turso-docs-22", "turso-docs-46" ] }, { "productId": "turso", "storyId": "vector-embeddings", "verdict": "full", "quality": 8, "confidence": "medium", "rationale": "Turso docs explicitly state native vector search support with no extensions required, supporting storage of embeddings alongside relational data and built-in distance functions for similarity search, and community evidence corroborates this as a genuine advantage over bolting vector extensions onto plain SQLite. Missing for 10: independent hands-on benchmarks of vector search performance/scale, and community feedback notes documentation on vector embeddings could be more robust.", "evidenceIds": [ "turso-docs-6", "turso-docs-36", "turso-docs-44", "turso-comm-3", "turso-comm-6" ] } ]