Qdrant vs Chroma

Agent access

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

   weight 2 · round drawn
   Qdrant✓fullprobed8/10

   A live probe confirms Qdrant serves an llms.txt file with an overview summary at qdrant.tech/llms.txt (HTTP 200), and Qdrant also ships agent-oriented skills/docs for AI coding assistants via GitHub. Missing for 10: no per-page markdown export (docs-md probe 404s) and no independent confirmation of how thoroughly agents actually consume/parse the llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://qdrant.tech/llms.txt # https://qdrant.tech/ ## Overall Summary > Qdrant is an Open-Source Vector Search …”
   • [github] “Install these skills to empower your agent in making critical engineering decisions for optimal vector search performance, such as quantizat…”
   • [github] “Qdrant provides a collection of ready-to-use agent skills that bring Qdrant's vector search capabilities directly into your AI coding assist…”

   proof ↗⚑ flag

   Chroma✓fullprobed8/10

   A direct probe confirms Chroma serves a working llms.txt file at docs.trychroma.com/llms.txt (HTTP 200) with structured links to agent-oriented docs, and Chroma's docs also explicitly instruct users to point AI agents (Claude Code, Cursor, Codex) at setup prompts. This directly satisfies the story of pointing an agent at llms.txt or agent-oriented docs. Missing for 10: independent/community confirmation that agents actually consume this file successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.trychroma.com/llms.txt # Chroma Docs - [Introduction](https://docs.trychroma.com/docs/overview/int…”
   • [claimed-docs] “Give the following prompt to Claude Code, Cursor, Codex, or your favorite AI agent. It will quickly set you up with Chroma.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Qdrant~partialcommunity6/10

   Qdrant runs headlessly via Docker with a REST/gRPC API and client SDKs, and is designed as a server process amenable to CI/scripted use (docker run, Python client create_collection, etc.), with community reports of production automation at scale. However, there is no explicit documentation or example of running Qdrant inside a CI pipeline, no headless test-harness or CI recipe, and no discussion of ephemeral/CI-specific configuration. missing for 10: explicit CI/automation guide or example, headless test-mode documentation, independent confirmation of CI usage.

   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 \ -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \ qdrant/qdrant”
   • [claimed-docs] “client.create_collection( collection_name="test_collection", vectors_config=VectorParams(size=4, distance=Distance.DOT), )”
   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 -v "$(pwd)/qdrant_storage:/qdrant/storage:z" qdrant/qdrant”
   • [github] “Qdrant offers the following client libraries to help you integrate it into your application stack”
   • [community] “We've been using Qdrant for over a year with 10s of millions of items, lots of daily inserts/deletions. A couple of gotchas but generally pr…”
   • [community] “We've been using qdrant in production for over a year. It's excellent and the team are very responsive to the few issues we've had. Qdrant d…”

   proof ↗⚑ flag

   Chroma~partialprobed6/10

   Chroma ships as an embeddable Python/JS client and a self-hostable server/CLI (run locally, self-host, or Chroma Cloud), which supports headless, scriptable use in automation pipelines, and the GitHub quick-start shows a non-interactive DB spin-up. However, there is no explicit CI/automation guide, Docker-in-CI example, or documented headless test harness pattern. missing for 10: explicit CI pipeline example/docs, headless/no-GUI confirmation beyond CLI mention, automated testing guidance.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Install the Chroma CLI to run a local server, browse collections, and interact with Chroma Cloud.”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [github] “Create a DB and try it out in under 30 seconds with $5 of free credits.”
   • [probe] “official CLI documented at https://docs.trychroma.com/docs/cli/install”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Qdrant✓fullprobed8/10

   Qdrant is a database/platform (not itself an agent), so an official MCP server axis applies, and evidence shows a documented official MCP server page plus GitHub-listed agent skills that integrate Qdrant's vector search into AI coding assistants. missing for 10: deeper first-party docs detailing MCP server setup/config and independent hands-on confirmation of the MCP server working.

   • [probe] “official MCP server documented at https://qdrant.tech/documentation/qdrant-mcp-server/”
   • [github] “Install these skills to empower your agent in making critical engineering decisions for optimal vector search performance, such as quantizat…”
   • [github] “Qdrant provides a collection of ready-to-use agent skills that bring Qdrant's vector search capabilities directly into your AI coding assist…”

   proof ↗⚑ flag

   Chroma✓fullprobed8/10

   Chroma ships an official MCP server that lets Claude (and by extension MCP-compatible agents) interact directly with Chroma's search capabilities, enabling persistent memory across conversations, and this is documented first-party and confirmed via a live docs probe. Missing for 10: independent/hands-on validation of the MCP server working in practice, and examples of other agents beyond Claude using it.

   • [claimed-docs] “The Chroma MCP server allows Claude to directly interact with Chroma’s search capabilities through this standardized protocol.”
   • [claimed-docs] “The Chroma MCP server allows Claude to directly interact with Chroma's search capabilities through this standardized protocol. This enables …”
   • [claimed-docs] “Persistent memory across conversations”
   • [probe] “official MCP server documented at https://docs.trychroma.com/integrations/frameworks/anthropic-mcp”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Chroma
   Qdrant—none0/10

   The evidence pack shows client libraries in multiple languages, Docker deployment, and agent skills for IDEs, but no mention of an official Qdrant CLI tool for AI-native workflows. This axis is plausible for a database product (e.g. a qdrant-cli for managing collections/points) but no such tool is evidenced.

   ⚑ flag

   Chroma✓fullprobed8/10

   Chroma ships an official CLI (documented and probed) that runs a local server, browses collections, installs sample apps, and interacts with Chroma Cloud, directly matching the AI-native CLI story. Missing for 10: independent/hands-on community corroboration of CLI usage and deeper coverage of agentic-specific CLI workflows beyond basic docs.

   • [claimed-docs] “Install the Chroma CLI to run a local server, browse collections, and interact with Chroma Cloud.”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [probe] “official CLI documented at https://docs.trychroma.com/docs/cli/install”

   proof ↗⚑ flag

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

   weight 3 · round to Chroma
   Qdrant✓fullprobed8/10

   Qdrant is fundamentally an API-first product: it exposes a documented REST/gRPC API with official client libraries in Python, JS/TS, Go, Rust, Java, .NET, and quickstart docs show programmatic collection creation, search, filtering, and hybrid queries, all consumable by an AI agent. missing for 10: a publicly discoverable OpenAPI/swagger spec (probe found all candidate OpenAPI paths 404) and independent hands-on confirmation specifically of API completeness/stability beyond general community praise for core functionality.

   • [github] “It provides a production-ready service with a convenient API to store, search, and manage points—vectors with an additional payload.”
   • [github] “Qdrant offers the following client libraries to help you integrate it into your application stack”
   • [github] “Go client ... Rust client ... JavaScript/TypeScript client ... Python client ... .NET/C# client ... Java client”
   • [claimed-docs] “client.create_collection( collection_name="test_collection", vectors_config=VectorParams(size=4, distance=Distance.DOT), )”
   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 \ -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \ qdrant/qdrant”
   • [probe] “PROBE openapi: all candidate paths 404 (https://qdrant.tech/openapi.json, https://qdrant.tech/swagger.json, https://qdrant.tech/api/openapi.…”
   • [community] “After testing numerous open source vector databases, Qdrant is the best option: docs are clear, easy to build from source in Rust (~30 min),…”

   proof ↗⚑ flag

   Chroma✓fullprobed9/10

   Chroma exposes a documented public API (client libraries, REST/OpenAPI schema, CLI) confirmed by both official docs and a live probe of its openapi.json, plus llms.txt for AI-native discovery, and it is explicitly promoted for use by AI coding agents (Claude Code, Cursor, Codex) to set up and query the DB. Missing for 10: independent third-party benchmarking or hands-on developer confirmation of API robustness beyond vendor docs/probes.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.trychroma.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.trychroma.com/llms.txt # Chroma Docs - [Introduction](https://docs.trychroma.com/docs/overview/int…”
   • [claimed-docs] “Give the following prompt to Claude Code, Cursor, Codex, or your favorite AI agent. It will quickly set you up with Chroma.”
   • [claimed-docs] “Install the Chroma CLI to run a local server, browse collections, and interact with Chroma Cloud.”
   • [probe] “official CLI documented at https://docs.trychroma.com/docs/cli/install”
   • [claimed-docs] “You can query the collection with a list of query texts, and Chroma will return the n most similar results.”

   proof ↗⚑ flag

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

   weight 2 · round to Qdrant
   Qdrant✓fullclaimed8/10

   Qdrant docs explicitly describe three API key tiers—Admin, Read-Only, and Granular Access API Keys with per-collection read/write scoping—enabling least-privilege credential issuance for agents accessing specific collections. This is documented first-party functionality directly matching the story, though there's no independent/hands-on corroboration or agent-specific tutorial. Missing for 10: independent verification of granular API key behavior in practice, and explicit agent-oriented documentation tying this to agentic workflows.

   • [claimed-docs] “Qdrant supports three types of API key: **Admin API Key**... **Read-Only API Key**... **Granular Access API Keys**”
   • [claimed-docs] “Qdrant supports API key authentication (including read-only API keys for query-only consumers and granular access API keys with per-collecti…”
   • [claimed-docs] “Qdrant supports API key authentication ... network binding, TLS for encrypted connections, and audit logging for compliance.”

   proof ↗⚑ flag

   Chroma—none0/10

   No evidence of scoped or least-privilege API credential issuance for agents; the evidence pack covers embeddings, querying, CLI, MCP server, and pricing but never mentions API key scoping, RBAC, or per-agent credential management in Chroma Cloud or self-hosted deployments.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Qdrant
   Qdrant✓fullcommunity8/10

   Qdrant provides official client SDKs across many languages (Python, Go, Rust, JS/TS, .NET/C#, Java) with documented usage examples (create_collection code sample), plus community corroboration of smooth onboarding with the Python client. Missing for 10: independent benchmarking of SDK completeness/parity across languages and more first-party API reference docs beyond quickstart snippets.

   • [github] “Qdrant offers the following client libraries to help you integrate it into your application stack”
   • [github] “Go client ... Rust client ... JavaScript/TypeScript client ... Python client ... .NET/C# client ... Java client”
   • [claimed-docs] “client.create_collection( collection_name="test_collection", vectors_config=VectorParams(size=4, distance=Distance.DOT), )”
   • [community] “Just played with qdrant using its Python client. Pretty smooth onboarding experience, though having to generate embeddings client-side rathe…”
   • [community] “After testing numerous open source vector databases, Qdrant is the best option: docs are clear, easy to build from source in Rust (~30 min),…”

   proof ↗⚑ flag

   Chroma~partialprobed7/10

   Chroma documents official Python/JS SDK usage patterns (getting-started, querying, embedding integration) and an OpenAPI spec, CLI, and MCP server, showing a well-documented SDK surface for AI-native workflows. missing for 10: independent hands-on developer corroboration of SDK ergonomics/completeness, explicit multi-language SDK reference docs beyond Python examples, and community validation of SDK reliability at scale.

   • [claimed-docs] “Chroma will store your text and handle embedding and indexing automatically.”
   • [claimed-docs] “You can query the collection with a list of query texts, and Chroma will return the n most similar results.”
   • [claimed-docs] “Use any embedding model. OpenAI, Cohere, Hugging Face, sentence-transformers, and more.”
   • [claimed-docs] “In this directory create a new Python project with Chroma set up. Use a virtual environment.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.trychroma.com/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.trychroma.com/docs/cli/install”
   • [claimed-docs] “Give the following prompt to Claude Code, Cursor, Codex, or your favorite AI agent. It will quickly set you up with Chroma.”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Qdrant—none0/10

   No evidence anywhere in the pack of webhook subscriptions, event notifications, or pub/sub-style triggers from Qdrant; the product's evidence covers storage, search, deployment, security, and clients but nothing about event-driven webhook subscriptions.

   ⚑ flag

   Chroma—none0/10

   No evidence in the pack mentions webhooks or event subscription mechanisms for Chroma; the product is a vector database and its documented integrations (MCP, CLI, APIs) do not include any webhook/event-push feature.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   Qdrant—none0/10

   Qdrant is positioned as a vector search infrastructure/database with client libraries, deployment, and security features, but the evidence pack contains no mention of any built-in AI-generated insights, analytics, or suggestion features surfaced to users inside the product itself.

   ⚑ flag

   Chroma—none0/10

   Chroma is positioned as a vector/embedding database and retrieval backend (storage, indexing, querying, MCP-based agent access) rather than a product that itself surfaces AI-generated insights or suggestions to the user; none of the evidence describes built-in analytics, summarization, or recommendation features inside Chroma's own interface.

   ⚑ flag

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

   weight 3 · round drawn
   Qdrant—none0/10

   Evidence shows only external integrations (agent skills for coding assistants, an MCP server for external agents to query Qdrant) but no built-in AI assistant embedded within the Qdrant product itself that a user could delegate tasks to.

   • [github] “Install these skills to empower your agent in making critical engineering decisions for optimal vector search performance, such as quantizat…”
   • [github] “Qdrant provides a collection of ready-to-use agent skills that bring Qdrant's vector search capabilities directly into your AI coding assist…”
   • [probe] “official MCP server documented at https://qdrant.tech/documentation/qdrant-mcp-server/”

   proof ↗⚑ flag

   Chroma—none0/10

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

   ⚑ flag

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

   weight 2 · round to Chroma
   Qdrant~partialprobed5/10

   Qdrant ships an official MCP server (qdrant-mcp-server) and 'agent skills' for AI coding assistants that expose its vector-search operations (quantization, sharding, hybrid search, etc.) for agentic use, which lets an AI agent translate natural-language requests into Qdrant operations. However, there is no first-party natural-language query interface, no documented examples of end-to-end NL command usage, and no independent/hands-on evidence validating this workflow. missing for 10: direct NL-command examples/docs, hands-on validation of the MCP server or agent skills in use, and any built-in NL query capability outside of agent-mediated tool calls.

   • [probe] “official MCP server documented at https://qdrant.tech/documentation/qdrant-mcp-server/”
   • [github] “Install these skills to empower your agent in making critical engineering decisions for optimal vector search performance, such as quantizat…”
   • [github] “Qdrant provides a collection of ready-to-use agent skills that bring Qdrant's vector search capabilities directly into your AI coding assist…”

   proof ↗⚑ flag

   Chroma~partialprobed6/10

   Chroma ships an official MCP server that lets Claude (and by extension other MCP-enabled agents) interact with Chroma's search/storage via natural-language requests, and docs explicitly promote giving NL prompts to Claude Code/Cursor/Codex to set up and use Chroma. However, this is agent-mediated (through MCP) rather than a native NL command interface, and there's no independent/hands-on evidence validating reliability of these NL-driven interactions. Missing for 10: independent corroboration of the MCP/NL workflow in practice, and evidence of a native NL query interface outside of agent integrations.

   • [claimed-docs] “The Chroma MCP server allows Claude to directly interact with Chroma’s search capabilities through this standardized protocol.”
   • [claimed-docs] “The Chroma MCP server allows Claude to directly interact with Chroma's search capabilities through this standardized protocol. This enables …”
   • [claimed-docs] “Give the following prompt to Claude Code, Cursor, Codex, or your favorite AI agent. It will quickly set you up with Chroma.”
   • [probe] “official MCP server documented at https://docs.trychroma.com/integrations/frameworks/anthropic-mcp”
   • [claimed-docs] “Persistent memory across conversations”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Chroma
   Qdrant—none0/10

   The evidence pack shows no interactive API reference with runnable examples; a probe explicitly found no OpenAPI/Swagger spec at any candidate URL, and no docs mention runnable code snippets or an API playground. Docs only show static code blocks (docker run, Python client calls) rather than an interactive reference tool.

   • [probe] “PROBE openapi: all candidate paths 404 (https://qdrant.tech/openapi.json, https://qdrant.tech/swagger.json, https://qdrant.tech/api/openapi.…”
   • [claimed-docs] “client.create_collection( collection_name="test_collection", vectors_config=VectorParams(size=4, distance=Distance.DOT), )”
   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 \ -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \ qdrant/qdrant”

   proof ↗⚑ flag

   Chroma~partialprobed4/10

   Chroma exposes a machine-readable OpenAPI spec and an llms.txt AI-friendly docs index, which are building blocks for interactive/AI-native API exploration, and its docs include code snippets for getting started. However there's no direct evidence of an interactive API reference UI (e.g., a Swagger/Redoc explorer) or in-browser runnable examples. Missing for 10: explicit interactive API console/playground, runnable code execution in docs, independent confirmation of an interactive reference experience.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.trychroma.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.trychroma.com/llms.txt # Chroma Docs - [Introduction](https://docs.trychroma.com/docs/overview/int…”
   • [claimed-docs] “Chroma will store your text and handle embedding and indexing automatically.”
   • [claimed-docs] “In this directory create a new Python project with Chroma set up. Use a virtual environment.”

   proof ↗⚑ flag

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

   weight 2 · round to Chroma
   Qdrant—none0/10

   No evidence of a downloadable OpenAPI/machine-readable spec; direct probes for openapi.json/swagger.json paths all returned 404, and no doc page references an API spec download for Qdrant's REST/gRPC API.

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

   proof ↗⚑ flag

   Chroma✓fullprobed9/10

   Chroma exposes a live OpenAPI spec at /openapi.json confirmed by direct probe, and also provides a machine-readable llms.txt docs index, satisfying the ask for a downloadable machine-readable API spec. Missing for 10: no independent/community corroboration of third-party usage of the OpenAPI spec.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.trychroma.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.trychroma.com/llms.txt # Chroma Docs - [Introduction](https://docs.trychroma.com/docs/overview/int…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Qdrant~partialcommunity6/10

   Qdrant can be run entirely locally via Docker with local storage, and community evidence highlights an easy in-memory 'sqlite-like' mode ideal for POC/testing separate from production data. There's also a free cloud tier for trying things out without payment. However, there's no first-party documented 'sandbox environment' feature, staging/test-mode toggle, or explicit guidance on isolating test vs prod within the same deployment. Missing for 10: dedicated sandbox/staging environment docs, first-party guidance on test-vs-prod data isolation, independent corroboration of safe sandbox testing workflow.

   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 \ -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \ qdrant/qdrant”
   • [community] “One of the big advantages of Qdrant is how easy it is to do a POC because it allows an 'in-memory' version similar to sqlite. Milvus by comp…”
   • [claimed-docs] “No token limits ... No payment method required”

   proof ↗⚑ flag

   Chroma~partialcommunity6/10

   Chroma supports local/self-hosted runs and copy-on-write 'Forking' for dataset versioning, A/B testing, and roll-outs, which lets users test against a copy of data without touching production, and this forking use case is corroborated by community mentions of code-search testing. However, there's no explicit 'sandbox environment' feature or dedicated staging/test-mode documentation distinct from forking/local instances. Missing for 10: an explicit sandbox/staging environment concept, first-party guidance on isolating test vs prod data, and independent hands-on confirmation that forks/local runs fully replicate production behavior safely.

   • [claimed-docs] “Forking Dataset versioning, A/B testing, and roll-outs”
   • [claimed-docs] “Forks are copy-on-write. You only pay for incremental storage written after the fork; unchanged data remains shared.”
   • [claimed-docs] “Forking a collection costs $0.03 per fork request. Forks are copy-on-write. You only pay for incremental storage written after the fork; unc…”
   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [community] “Chroma has built in regex+trigram search and copy-on-write forking of indexes. this feature combo is killer for the code-search use case.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Qdrant—none0/10

   No evidence of a documented API versioning scheme or deprecation policy; probes for OpenAPI spec returned 404s and no docs mention version support/deprecation guarantees.

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

   proof ↗⚑ flag

   Chroma—none0/10

   No evidence pack item mentions API versioning scheme, version numbers, or a documented deprecation policy for Chroma's API; only general docs on features, CLI, MCP, and pricing are present. Missing for 10: any mention of API versioning, changelog, or deprecation/backward-compatibility policy.

   ⚑ flag

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

   weight 2 · round to Chroma
   Qdrant~partialcommunity3/10

   Evidence doesn't cite Qdrant's batch upsert/delete/query APIs directly, but community reports of production use with '10s of millions of items, lots of daily inserts/deletions' imply bulk operations are supported at scale, and the client SDK docs show programmatic point/collection management that would underlie bulk workflows. missing for 10: explicit documentation of batch upsert/delete/query endpoints, bulk import tooling, and performance/throughput benchmarks for large-batch operations.

   • [community] “We've been using Qdrant for over a year with 10s of millions of items, lots of daily inserts/deletions. A couple of gotchas but generally pr…”
   • [claimed-docs] “client.create_collection( collection_name="test_collection", vectors_config=VectorParams(size=4, distance=Distance.DOT), )”
   • [github] “Go client ... Rust client ... JavaScript/TypeScript client ... Python client ... .NET/C# client ... Java client”

   proof ↗⚑ flag

   Chroma~partialclaimed6/10

   Docs confirm batch-style operations: querying with a list of query texts returns top-n matches per query (chroma-docs-2), and metadata/full-text filters operate across the whole collection at once (chroma-docs-3/4/22), plus dataset-level bulk operations like forking for versioning/A-B testing (chroma-docs-8/18/26). However, there's no explicit documentation of bulk insert/update/delete APIs (e.g., batch add of thousands of embeddings, bulk delete by filter) in the evidence pack. Missing for 10: explicit bulk insert/update/delete API docs, and independent hands-on confirmation of large-batch throughput/limits.

   • [claimed-docs] “You can query the collection with a list of query texts, and Chroma will return the n most similar results.”
   • [claimed-docs] “We support full-text search with the $contains and $not_contains operators. We also support regular expression pattern matching with the $re…”
   • [claimed-docs] “.get and .query can handle where_document search combined with metadata filtering”
   • [claimed-docs] “Forking Dataset versioning, A/B testing, and roll-outs”
   • [claimed-docs] “Forks are copy-on-write. You only pay for incremental storage written after the fork; unchanged data remains shared.”
   • [claimed-docs] “Forking a collection costs $0.03 per fork request. Forks are copy-on-write. You only pay for incremental storage written after the fork; unc…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Qdrant—none0/10

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

   ⚑ flag

   Chroma—none0/10

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

   ⚑ flag

Backup

1. platform-engineerBack up collections with snapshots and restore them

   weight 2 · round to Qdrant
   Qdrant✓fullclaimed8/10

   Qdrant docs explicitly document snapshots as tar archives capturing collection data/config at a point in time, per-node, which is the mechanism for backup and restore of collections; this is a first-party documented feature (qdrant-docs-6/21). Missing for 10: no independent/hands-on community confirmation of snapshot restore workflows or edge-case reliability.

   • [claimed-docs] “Snapshots are `tar` archive files that contain data and configuration of a specific collection on a specific node at a specific time.”
   • [claimed-docs] “Snapshots are tar archive files that contain data and configuration of a specific collection on a specific node at a specific time.”

   proof ↗⚑ flag

   Chroma~partialclaimed3/10

   Chroma documents 'point-in-time-recovery' as part of its BYOC/Cloud offering and separately offers collection 'Forking' (copy-on-write dataset versioning) which can serve snapshot-like purposes, but there is no dedicated backup/restore API, CLI command, or documented workflow for creating and restoring a snapshot of a collection. Missing for 10: explicit snapshot/export-import or backup CLI commands, restore procedure documentation, and independent confirmation that point-in-time-recovery actually restores a full collection state.

   • [claimed-docs] “BYOC in your VPC, multi-cloud/multi-region replication, point-in-time-recovery ensure a resilient and scalable search system with the same 0…”
   • [claimed-docs] “Forking Dataset versioning, A/B testing, and roll-outs”
   • [claimed-docs] “Forks are copy-on-write. You only pay for incremental storage written after the fork; unchanged data remains shared.”
   • [claimed-docs] “Forking a collection costs $0.03 per fork request. Forks are copy-on-write. You only pay for incremental storage written after the fork; unc…”

   proof ↗⚑ flag

Freshness

1. developerUpsert and delete records continuously and have changes reflected in search results quickly, with documented freshness/consistency behavior

   weight 2 · round to Qdrant
   Qdrant~partialcommunity4/10

   Community evidence confirms Qdrant handles continuous high-volume inserts/deletions reliably in production (qdrant-comm-1, qdrant-comm-5), and docs describe distributed deployment and snapshots, but the evidence pack lacks explicit documentation of freshness/consistency semantics (e.g., read-after-write guarantees, consistency levels, replication ordering) for upserts/deletes. missing for 10: documented consistency/freshness guarantees (e.g., write-ahead log, replication consistency modes, read-your-writes semantics), benchmarks on update-to-search latency.

   • [community] “We've been using Qdrant for over a year with 10s of millions of items, lots of daily inserts/deletions. A couple of gotchas but generally pr…”
   • [community] “We've been using qdrant in production for over a year. It's excellent and the team are very responsive to the few issues we've had. Qdrant d…”
   • [claimed-docs] “Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data acr…”
   • [claimed-docs] “Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data acr…”

   proof ↗⚑ flag

   Chroma—none0/10

   The evidence pack covers embedding, querying, full-text search, CLI, MCP, and cloud forking, but contains no documentation of upsert/delete freshness or consistency guarantees for search results. No mention of read-after-write behavior, indexing latency, or eventual-consistency semantics anywhere in the pack.

   ⚑ flag

Portability

1. developerBulk-import and bulk-export vectors plus metadata in documented formats

   weight 2 · round to Qdrant
   Qdrant~partialclaimed5/10

   Qdrant's snapshot feature (tar archives containing full collection data and config) provides a documented mechanism for exporting and re-importing vectors plus metadata at the collection level, and batch upsert APIs are implied by the client SDK docs. However, there is no evidence of a dedicated bulk import/export tool or documented interchange formats (e.g., CSV/JSON/Parquet import, mass export API) beyond the snapshot archive mechanism. Missing for 10: documented bulk import/export CLI or API distinct from full-collection snapshots, support for common interchange formats, and independent confirmation of round-trip fidelity for large-scale migrations.

   • [claimed-docs] “Snapshots are `tar` archive files that contain data and configuration of a specific collection on a specific node at a specific time.”
   • [claimed-docs] “Snapshots are tar archive files that contain data and configuration of a specific collection on a specific node at a specific time.”
   • [claimed-docs] “client.create_collection( collection_name="test_collection", vectors_config=VectorParams(size=4, distance=Distance.DOT), )”

   proof ↗⚑ flag

   Chroma—none0/10

   No evidence pack item documents a bulk-import or bulk-export feature, file format spec, or CLI/API command for moving vectors+metadata in/out of Chroma; forking (chroma-docs-8/18/26) is copy-on-write cloning, not data export/import. Axis applies to any vector database but no supporting evidence exists.

   ⚑ flag

Local dev

1. developerRun the database embedded in-process or as a lightweight local instance for development and small workloads

   weight 2 · round drawn
   Qdrant✓fullcommunity8/10

   Qdrant ships both a lightweight local Docker instance for dev (qdrant-docs-1/16) and 'Qdrant Edge', an explicitly embedded, in-process, no-network-required engine for kiosks/mobile/robots (qdrant-docs-10/14), and community reports confirm an easy in-memory/sqlite-like POC mode for local development (qdrant-comm-4). Missing for 10: independent hands-on validation of Qdrant Edge specifically (it's a newer offering) and explicit documentation of the Python client's embedded ':memory:' mode in the evidence pack.

   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 \ -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \ qdrant/qdrant”
   • [claimed-docs] “Qdrant Edge is a lightweight, embedded vector search engine for in-process retrieval — no background services, minimal memory footprint, and…”
   • [claimed-docs] “Qdrant Edge is a lightweight, embedded vector search engine for in-process retrieval — no background services, minimal memory footprint, and…”
   • [community] “One of the big advantages of Qdrant is how easy it is to do a POC because it allows an 'in-memory' version similar to sqlite. Milvus by comp…”

   proof ↗⚑ flag

   Chroma✓fullprobed8/10

   Chroma docs explicitly state it can be run locally/embedded, self-hosted, or via the CLI to spin up a lightweight local server, in addition to Chroma Cloud, and community comments corroborate operational simplicity for small deployments (chroma-docs-9, chroma-docs-15, chroma-docs-5, chroma-docs-23, chroma-comm-4). Missing for 10: explicit in-process/embedded-mode code example (e.g. PersistentClient in Python) and independent hands-on confirmation of embedded usage rather than just docs.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Install the Chroma CLI to run a local server, browse collections, and interact with Chroma Cloud.”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [probe] “official CLI documented at https://docs.trychroma.com/docs/cli/install”
   • [community] “The main reason we have seen people switch from Qdrant to Chroma is for operational simplicity and reliability. With Qdrant you have to size…”

   proof ↗⚑ flag

Managed cloud

1. developerUse a fully managed cloud version of the database with programmatic provisioning

   weight 2 · round to Chroma
   Qdrant~partialcommunity4/10

   Evidence only mentions Qdrant Cloud tangentially (free tier, no credit card, docs mention 'cloud-hosted embedding models') and Private Cloud on Kubernetes, but there is no documentation of programmatic provisioning (API/Terraform/CLI to create managed clusters) for the fully managed cloud offering. missing for 10: dedicated Qdrant Cloud docs, Cloud API/Terraform provider or CLI for programmatic cluster creation, independent confirmation of managed cloud provisioning workflow.

   • [claimed-docs] “No token limits ... No payment method required”
   • [claimed-docs] “Configure dense, sparse, and multi-vector embeddings. Use cloud-hosted embedding models directly with Qdrant.”
   • [claimed-docs] “Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure.”
   • [community] “I like their pricing page and business model: Apache-2.0 license, free tier with a free forever 1GB cluster for trying out, no credit card r…”

   proof ↗⚑ flag

   Chroma~partialcommunity6/10

   Chroma Cloud is documented as a managed, serverless offering (chroma-docs-9/15) with a CLI that can create and interact with Cloud DBs (chroma-docs-5/14/23) and GitHub notes creating a DB in under 30 seconds (chroma-gh-1), corroborated by community reports of '0-ops' cloud use (chroma-comm-4). However, evidence lacks explicit documentation of a programmatic API/SDK (e.g. REST or Python API) for provisioning databases beyond the CLI. Missing for 10: dedicated API/SDK docs for programmatic provisioning, infrastructure-as-code examples, and independent hands-on confirmation of automated provisioning workflows.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Install the Chroma CLI to run a local server, browse collections, and interact with Chroma Cloud.”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [github] “Create a DB and try it out in under 30 seconds with $5 of free credits.”
   • [community] “The main reason we have seen people switch from Qdrant to Chroma is for operational simplicity and reliability. With Qdrant you have to size…”

   proof ↗⚑ flag

Self managed

1. platform-engineerDeploy to production on Kubernetes with an official Helm chart or operator

   weight 1 · round to Qdrant
   Qdrant~partialclaimed4/10

   Docs mention 'Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure' and generic 'Deploy Qdrant on any infrastructure' guidance, implying Kubernetes-native deployment tooling, but the evidence never explicitly names a Helm chart or a Kubernetes operator. missing for 10: explicit documentation of an official Helm chart, explicit mention of a Kubernetes operator/CRDs, and independent confirmation of production use via these tools.

   • [claimed-docs] “Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure.”
   • [claimed-docs] “Deploy Qdrant on any infrastructure. Get requirements, configuration options, and GPU setup guides.”

   proof ↗⚑ flag

   Chroma—none0/10

   No evidence of an official Helm chart or Kubernetes operator; docs mention self-hosting, BYOC, and Chroma Cloud but nothing about Kubernetes-native deployment tooling. Missing for 10: official Helm chart, Kubernetes operator, or documented K8s deployment guide.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “We offer a BYOC (bring your own cloud) option for single-tenant deployments.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “BYOC in your VPC, multi-cloud/multi-region replication, point-in-time-recovery ensure a resilient and scalable search system with the same 0…”

   proof ↗⚑ flag

Embeddings

1. ml-engineerHave the database generate embeddings at ingest and query time using built-in or configured model providers, instead of running a separate embedding pipeline

   weight 3 · round to Chroma
   Qdrant!disputedcontradicted4/10

   Qdrant's docs claim built-in support for 'cloud-hosted embedding models directly with Qdrant' and configurable dense/sparse/multi-vector embeddings (qdrant-docs-9), suggesting some inference-at-ingest capability. However, a hands-on community report explicitly contradicts this, noting embeddings had to be generated client-side rather than in the DB, which 'felt somewhat besides the point' (qdrant-comm-8) — indicating the built-in embedding generation is either limited, add-on (e.g. FastEmbed/Inference API), or not as seamless as marketed. Missing for 10: first-party documentation walkthrough of configuring a model provider for automatic ingest+query-time embedding, and corroborating hands-on evidence that this actually works end-to-end without a separate pipeline.

   • [claimed-docs] “Configure dense, sparse, and multi-vector embeddings. Use cloud-hosted embedding models directly with Qdrant.”
   • [community] “Just played with qdrant using its Python client. Pretty smooth onboarding experience, though having to generate embeddings client-side rathe…”

   proof ↗⚑ flag

   Chroma✓fullclaimed8/10

   Chroma docs confirm automatic embedding generation at ingest and query time ("Chroma will store your text and handle embedding and indexing automatically") and support for pluggable/configurable embedding providers (OpenAI, Cohere, Hugging Face, sentence-transformers), matching the story's built-in/configured-provider need. Missing for 10: independent hands-on validation of embedding-function configuration and no detail on provider-specific setup/limitations beyond docs.

   • [claimed-docs] “Chroma will store your text and handle embedding and indexing automatically.”
   • [claimed-docs] “You can query the collection with a list of query texts, and Chroma will return the n most similar results.”
   • [claimed-docs] “Use any embedding model. OpenAI, Cohere, Hugging Face, sentence-transformers, and more.”
   • [claimed-docs] “Chroma will store your text and handle embedding and indexing automatically. You can also customize the embedding model.”

   proof ↗⚑ flag

Filtering

1. developerFilter vector search by structured metadata conditions without wrecking recall or latency

   weight 3 · round to Qdrant
   Qdrant~partialcommunity6/10

   Qdrant docs confirm rich structured payload filtering with AND/OR/NOT clauses and payload-based tenant partitioning, which is designed to be efficient at scale, but there is no direct benchmark or evidence quantifying recall/latency impact when filters are applied (e.g., filterable HNSW index behavior under heavy filtering). Community comments praise general speed/accuracy but don't specifically address filtered-search recall/latency tradeoffs. missing for 10: benchmark data or documentation showing filtered search maintains recall/latency (e.g., filterable index/payload indexing performance), independent corroboration of filter performance at scale.

   • [claimed-docs] “Qdrant allows you to combine conditions in clauses. Clauses are different logical operations, such as `OR`, `AND`, and `NOT`.”
   • [claimed-docs] “Qdrant allows you to combine conditions in clauses. Clauses are different logical operations, such as OR, AND, and NOT.”
   • [claimed-docs] “Partition by payload filters points by a payload field that identifies the tenant. This is efficient for a large number of small, similarly-…”
   • [claimed-docs] “keep all tenants in a single collection and use one of these three approaches to isolate them: Partition by payload”
   • [community] “We've been using Qdrant for over a year with 10s of millions of items, lots of daily inserts/deletions. A couple of gotchas but generally pr…”
   • [community] “I've been using Qdrant. Can't speak highly enough of the core functionality. It's fast, good accuracy, easy to use. Wish finding/updating po…”

   proof ↗⚑ flag

   Chroma~partialclaimed4/10

   Chroma's docs confirm metadata filtering exists and can be combined with full-text/document search (`.get`/`.query` combined with `where_document` and metadata filtering, $contains/$regex operators), but there is no first-party or community evidence addressing how filtering affects recall or query latency at scale. Missing for 10: benchmarks or documentation on filtered-search performance/recall trade-offs, independent hands-on tests confirming filtering doesn't degrade ANN recall or add latency.

   • [claimed-docs] “.get and .query can handle where_document search combined with metadata filtering”
   • [claimed-docs] “`.get` and `.query` can handle `where_document` search combined with metadata filtering”
   • [claimed-docs] “We support full-text search with the $contains and $not_contains operators. We also support regular expression pattern matching with the $re…”
   • [claimed-docs] “We support full-text search with the `$contains` and `$not_contains` operators. We also support regular expression pattern matching with the…”

   proof ↗⚑ flag

2. developerExpress rich filter conditions (ranges, geo, nested boolean logic, array membership) in queries

   weight 2 · round to Qdrant
   Qdrant~partialclaimed5/10

   Docs confirm Qdrant filtering supports combining conditions with boolean clauses (AND/OR/NOT) for nested logic, but the evidence pack contains no explicit documentation of range filters, geo filters, or array/membership conditions. missing for 10: range condition docs, geo filter docs, array/membership match docs, independent corroboration of these specific filter types.

   • [claimed-docs] “Qdrant allows you to combine conditions in clauses. Clauses are different logical operations, such as `OR`, `AND`, and `NOT`.”
   • [claimed-docs] “Qdrant allows you to combine conditions in clauses. Clauses are different logical operations, such as OR, AND, and NOT.”

   proof ↗⚑ flag

   Chroma~partialclaimed3/10

   Docs confirm metadata filtering can be combined with full-text/document search ($contains, $regex, $not_contains) via .get/.query, but the evidence pack never documents range operators, geo filters, nested AND/OR boolean logic, or array membership ($in) operators explicitly. missing for 10: range query operators, geo filtering, nested boolean logic (AND/OR), array membership operators, and independent confirmation of these advanced filter semantics.

   • [claimed-docs] “We support full-text search with the $contains and $not_contains operators. We also support regular expression pattern matching with the $re…”
   • [claimed-docs] “.get and .query can handle where_document search combined with metadata filtering”
   • [claimed-docs] “`.get` and `.query` can handle `where_document` search combined with metadata filtering”
   • [claimed-docs] “We support full-text search with the `$contains` and `$not_contains` operators. We also support regular expression pattern matching with the…”

   proof ↗⚑ flag

Scaling

1. platform-engineerScale beyond one node with sharding or distributed deployment

   weight 2 · round to Qdrant
   Qdrant✓fullcommunity8/10

   Qdrant documents native distributed deployment mode that shards and distributes data across peers, plus sharding-adjacent multi-tenant partitioning strategies and Kubernetes-based Private Cloud clusters for horizontal scale, with community reports confirming production use at tens of millions of items. Missing for 10: independent benchmarks of multi-node cluster performance/failover behavior and more detailed hands-on validation of resharding/rebalancing at scale.

   • [claimed-docs] “Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data acr…”
   • [claimed-docs] “Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data acr…”
   • [claimed-docs] “keep all tenants in a single collection and use one of these three approaches to isolate them”
   • [claimed-docs] “Partition by payload filters points by a payload field that identifies the tenant. This is efficient for a large number of small, similarly-…”
   • [claimed-docs] “Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure.”
   • [community] “We've been using Qdrant for over a year with 10s of millions of items, lots of daily inserts/deletions. A couple of gotchas but generally pr…”
   • [community] “We've been using qdrant in production for over a year. It's excellent and the team are very responsive to the few issues we've had. Qdrant d…”

   proof ↗⚑ flag

   Chroma~partialcommunity6/10

   Chroma Cloud is documented and reported (via HN discussion) to support sharding via collections, distributed scaling, and multi-cloud/multi-region replication (chroma-comm-2, chroma-docs-28), and BYOC offers single-tenant VPC deployments with resilience features. However, first-party docs mostly frame self-hosting as a single-node/local option (chroma-docs-9, chroma-docs-15) and a competitor comparison notes self-hosted Chroma avoids manual sharding/ops entirely, implying distributed scaling is chiefly a managed-Cloud capability rather than a documented self-hosted clustering feature. Missing for 10: first-party technical documentation on self-hosted multi-node/sharded cluster architecture, and independent hands-on verification of horizontal scaling beyond one node.

   • [community] “Chroma Cloud: Better indexes (SPANN/SPFresh), sharding via collections, distributed scaling, and object storage on S3 with cold/warm tiers f…”
   • [claimed-docs] “BYOC in your VPC, multi-cloud/multi-region replication, point-in-time-recovery ensure a resilient and scalable search system with the same 0…”
   • [community] “The main reason we have seen people switch from Qdrant to Chroma is for operational simplicity and reliability. With Qdrant you have to size…”
   • [claimed-docs] “We offer a BYOC (bring your own cloud) option for single-tenant deployments.”
   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”

   proof ↗⚑ flag

2. platform-engineerReplicate data across nodes or zones for high availability with a documented consistency model

   weight 2 · round to Qdrant
   Qdrant~partialcommunity6/10

   Qdrant documents distributed deployment across peers, replication via snapshots, and cluster consistency mechanisms (raft-based), and supports multi-region/Kubernetes deployment for HA; community reports confirm production use at scale. However, the evidence pack lacks explicit documentation of the consistency model (e.g., read/write consistency levels, tunable quorum) or zone-aware replication guarantees. Missing for 10: explicit consistency-model documentation (read/write consistency factors, quorum tuning), zone-awareness/multi-AZ replication guidance, and independent verification of failover behavior under partition.

   • [claimed-docs] “Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data acr…”
   • [claimed-docs] “Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data acr…”
   • [claimed-docs] “Snapshots are `tar` archive files that contain data and configuration of a specific collection on a specific node at a specific time.”
   • [claimed-docs] “Snapshots are tar archive files that contain data and configuration of a specific collection on a specific node at a specific time.”
   • [claimed-docs] “Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure.”
   • [community] “We've been using Qdrant for over a year with 10s of millions of items, lots of daily inserts/deletions. A couple of gotchas but generally pr…”
   • [community] “We've been using qdrant in production for over a year. It's excellent and the team are very responsive to the few issues we've had. Qdrant d…”

   proof ↗⚑ flag

   Chroma~partialcommunity3/10

   Chroma Cloud/BYOC docs mention 'multi-cloud/multi-region replication' and point-in-time-recovery, and community comments reference sharding/distributed scaling for Chroma Cloud, but there is no documented consistency model (e.g., eventual vs strong consistency, quorum, replication factor) anywhere in the evidence. missing for 10: explicit consistency-model documentation, replication configuration details, failover/consistency guarantees, independent verification of HA behavior.

   • [claimed-docs] “BYOC in your VPC, multi-cloud/multi-region replication, point-in-time-recovery ensure a resilient and scalable search system with the same 0…”
   • [community] “Chroma Cloud: Better indexes (SPANN/SPFresh), sharding via collections, distributed scaling, and object storage on S3 with cold/warm tiers f…”

   proof ↗⚑ flag

Tenancy

1. platform-engineerEnforce granular access control (API keys, roles, per-collection permissions) on database operations

   weight 2 · round to Qdrant
   Qdrant✓fullclaimed8/10

   Qdrant's docs explicitly describe Admin, Read-Only, and Granular Access API keys with per-collection read/write scoping, plus network binding, TLS, and audit logging for compliance — directly matching the platform-engineer story of API keys, roles, and per-collection permissions. Missing for 10: no independent/hands-on corroboration of the granular access controls in practice, and no mention of finer role-based (RBAC) features beyond key-based scoping.

   • [claimed-docs] “Qdrant supports three types of API key: **Admin API Key**... **Read-Only API Key**... **Granular Access API Keys**”
   • [claimed-docs] “Qdrant supports API key authentication ... network binding, TLS for encrypted connections, and audit logging for compliance.”
   • [claimed-docs] “Qdrant supports API key authentication (including read-only API keys for query-only consumers and granular access API keys with per-collecti…”

   proof ↗⚑ flag

   Chroma—none0/10

   No evidence in the pack mentions API keys, roles, RBAC, or per-collection permission scoping; docs cover embedding, querying, CLI, MCP, forking, and cloud pricing but nothing about access control mechanisms. This is a fair axis for a database product, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

2. platform-engineerIsolate many tenants cheaply using namespaces, partitions, or per-tenant collections with documented limits

   weight 3 · round to Qdrant
   Qdrant✓fullclaimed7/10

   Qdrant's official multi-tenancy guide explicitly documents three isolation strategies (payload-based partitioning within a single collection, per-tenant collections, per-tenant clusters) with tradeoff guidance for cheaply isolating many small tenants, backed by payload filtering and granular per-collection API keys for access control. Missing for 10: concrete quantified limits (max tenants per collection/cluster, resource overhead numbers) and independent/hands-on benchmarks specifically validating tenant-isolation scale claims.

   • [claimed-docs] “keep all tenants in a single collection and use one of these three approaches to isolate them”
   • [claimed-docs] “Partition by payload filters points by a payload field that identifies the tenant. This is efficient for a large number of small, similarly-…”
   • [claimed-docs] “keep all tenants in a single collection and use one of these three approaches to isolate them: Partition by payload”
   • [claimed-docs] “Qdrant allows you to combine conditions in clauses. Clauses are different logical operations, such as OR, AND, and NOT.”
   • [claimed-docs] “Qdrant supports three types of API key: **Admin API Key**... **Read-Only API Key**... **Granular Access API Keys**”
   • [claimed-docs] “Qdrant supports API key authentication (including read-only API keys for query-only consumers and granular access API keys with per-collecti…”

   proof ↗⚑ flag

   Chroma~partialcommunity5/10

   Chroma docs and community evidence show collections as the tenant-isolation unit, with cheap copy-on-write forking and Cloud features like sharding via collections and 'scale to zero' multi-tenant support, which supports low-cost per-tenant isolation. However there is no documented guidance on per-tenant limits (max collections, size caps, quotas) or explicit multi-tenancy best-practice docs. Missing for 10: explicit multi-tenancy architecture guide, documented collection/tenant count limits, and quota/throttling details.

   • [community] “Chroma Cloud: Better indexes (SPANN/SPFresh), sharding via collections, distributed scaling, and object storage on S3 with cold/warm tiers f…”
   • [claimed-docs] “Forks are copy-on-write. You only pay for incremental storage written after the fork; unchanged data remains shared.”
   • [claimed-docs] “Forking a collection costs $0.03 per fork request. Forks are copy-on-write. You only pay for incremental storage written after the fork; unc…”
   • [claimed-docs] “We offer a BYOC (bring your own cloud) option for single-tenant deployments.”
   • [claimed-docs] “BYOC in your VPC, multi-cloud/multi-region replication, point-in-time-recovery ensure a resilient and scalable search system with the same 0…”

   proof ↗⚑ flag

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

   weight 2 · round to Qdrant
   Qdrant~partialprobed6/10

   Qdrant's architecture is fundamentally API-first (REST/gRPC API with clients in Python, JS, Go, Rust, etc.) and the Web UI is described by users as a secondary, weaker component ('UI could be better'), implying the UI is a thin layer over the same API rather than exposing exclusive functionality. However, there is no explicit documentation asserting full UI/API parity, and no OpenAPI spec was found publicly (probe returned 404s), making it hard to verify completeness. Missing for 10: explicit parity statement/documentation, a discoverable OpenAPI/swagger spec confirming full API surface, and any independent audit of UI-only features.

   • [github] “It provides a production-ready service with a convenient API to store, search, and manage points—vectors with an additional payload.”
   • [github] “Go client ... Rust client ... JavaScript/TypeScript client ... Python client ... .NET/C# client ... Java client”
   • [community] “I've been using Qdrant. Can't speak highly enough of the core functionality. It's fast, good accuracy, easy to use. Wish finding/updating po…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://qdrant.tech/openapi.json, https://qdrant.tech/swagger.json, https://qdrant.tech/api/openapi.…”

   proof ↗⚑ flag

   Chroma~partialprobed5/10

   Chroma exposes a full OpenAPI spec (chroma-probe-2) and its CLI/SDKs cover core operations (create, query, filter, full-text search, forking) described throughout the docs, suggesting the API is the primary surface. However, the evidence never explicitly confirms that Chroma Cloud's UI/dashboard offers no capabilities beyond the API, nor does it document specific UI-only features that would need parity. missing for 10: explicit parity statement comparing Cloud dashboard UI features to API/SDK capabilities, independent confirmation that all Cloud UI actions (e.g., billing, monitoring, forking via UI) are also API-accessible.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.trychroma.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Install the Chroma CLI to run a local server, browse collections, and interact with Chroma Cloud.”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Forking a collection costs $0.03 per fork request. Forks are copy-on-write. You only pay for incremental storage written after the fork; unc…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Qdrant~partialcommunity5/10

   Qdrant is Apache-2.0 open-source and self-hostable, with local on-disk storage you fully control and a snapshot mechanism to export a collection's full data/config as a tar archive for backup or migration (qdrant-docs-6/21), plus client libraries to scroll/retrieve all points programmatically (qdrant-gh-1/3). However, snapshots are a Qdrant-proprietary archive format rather than a standard open interchange format (CSV/JSON/Parquet), and there is no documented dedicated 'export to open format' feature or tooling for full data extraction into vendor-neutral formats. Missing for 10: explicit documented export-to-standard-format capability (e.g., JSON/Parquet dump), and independent confirmation that full data+vectors can be cleanly extracted and reloaded elsewhere.

   • [claimed-docs] “Snapshots are `tar` archive files that contain data and configuration of a specific collection on a specific node at a specific time.”
   • [claimed-docs] “Snapshots are tar archive files that contain data and configuration of a specific collection on a specific node at a specific time.”
   • [community] “I like their pricing page and business model: Apache-2.0 license, free tier with a free forever 1GB cluster for trying out, no credit card r…”
   • [github] “Qdrant offers the following client libraries to help you integrate it into your application stack”
   • [github] “Go client ... Rust client ... JavaScript/TypeScript client ... Python client ... .NET/C# client ... Java client”

   proof ↗⚑ flag

   Chroma~partialcommunity5/10

   Chroma is Apache 2.0 licensed and can be run locally or self-hosted, meaning users are not locked into a proprietary cloud and own their underlying data store (chroma-docs-9, chroma-docs-15). However, there is no explicit documentation of a dedicated 'export all data' tool/API or a defined open interchange format for bulk export, only general self-host/local-run capability. missing for 10: explicit data-export/import API or CLI command, documented open export format (e.g. JSON/parquet dump), and independent confirmation that migrating away from Chroma Cloud preserves all data losslessly.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [community] “Why does it say open source but then try to charge me money (re: Chroma Cloud vs self-hosted OSS Apache 2.0 licensed core).”

   proof ↗⚑ flag

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

   weight 2 · round to Chroma
   Qdrant✓fullcommunity8/10

   Qdrant's source is hosted publicly on GitHub and is released under the Apache-2.0 license, confirmed both by community commentary and the public repo evidence; independent hands-on report even describes building it from source in ~30 minutes. Missing for 10: no explicit first-party LICENSE file citation or CONTRIBUTING/governance docs in the pack, and no direct docs page restating the license.

   • [github] “Qdrant offers the following client libraries to help you integrate it into your application stack”
   • [github] “Go client ... Rust client ... JavaScript/TypeScript client ... Python client ... .NET/C# client ... Java client”
   • [community] “I like their pricing page and business model: Apache-2.0 license, free tier with a free forever 1GB cluster for trying out, no credit card r…”
   • [community] “After testing numerous open source vector databases, Qdrant is the best option: docs are clear, easy to build from source in Rust (~30 min),…”

   proof ↗⚑ flag

   Chroma✓fullcommunity9/10

   Chroma's core is explicitly Apache 2.0 licensed and open-source, confirmed by both docs and GitHub, with community discussion corroborating the OSS core vs paid Cloud distinction (chroma-comm-8 confirms the core is genuinely open even amid pricing confusion). missing for 10: no direct citation of the GitHub repo license file itself, only docs statements referencing Apache 2.0.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [github] “Create a DB and try it out in under 30 seconds with $5 of free credits.”
   • [community] “Why does it say open source but then try to charge me money (re: Chroma Cloud vs self-hosted OSS Apache 2.0 licensed core).”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Qdrant✓fullcommunity9/10

   Qdrant is Apache-2.0 licensed and provides clear self-hosting instructions via Docker, with support for distributed deployment, snapshots, security controls, and deployment on any infrastructure including Kubernetes; community reports confirm production self-hosting at scale and ease of building from source. missing for 10: no independent audit of self-hosted feature parity with cloud offering.

   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 \ -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \ qdrant/qdrant”
   • [claimed-docs] “Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data acr…”
   • [claimed-docs] “Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure.”
   • [claimed-docs] “Deploy Qdrant on any infrastructure. Get requirements, configuration options, and GPU setup guides.”
   • [community] “After testing numerous open source vector databases, Qdrant is the best option: docs are clear, easy to build from source in Rust (~30 min),…”
   • [community] “We've been using Qdrant for over a year with 10s of millions of items, lots of daily inserts/deletions. A couple of gotchas but generally pr…”
   • [community] “I like their pricing page and business model: Apache-2.0 license, free tier with a free forever 1GB cluster for trying out, no credit card r…”

   proof ↗⚑ flag

   Chroma✓fullprobed9/10

   Chroma's core is Apache 2.0 licensed and explicitly documented as runnable locally/self-hosted via its CLI, distinct from the managed Chroma Cloud offering, and community comments confirm the open-source self-hosted nature (even questioning the cloud pricing model relative to the free OSS core). missing for 10: no independent hands-on report of running the self-hosted server at scale/production beyond docs and CLI install references.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Install the Chroma CLI to run a local server, browse collections, and interact with Chroma Cloud.”
   • [claimed-docs] “The Chroma CLI lets you run a Chroma server locally on your machine, install sample apps, browse your collections, interact with your Chroma…”
   • [probe] “official CLI documented at https://docs.trychroma.com/docs/cli/install”
   • [community] “Why does it say open source but then try to charge me money (re: Chroma Cloud vs self-hosted OSS Apache 2.0 licensed core).”

   proof ↗⚑ flag

Benchmarks

1. platform-engineerSee published benchmarks or measured latency/recall numbers backing the database's performance claims

   weight 2 · round drawn
   Qdrant—none0/10

   No published benchmark reports, latency/recall numbers, or performance comparison data appear anywhere in the evidence; community comments only offer vague qualitative praise ('fast', 'good accuracy') without measured figures. Missing for 10: published benchmark suite/results, recall@k or QPS/latency tables, methodology docs, third-party benchmark corroboration.

   • [community] “I've been using Qdrant. Can't speak highly enough of the core functionality. It's fast, good accuracy, easy to use. Wish finding/updating po…”
   • [community] “After testing numerous open source vector databases, Qdrant is the best option: docs are clear, easy to build from source in Rust (~30 min),…”

   proof ↗⚑ flag

   Chroma—none0/10

   The evidence pack contains only feature/marketing docs, pricing, and community sentiment; no published benchmark reports, latency/recall figures, or comparative performance data for Chroma are cited anywhere. The one research reference found (chroma-comm-9) is about long-context LLM degradation, not database latency/recall benchmarks, so it does not satisfy this axis.

   ⚑ flag

Index tuning

1. ml-engineerTune index parameters (HNSW graph settings, index types) to trade recall against latency and memory

   weight 2 · round to Qdrant
   Qdrant~partialclaimed3/10

   The pack only vaguely references performance-tuning levers ('optimal vector search performance, such as quantization, sharding, tenant isolation') via an agent-skills GitHub listing, but never documents HNSW graph parameters (m, ef_construct, ef_search) or alternate index types as explicit recall/latency/memory trade-off knobs. Missing for 10: dedicated HNSW parameter tuning docs, index type comparison, benchmark data showing recall-vs-latency trade-offs, and independent confirmation of tuning outcomes.

   • [github] “Install these skills to empower your agent in making critical engineering decisions for optimal vector search performance, such as quantizat…”

   proof ↗⚑ flag

   Chroma—none0/10

   The evidence pack contains no mention of HNSW graph parameters (e.g., ef_construction, M, ef_search), alternative index types, or any recall/latency/memory tuning controls exposed to users; only high-level mentions of automatic indexing and Cloud-side index upgrades (SPANN/SPFresh) which are not user-tunable HNSW settings.

   ⚑ flag

2. ml-engineerEnable vector quantization or compression to cut memory and storage cost with a documented accuracy trade-off

   weight 2 · round to Qdrant
   Qdrant~partialclaimed3/10

   Only a single glancing mention (qdrant-gh-2) references quantization as an engineering lever for vector search performance, but the evidence pack contains no dedicated documentation on scalar/binary/product quantization configuration or the accuracy/memory trade-off curve. Missing for 10: dedicated quantization docs page, configuration examples (rescore, oversampling), benchmark/accuracy trade-off data, independent corroboration of memory savings.

   • [github] “Install these skills to empower your agent in making critical engineering decisions for optimal vector search performance, such as quantizat…”

   proof ↗⚑ flag

   Chroma—none0/10

   No documentation describes vector quantization or compression options with accuracy trade-offs; in fact community evidence explicitly states Chroma lacks vector quantization (unlike Weaviate), confirming the capability's absence rather than any dispute of a vendor claim.

   • [community] “Chroma and Weaviate are both popular OSS projects, 21k and 14k stars respectively. Weaviate has some features Chroma does not (yet) - notabl…”

   proof ↗⚑ flag

Pricing

1. developerPrototype on a meaningful free tier before paying anything

   weight 1 · round drawn
   Qdrant✓fullcommunity8/10

   Qdrant offers a free-forever 1GB cloud cluster with no credit card required, plus fully free self-hosted open-source/Docker option and no token limits, corroborated by community testimony praising the free tier and easy POC setup. Missing for 10: no independent benchmarking of free-tier limits/performance over time or detail on how quickly a prototype would need to scale beyond the free tier.

   • [community] “I like their pricing page and business model: Apache-2.0 license, free tier with a free forever 1GB cluster for trying out, no credit card r…”
   • [community] “Weaviate and Qdrant have similar offerings in features, open-sourceness, flexible deployment. Qdrant gets a lot of support from the Rust com…”
   • [community] “One of the big advantages of Qdrant is how easy it is to do a POC because it allows an 'in-memory' version similar to sqlite. Milvus by comp…”
   • [claimed-docs] “No token limits ... No payment method required”
   • [claimed-docs] “No limits ![No token limits”
   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 \ -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \ qdrant/qdrant”

   proof ↗⚑ flag

   Chroma✓fullcommunity8/10

   Chroma's core is Apache-2.0 OSS and can be run and prototyped with entirely for free locally/self-hosted, and Chroma Cloud offers $5 in free credits to try it in under 30 seconds; community feedback also praises the straightforward, reasonable pricing calculator. missing for 10: independent developer accounts specifically praising the free-tier prototyping experience over time, and clearer detail on free-tier usage limits/duration.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [github] “Create a DB and try it out in under 30 seconds with $5 of free credits.”
   • [community] “I appreciate the straightforward pricing calculator and the pricing seems very reasonable.”
   • [community] “Why does it say open source but then try to charge me money (re: Chroma Cloud vs self-hosted OSS Apache 2.0 licensed core).”

   proof ↗⚑ flag

2. developerPay serverless usage-based pricing with transparent per-unit costs instead of provisioning fixed clusters

   weight 2 · round to Chroma
   Qdrant—none0/10

   Evidence shows Qdrant offers self-hosted deployment, Kubernetes private cloud, and a free-forever fixed-size (1GB) cluster tier for its cloud offering, but no evidence of a serverless usage-based pricing model with transparent per-unit costs — the cited pricing references are all cluster/tier-based rather than consumption-based.

   • [claimed-docs] “No token limits ... No payment method required”
   • [claimed-docs] “No limits ![No token limits”
   • [community] “I like their pricing page and business model: Apache-2.0 license, free tier with a free forever 1GB cluster for trying out, no credit card r…”
   • [claimed-docs] “Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure.”
   • [claimed-docs] “Deploy Qdrant on any infrastructure. Get requirements, configuration options, and GPU setup guides.”

   proof ↗⚑ flag

   Chroma✓fullcommunity7/10

   Chroma Cloud is explicitly described as a managed, serverless offering with usage-based unit pricing (e.g., $0.03 per fork, pay only for incremental storage), contrasting with fixed-cluster provisioning, and community users corroborate a straightforward, reasonable pricing calculator and cost savings. Missing for 10: a full breakdown of all per-unit costs (compute/query pricing beyond forking/storage) and independent hands-on cost verification beyond anecdotal praise.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “Forks are copy-on-write. You only pay for incremental storage written after the fork; unchanged data remains shared.”
   • [claimed-docs] “Forking a collection costs $0.03 per fork request. Forks are copy-on-write. You only pay for incremental storage written after the fork; unc…”
   • [community] “I appreciate the straightforward pricing calculator and the pricing seems very reasonable.”
   • [community] “Happy paying user of Chroma Cloud here. Congratulations Jeff, Hammad and team! We were lucky to get early access and have saved a bundle.”
   • [community] “Chroma Cloud: Better indexes (SPANN/SPFresh), sharding via collections, distributed scaling, and object storage on S3 with cold/warm tiers f…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Qdrant~partialclaimed6/10

   Qdrant can be self-hosted on any infrastructure (Docker, Kubernetes 'Private Cloud' on any cloud) which lets users control exactly where data physically resides, satisfying residency needs for self-managed deployments. However, there is no evidence describing an explicit region-selection feature for Qdrant Cloud (the managed offering), so hosted-tier residency control is unproven. Missing for 10: documented region/zone picker for Qdrant Cloud, compliance certifications tied to specific regions, and independent confirmation of residency guarantees.

   • [claimed-docs] “Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure.”
   • [claimed-docs] “Deploy Qdrant on any infrastructure. Get requirements, configuration options, and GPU setup guides.”
   • [claimed-docs] “Qdrant supports a distributed deployment mode. In this mode, multiple Qdrant services communicate with each other to distribute the data acr…”

   proof ↗⚑ flag

   Chroma~partialclaimed6/10

   Chroma supports self-hosting and a BYOC (bring-your-own-cloud) option with multi-cloud/multi-region replication, which lets customers control where data physically resides, but there is no documented region-selection feature for the standard managed Chroma Cloud offering. Missing for 10: explicit region/residency picker in Chroma Cloud UI, documentation on specific supported regions, and independent confirmation of residency compliance for managed tenants.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “We offer a BYOC (bring your own cloud) option for single-tenant deployments.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “BYOC in your VPC, multi-cloud/multi-region replication, point-in-time-recovery ensure a resilient and scalable search system with the same 0…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Qdrant—none0/10

   The evidence pack covers self-hosting, security/API keys, deployment, and embeddings, but contains no statement about Qdrant's (or Qdrant Cloud's) policy on using customer data to train AI/embedding models, nor an opt-out mechanism. Self-hosting implies data control, but that is not explicit evidence of a training-data policy. missing for 10: explicit vendor privacy policy or ToS statement on not using customer data for model training, evidence of an opt-out setting, or independent confirmation of this practice.

   ⚑ flag

   Chroma—none0/10

   Chroma is a vector database; the evidence pack contains no statement about data-training opt-out policies, data usage terms, or privacy commitments regarding whether user data is used to train AI models. This is a fair question since Chroma Cloud is a hosted service that could plausibly have such a policy, but no evidence addresses it.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Qdrant
   Qdrant~partialclaimed5/10

   Qdrant's self-hosted deployment model (Docker volumes, on-prem/K8s options) implies users fully own and can delete their storage, and snapshot/backup features give some control over data lifecycle, but the evidence pack has no explicit documentation of a delete-collection/delete-point API, TTL/retention policies, or data-expiry controls tailored to privacy compliance. missing for 10: explicit deletion/point-removal API docs, retention/TTL policy documentation, GDPR-style data-erasure guidance.

   • [claimed-docs] “docker run -p 6333:6333 -p 6334:6334 \ -v "$(pwd)/qdrant_storage:/qdrant/storage:z" \ qdrant/qdrant”
   • [claimed-docs] “Snapshots are `tar` archive files that contain data and configuration of a specific collection on a specific node at a specific time.”
   • [claimed-docs] “Qdrant Private Cloud allows you to manage Qdrant database clusters in any Kubernetes cluster on any infrastructure.”
   • [claimed-docs] “Deploy Qdrant on any infrastructure. Get requirements, configuration options, and GPU setup guides.”

   proof ↗⚑ flag

   Chroma~partialclaimed4/10

   Chroma's self-host/BYOC/Apache-2.0 options (chroma-docs-9, chroma-docs-11, chroma-docs-15, chroma-docs-28) let an AI-native user run their own infrastructure and thus control where data lives, giving implicit control over retention, but the evidence pack contains no explicit documentation of a delete API, TTL/retention policy, or data-deletion workflow for collections or Chroma Cloud. missing for 10: explicit delete/purge API docs, data retention policy statement, and any independent confirmation that deletion requests are honored in Chroma Cloud.

   • [claimed-docs] “Chroma is licensed under Apache 2.0. Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “We offer a BYOC (bring your own cloud) option for single-tenant deployments.”
   • [claimed-docs] “Run it locally, self-host, or use Chroma Cloud for a managed, serverless experience.”
   • [claimed-docs] “BYOC in your VPC, multi-cloud/multi-region replication, point-in-time-recovery ensure a resilient and scalable search system with the same 0…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Qdrant—none0/10

   No evidence pack item mentions telemetry, usage tracking, analytics collection, or an opt-out setting/flag for Qdrant; Qdrant is self-hosted open-source software, which makes this a fair question, but nothing in the docs, GitHub, or community evidence addresses it.

   ⚑ flag

   Chroma—none0/10

   No evidence in the pack mentions telemetry, usage tracking, or an opt-out mechanism for Chroma; the docs cover storage, search, CLI, MCP, and pricing but never address privacy/telemetry settings. missing for 10: any documentation of telemetry collection, an opt-out flag/env var (e.g., ANONYMIZED_TELEMETRY), or privacy policy statement.

   ⚑ flag

Integrations

1. ml-engineerPlug the database into RAG and agent frameworks (LangChain, LlamaIndex, etc.) through maintained first-class integrations

   weight 2 · round to Chroma
   Qdrant—none0/10

   The evidence pack documents Qdrant's own client libraries (Python, JS, Go, Rust, Java, .NET) and an MCP server/agent-skills for coding assistants, but contains no mention of maintained first-class integrations with RAG/agent frameworks like LangChain or LlamaIndex. Since this axis clearly applies to a vector database aimed at ML engineers building RAG pipelines, absence of such evidence yields 'none' rather than 'na'.

   • [github] “Qdrant offers the following client libraries to help you integrate it into your application stack”
   • [github] “Go client ... Rust client ... JavaScript/TypeScript client ... Python client ... .NET/C# client ... Java client”
   • [github] “Qdrant provides a collection of ready-to-use agent skills that bring Qdrant's vector search capabilities directly into your AI coding assist…”
   • [probe] “official MCP server documented at https://qdrant.tech/documentation/qdrant-mcp-server/”

   proof ↗⚑ flag

   Chroma~partialprobed6/10

   Chroma documents a first-class LangChain integration page (with a link to a LangChain blog post) and an official Anthropic MCP server, showing maintained framework integrations exist, but the evidence pack lacks explicit mention of LlamaIndex or other agent frameworks, and no independent hands-on corroboration of integration quality is given. missing for 10: explicit LlamaIndex integration docs, broader multi-framework coverage (e.g., Haystack, Semantic Kernel), independent developer confirmation of integration reliability.

   • [claimed-docs] “question answering over documents”
   • [claimed-docs] “LangChain + Chroma on the LangChain blog”
   • [claimed-docs] “The Chroma MCP server allows Claude to directly interact with Chroma’s search capabilities through this standardized protocol.”
   • [claimed-docs] “The Chroma MCP server allows Claude to directly interact with Chroma's search capabilities through this standardized protocol. This enables …”
   • [probe] “official MCP server documented at https://docs.trychroma.com/integrations/frameworks/anthropic-mcp”

   proof ↗⚑ flag

Sdks

1. developerBuild against official SDKs in the major languages (Python, TypeScript, Go, Java)

   weight 2 · round to Qdrant
   Qdrant✓fullcommunity8/10

   GitHub evidence explicitly lists official client libraries including Python, JavaScript/TypeScript, Go, and Java clients, and docs show a working Python client quickstart example, confirming official SDK support in these major languages. Missing for 10: no direct code samples/docs snippets shown for TypeScript, Go, or Java specifically (only Python is demonstrated in detail), and no independent hands-on corroboration of the non-Python SDKs' quality.

   • [github] “Qdrant offers the following client libraries to help you integrate it into your application stack”
   • [github] “Go client ... Rust client ... JavaScript/TypeScript client ... Python client ... .NET/C# client ... Java client”
   • [claimed-docs] “client.create_collection( collection_name="test_collection", vectors_config=VectorParams(size=4, distance=Distance.DOT), )”
   • [community] “Just played with qdrant using its Python client. Pretty smooth onboarding experience, though having to generate embeddings client-side rathe…”

   proof ↗⚑ flag

   Chroma~partialclaimed3/10

   Evidence only confirms a Python SDK/workflow (chroma-docs-20, chroma-docs-21) with no mention of official TypeScript, Go, or Java SDKs anywhere in the pack. Missing for 10: explicit documentation of TypeScript, Go, and Java official client libraries, and any independent corroboration of their feature parity.

   • [claimed-docs] “In this directory create a new Python project with Chroma set up. Use a virtual environment.”
   • [claimed-docs] “Chroma will store your text and handle embedding and indexing automatically. You can also customize the embedding model.”
   • [claimed-docs] “Chroma will store your text and handle embedding and indexing automatically.”

   proof ↗⚑ flag

Core search

1. developerRun approximate nearest-neighbor similarity search over embeddings with configurable distance metrics

   weight 3 · round to Qdrant
   Qdrant✓fullcommunity9/10

   Qdrant is a core ANN vector search engine; docs show creating collections with configurable distance metrics (e.g. Distance.DOT) and hybrid/filtered query support, corroborated by community reports of fast, accurate search at production scale. Missing for 10: explicit enumeration/benchmarking of all supported distance metrics (cosine, euclidean, dot) in one place and independent ANN recall benchmarks.

   • [claimed-docs] “client.create_collection( collection_name="test_collection", vectors_config=VectorParams(size=4, distance=Distance.DOT), )”
   • [claimed-docs] “Qdrant has a few ways of fusing the results from different queries: `rrf` and `dbsf`”
   • [claimed-docs] “in text search, it is often useful to combine dense and sparse vectors to get the best of both worlds: semantic understanding from dense vec…”
   • [community] “I've been using Qdrant. Can't speak highly enough of the core functionality. It's fast, good accuracy, easy to use. Wish finding/updating po…”
   • [community] “We've been using Qdrant for over a year with 10s of millions of items, lots of daily inserts/deletions. A couple of gotchas but generally pr…”

   proof ↗⚑ flag

   Chroma~partialclaimed5/10

   Docs confirm core ANN similarity search — Chroma auto-embeds and returns the 'n most similar results' for a query, and supports pluggable embedding models — establishing the basic ANN capability. However, the evidence pack never documents configurable distance metrics (e.g., cosine/L2/IP) or how to select them, so that specific part of the story is unsupported. missing for 10: explicit documentation of configurable distance-metric options, independent benchmarking of ANN recall/latency.

   • [claimed-docs] “Chroma will store your text and handle embedding and indexing automatically.”
   • [claimed-docs] “You can query the collection with a list of query texts, and Chroma will return the n most similar results.”
   • [claimed-docs] “Use any embedding model. OpenAI, Cohere, Hugging Face, sentence-transformers, and more.”
   • [claimed-docs] “Chroma will store your text and handle embedding and indexing automatically. You can also customize the embedding model.”

   proof ↗⚑ flag

Hybrid

1. developerRun keyword/full-text search over documents inside the database without bolting on a separate search engine

   weight 2 · round drawn
   Qdrant~partialclaimed6/10

   Qdrant documents sparse-vector search and hybrid dense+sparse queries (fused via rrf/dbsf) explicitly for 'precise word matching' alongside semantic search, letting a developer get keyword-style search without a separate engine like Elasticsearch. However, the evidence never describes a dedicated full-text/BM25 index or classic text-search features (stemming, tokenizer configuration, phrase queries), and there is no independent hands-on validation of keyword-search quality specifically (community comments focus on vector search performance, not text search). Missing for 10: explicit full-text/BM25 index documentation, tokenizer/analyzer configuration details, and independent verification of keyword-search relevance.

   • [claimed-docs] “Qdrant has a few ways of fusing the results from different queries: `rrf` and `dbsf`”
   • [claimed-docs] “in text search, it is often useful to combine dense and sparse vectors to get the best of both worlds: semantic understanding from dense vec…”
   • [claimed-docs] “Configure dense, sparse, and multi-vector embeddings. Use cloud-hosted embedding models directly with Qdrant.”

   proof ↗⚑ flag

   Chroma~partialcommunity6/10

   Chroma documents built-in full-text search via $contains/$not_contains and regex matching combinable with metadata filtering, and mentions sparse/lexical BM25/SPLADE search on its marketing site, with community corroboration citing regex+trigram search for code-search use cases. However, this is substring/regex matching rather than true relevance-ranked keyword search (BM25/lexical) in the queryable API — the BM25/SPLADE claim appears only as a roadmap/marketing bullet without documented API details or independent verification of ranking quality. missing for 10: documented API/tutorial for BM25 lexical scoring and ranking, independent hands-on validation of full-text search quality vs dedicated search engines.

   • [claimed-docs] “We support full-text search with the $contains and $not_contains operators. We also support regular expression pattern matching with the $re…”
   • [claimed-docs] “.get and .query can handle where_document search combined with metadata filtering”
   • [claimed-docs] “We support full-text search with the `$contains` and `$not_contains` operators. We also support regular expression pattern matching with the…”
   • [claimed-docs] “Sparse vector search - Lexical search (BM25, SPLADE)”
   • [community] “Chroma has built in regex+trigram search and copy-on-write forking of indexes. this feature combo is killer for the code-search use case.”

   proof ↗⚑ flag

2. developerCombine dense vector search with keyword or sparse (BM25-style) signals in one hybrid query with fusion ranking

   weight 3 · round to Qdrant
   Qdrant✓fullclaimed8/10

   Qdrant docs explicitly describe hybrid queries combining dense and sparse vectors with fusion ranking methods (rrf and dbsf), directly matching the story. Missing for 10: independent hands-on verification of fusion ranking quality/behavior and no code example showing a full hybrid query request in the pack.

   • [claimed-docs] “Qdrant has a few ways of fusing the results from different queries: `rrf` and `dbsf`”
   • [claimed-docs] “in text search, it is often useful to combine dense and sparse vectors to get the best of both worlds: semantic understanding from dense vec…”

   proof ↗⚑ flag

   Chroma~partialclaimed4/10

   Chroma's docs advertise full-text/regex filtering ("$contains", "$regex") that can be combined with metadata filters, and separately list "Sparse vector search - Lexical search (BM25, SPLADE)" as a roadmap/feature item on the homepage, but no documentation describes a single query API that fuses dense and BM25/sparse scores into one ranked result set. missing for 10: explicit fusion-ranking API/query syntax combining dense+sparse scores, hands-on or benchmark evidence that hybrid fusion actually works, and clarity on whether BM25/SPLADE support is shipped vs. planned.

   • [claimed-docs] “We support full-text search with the $contains and $not_contains operators. We also support regular expression pattern matching with the $re…”
   • [claimed-docs] “.get and .query can handle where_document search combined with metadata filtering”
   • [claimed-docs] “Sparse vector search Lexical search (BM25, SPLADE)”
   • [claimed-docs] “Sparse vector search - Lexical search (BM25, SPLADE)”

   proof ↗⚑ flag

Reranking

1. ml-engineerRerank search results with built-in or first-party-integrated reranking models

   weight 2 · round drawn
   Qdrant—none0/10

   The evidence pack covers hybrid dense/sparse fusion (RRF, DBSF) but contains no mention of reranking models (cross-encoder, built-in reranker, or first-party integration for reranking search results). Missing for 10: any documentation of a built-in reranker, first-party reranking model integration, or reranker API/parameter in Qdrant's query interface.

   • [claimed-docs] “Qdrant has a few ways of fusing the results from different queries: `rrf` and `dbsf`”
   • [claimed-docs] “in text search, it is often useful to combine dense and sparse vectors to get the best of both worlds: semantic understanding from dense vec…”

   proof ↗⚑ flag

   Chroma—none0/10

   The evidence pack covers embeddings, full-text/regex search, sparse lexical search (BM25/SPLADE), forking, and MCP/CLI integrations, but nowhere mentions a built-in or first-party-integrated reranking model (e.g., cross-encoder or Cohere rerank) applied to search results.

   • [claimed-docs] “Sparse vector search Lexical search (BM25, SPLADE)”
   • [claimed-docs] “Sparse vector search - Lexical search (BM25, SPLADE)”
   • [claimed-docs] “We support full-text search with the $contains and $not_contains operators. We also support regular expression pattern matching with the $re…”
   • [claimed-docs] “We support full-text search with the `$contains` and `$not_contains` operators. We also support regular expression pattern matching with the…”

   proof ↗⚑ flag