Weaviate vs Qdrant

Agent access

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

   weight 2 · round to Weaviate
   Weaviate✓fullprobed9/10

   A probe confirms Weaviate hosts a working llms.txt at docs.weaviate.io/llms.txt returning HTTP 200 with structured summary content, and Weaviate also documents an official MCP server for agent/IDE integration, directly supporting agent-oriented docs consumption. Missing for 10: independent third-party confirmation that agents actually consume and act on this llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.weaviate.io/llms.txt # Weaviate ## TL;DR Weaviate is an open-source vector database (Go) that sto…”
   • [probe] “official MCP server documented at https://github.com/weaviate/mcp-server-weaviate”
   • [claimed-docs] “Enable and configure the Weaviate MCP server so LLMs and IDE assistants can interact with your Weaviate instance.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Weaviate~partialclaimed6/10

   Weaviate ships as a headless server deployable via Docker/Kubernetes with official client libraries (Python, JS, Go, Java) for programmatic access, which supports scripted/CI automation (weaviate-gh-2, weaviate-gh-3, weaviate-docs-21). However, there is no explicit documentation or example of running Weaviate specifically within a CI pipeline or automated test/deploy workflow. Missing for 10: explicit CI/CD integration guides, non-interactive automation examples, and independent confirmation of headless CI usage.

   • [github] “You can easily start Weaviate and a local vector embedding model with Docker.”
   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”
   • [claimed-docs] “Follow the instructions below to install one of the official client libraries, available in Python, JavaScript/TypeScript, Go, and Java.”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Weaviate✓fullprobed8/10

   Weaviate documents an official MCP server that lets LLMs/IDE assistants interact with a Weaviate instance, with both docs and a dedicated GitHub repo confirming it. Missing for 10: independent hands-on validation/community corroboration of the MCP server's reliability and depth of tool coverage.

   • [claimed-docs] “Enable and configure the Weaviate MCP server so LLMs and IDE assistants can interact with your Weaviate instance.”
   • [probe] “official MCP server documented at https://github.com/weaviate/mcp-server-weaviate”

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Weaviate—none0/10

   Evidence lists official client libraries (Python, JS/TS, Go, Java) and an MCP server, but no mention anywhere of an official CLI tool for interacting with or managing Weaviate.

   • [claimed-docs] “Follow the instructions below to install one of the official client libraries, available in Python, JavaScript/TypeScript, Go, and Java.”
   • [probe] “official MCP server documented at https://github.com/weaviate/mcp-server-weaviate”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Weaviate✓fullprobed8/10

   Weaviate exposes official documented client libraries (Python, JS/TS, Go, Java) and REST/GraphQL APIs for driving all core operations (collections, hybrid search, RAG, multi-tenancy), plus a documented official MCP server enabling LLMs/IDE assistants to interact with instances, confirming programmatic, agent-friendly access. missing for 10: independent hands-on validation of API completeness/stability and no direct evidence of OpenAPI/REST spec docs beyond client libraries.

   • [claimed-docs] “Follow the instructions below to install one of the official client libraries, available in Python, JavaScript/TypeScript, Go, and Java.”
   • [claimed-docs] “Enable and configure the Weaviate MCP server so LLMs and IDE assistants can interact with your Weaviate instance.”
   • [probe] “official MCP server documented at https://github.com/weaviate/mcp-server-weaviate”
   • [github] “Weaviate supports two approaches to store vectors: automatic vectorization at import using integrated models ... or direct import of pre-com…”
   • [claimed-docs] “Import objects directly into Weaviate without having to manually specify embeddings”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Qdrant
   Weaviate—none0/10

   No evidence of scoped/least-privilege API key or credential issuance for agents; docs cover multi-tenancy, RBAC-adjacent isolation, and MCP server setup but nothing about generating restricted-scope API credentials specifically for agent use. Missing for 10: any mention of API key scoping, role-based permission grants, or credential minting workflow for agents.

   • [claimed-docs] “Enable and configure the Weaviate MCP server so LLMs and IDE assistants can interact with your Weaviate instance.”
   • [probe] “official MCP server documented at https://github.com/weaviate/mcp-server-weaviate”
   • [claimed-docs] “Multi-tenancy provides data isolation. Each tenant is stored on a separate shard. Data stored in one tenant is not visible to another tenant…”

   proof ↗⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Weaviate✓fullcommunity8/10

   Weaviate documents official client libraries in Python, JavaScript/TypeScript, Go, and Java, which are the primary SDKs for building AI-native applications against the database. Missing for 10: independent hands-on corroboration of SDK quality/completeness and explicit coverage of async support issues raised by a community user.

   • [claimed-docs] “Follow the instructions below to install one of the official client libraries, available in Python, JavaScript/TypeScript, Go, and Java.”
   • [community] “Just migrated from Supabase + pgvector to Weaviate hoping to take advantage of langchain.retrievers.weaviate_hybrid_search.WeaviateHybridSea…”

   proof ↗⚑ flag

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Weaviate—none0/10

   No evidence in the pack mentions webhooks or event subscription mechanisms; Weaviate's documented features cover search, RAG, multi-tenancy, replication, backups, and MCP integration but nothing about webhook-based event subscriptions.

   ⚑ flag

   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

Agentic features

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

   weight 2 · round to Weaviate
   Weaviate~partialclaimed6/10

   Weaviate's docs show generative/RAG features that produce natural-language answers from data (docs-6/23), a dedicated agentic 'Query Agent' for agentic search over collections (docs-27), and RAG-oriented backend claims (docs-3, gh-4) plus agent integrations leveraging semantic insights (docs-4) — this directly matches 'AI-generated insights from data'. However the natural-language Q&A feature is explicitly marked 'Cloud only' (docs-23), and there is no independent/hands-on evidence validating quality or reliability of these generated insights, only vendor docs. Missing for 10: independent corroboration of generated-insight quality, self-hosted parity for the Q&A/insights feature, and concrete examples of Query Agent output.

   • [claimed-docs] “Weaviate can serve as a robust backend for RAG workflows, where vector search is used to retrieve context that enhances the output of genera…”
   • [claimed-docs] “These agents can leverage semantic insights to make decisions or trigger actions based on the data stored in Weaviate.”
   • [claimed-docs] “Get answers from your data by using a natural language prompt/question.”
   • [claimed-docs] “Get answers from your data by using a natural language prompt/question. Cloud only”
   • [claimed-docs] “Query Agent: Run agentic search over your Weaviate Cloud collections”
   • [github] “It combines vector similarity search with keyword filtering, retrieval-augmented generation (RAG), and reranking in a single query interface…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Weaviate
   Weaviate~partialclaimed5/10

   Weaviate Cloud ships a 'Query Agent' described as agentic search that can be delegated over your collections, and docs mention agents leveraging semantic insights to trigger actions, which is a form of built-in AI delegation. However this is narrow (search-only, Cloud-only) rather than a general-purpose in-product assistant, and there's no independent/hands-on corroboration of its use. Missing for 10: broader task delegation beyond search, self-hosted availability, and third-party validation of the Query Agent's real-world behavior.

   • [claimed-docs] “Query Agent: Run agentic search over your Weaviate Cloud collections”
   • [claimed-docs] “These agents can leverage semantic insights to make decisions or trigger actions based on the data stored in Weaviate.”
   • [claimed-docs] “Get answers from your data by using a natural language prompt/question. Cloud only”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Weaviate
   Weaviate✓fullprobed7/10

   Weaviate documents both natural-language query answering ("Get answers from your data by using a natural language prompt/question") and an official MCP server enabling LLMs/IDE assistants to interact with a Weaviate instance, plus a 'Query Agent' for agentic search over collections — together these let an AI-native user operate the DB via natural-language commands rather than only structured queries. Missing for 10: independent/hands-on verification that NL commands reliably drive full CRUD/admin operations (not just search), and no community corroboration of MCP/Query Agent quality in practice.

   • [claimed-docs] “Get answers from your data by using a natural language prompt/question.”
   • [claimed-docs] “Get answers from your data by using a natural language prompt/question. Cloud only”
   • [claimed-docs] “Enable and configure the Weaviate MCP server so LLMs and IDE assistants can interact with your Weaviate instance.”
   • [claimed-docs] “Query Agent: Run agentic search over your Weaviate Cloud collections”
   • [probe] “official MCP server documented at https://github.com/weaviate/mcp-server-weaviate”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round drawn
   Weaviate—none0/10

   The evidence pack covers client libraries, quickstart guides, and an MCP server, but there is no mention of an interactive API reference (e.g., Swagger/OpenAPI console) with runnable, in-browser examples. missing for 10: interactive API explorer/playground, runnable code snippets embedded in docs, evidence of live query execution from documentation.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Weaviate—none0/10

   The evidence pack contains no mention of an OpenAPI spec, Swagger docs, or any machine-readable API specification being available for download; it only covers client libraries, MCP server, and quickstart guides. Since Weaviate exposes a REST/GraphQL API, this axis clearly applies to the product category, but no evidence confirms a downloadable spec.

   ⚑ flag

   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

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

   weight 1 · round to Qdrant
   Weaviate~partialclaimed4/10

   Weaviate supports self-hosted local deployments (Docker, Kubernetes) and a free cloud cluster tier, which a user could stand up as an isolated dev/test environment separate from production, and multi-tenancy provides data isolation between tenants. However, there is no explicit documented 'sandbox' feature or guidance for testing against a non-production environment without affecting live data. missing for 10: dedicated sandbox/staging environment documentation, guidance on test-vs-prod separation workflows, independent confirmation that local/free-tier usage is treated as a true sandbox.

   • [github] “You can easily start Weaviate and a local vector embedding model with Docker.”
   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”
   • [claimed-docs] “Always free — 1 cluster per user, upgrade to paid anytime.”
   • [claimed-docs] “Multi-tenancy provides data isolation. Each tenant is stored on a separate shard. Data stored in one tenant is not visible to another tenant…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Weaviate—none0/10

   No evidence pack item mentions API versioning scheme or a documented deprecation policy for Weaviate's APIs; all evidence covers search, RAG, multi-tenancy, backups, and MCP integration instead. Missing for 10: any mention of API version numbers, changelog/deprecation notices, or a stability/support policy document.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Weaviate~partialclaimed3/10

   Evidence only shows generic references to 'importing data' and 'creating collections' (e.g., weaviate-docs-5, weaviate-docs-12, weaviate-gh-1) without any explicit mention of a batch/bulk API for importing, updating, or deleting many objects at once. Bulk operations are a standard vector-DB capability, so the axis applies, but the pack lacks concrete documentation of batch size limits, bulk delete, or batch import endpoints. missing for 10: explicit batch import/delete API docs, performance/throughput claims for bulk operations, independent confirmation of bulk operation reliability.

   • [claimed-docs] “Set up a collection - Create a collection and import data into it.”
   • [claimed-docs] “Import objects directly into Weaviate without having to manually specify embeddings”
   • [github] “Weaviate supports two approaches to store vectors: automatic vectorization at import using integrated models ... or direct import of pre-com…”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Weaviate—none0/10

   Weaviate is a vector database with search, RAG, multi-tenancy, backup and agent-integration features, but there is no evidence of an event-driven rules/triggers system that automatically fires actions based on defined conditions or data events. The closest mentions (agentic search, Query Agent, MCP server) describe query/retrieval capabilities, not rule-based automation triggers.

   ⚑ flag

   Qdrant—none0/10

   No evidence in the pack shows Qdrant supporting rule-based automation or event-triggered actions (e.g., webhooks, alerts, triggers on data changes); documentation covers hybrid search, filtering, sharding, snapshots, and security only.

   ⚑ flag

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

   weight 1 · round drawn
   Weaviate—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

   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

Backup

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

   weight 2 · round drawn
   Weaviate✓fullclaimed8/10

   Docs explicitly cover backup/restore functionality including cloud blob storage integration (S3/GCS/Azure), cross-provider restore, incremental backups, and choice of backing up entire instance or selected collections. missing for 10: independent/hands-on corroboration of restore success, detail on snapshot scheduling/automation, and recovery time/consistency guarantees.

   • [claimed-docs] “Seamless integration with widely-used cloud blob storage, such as AWS S3, GCS, or Azure Storage”
   • [claimed-docs] “Backup and Restore between different storage providers”
   • [claimed-docs] “Incremental backups that only store changed data, reducing backup and speeding up backup times”
   • [claimed-docs] “Choice of backing up an entire instance, or selected collections only”

   proof ↗⚑ flag

   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

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
   Weaviate~partialclaimed3/10

   Docs confirm CRUD-style data import and replication factor settings (weaviate-docs-9/17) but there is no explicit documentation of freshness/consistency guarantees after upsert/delete, nor any consistency-level or read-after-write behavior described in the evidence pack. missing for 10: documented consistency levels/tunable consistency, read-after-write freshness guarantees, benchmarks or docs on indexing latency for updates/deletes.

   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1. This enables a variety of benefits such as…”
   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1.”
   • [claimed-docs] “Set up a collection - Create a collection and import data into it.”

   proof ↗⚑ flag

   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

Portability

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

   weight 2 · round to Weaviate
   Weaviate~partialclaimed6/10

   Bulk import of objects with either auto-vectorization or pre-computed vector embeddings is well documented (weaviate-docs-12, -15, -24, -28, weaviate-gh-1), and client libraries support this at scale. Export-side evidence is limited to backup/restore to cloud blob storage (S3/GCS/Azure) with incremental and selective backups (weaviate-docs-10, -11, -18, -19), which covers whole-instance/collection portability but is not explicitly documented as a per-object bulk vector+metadata export format (e.g., CSV/JSON dump) for developer-level data lifecycle use. Missing for 10: explicit documented bulk-export API/format for vectors+metadata (vs. binary backup snapshots), and independent/hands-on confirmation of round-trip import/export fidelity.

   • [claimed-docs] “Import objects directly into Weaviate without having to manually specify embeddings”
   • [claimed-docs] “Import objects and vectorize them with the Weaviate Embeddings service. ](/weaviate/quickstart?import=vectorization#create-a-collection)[ …”
   • [claimed-docs] “Import objects and vectorize them with the Weaviate Embeddings service. Import pre-computed vector embeddings along with your data.”
   • [claimed-docs] “Import vectors: Import pre-computed vector embeddings along with your data.”
   • [github] “Weaviate supports two approaches to store vectors: automatic vectorization at import using integrated models ... or direct import of pre-com…”
   • [claimed-docs] “Seamless integration with widely-used cloud blob storage, such as AWS S3, GCS, or Azure Storage”
   • [claimed-docs] “Backup and Restore between different storage providers”
   • [claimed-docs] “Incremental backups that only store changed data, reducing backup and speeding up backup times”
   • [claimed-docs] “Choice of backing up an entire instance, or selected collections only”

   proof ↗⚑ flag

   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

Local dev

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

   weight 2 · round to Qdrant
   Weaviate~partialcommunity5/10

   Weaviate is well documented for lightweight local deployment via Docker (weaviate-gh-2, weaviate-gh-3), and a community report confirms an embedded Python package mode exists as an alternative to running a separate process (weaviate-comm-1), but the evidence pack contains no first-party documentation describing or supporting embedded in-process operation as an official deployment mode. Missing for 10: first-party docs on embedded mode, language coverage beyond Python, and guidance on limitations of embedded/local instances for production-like dev workloads.

   • [github] “You can easily start Weaviate and a local vector embedding model with Docker.”
   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”
   • [community] “Weaviate is pretty cool IMO. It is open source and fairly easy to get running locally... You can even run Weaviate as an embedded python pac…”

   proof ↗⚑ flag

   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

Managed cloud

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

   weight 2 · round to Weaviate
   Weaviate~partialclaimed5/10

   Evidence confirms a fully managed offering (Weaviate Cloud) with a free tier and upgrade path, and lists Weaviate Cloud as one of the deployment options alongside Docker/Kubernetes, but there is no documentation of a provisioning API, CLI, or Terraform-style IaC tool for creating/managing cloud clusters programmatically. Missing for 10: explicit programmatic provisioning API/CLI/IaC support, independent confirmation of automated cluster creation workflows.

   • [claimed-docs] “Always free — 1 cluster per user, upgrade to paid anytime.”
   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”
   • [claimed-docs] “Follow the instructions below to install one of the official client libraries, available in Python, JavaScript/TypeScript, Go, and Java.”

   proof ↗⚑ flag

   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

Self managed

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

   weight 1 · round drawn
   Weaviate~partialclaimed4/10

   Evidence confirms Kubernetes is a supported deployment option (weaviate-gh-3), which implies K8s-native deployment tooling exists, but no citation explicitly mentions an official Helm chart or Kubernetes operator. Missing for 10: explicit documentation of the Helm chart repo, operator CRDs, or production-grade K8s deployment guide.

   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”

   proof ↗⚑ flag

   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

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

   Weaviate documents built-in vectorization at import (automatic vectorization via integrated models, including its own Embeddings service) and integration with many self-hosted/API model providers, avoiding a separate embedding pipeline; it also supports natural-language query-time search that uses these configured providers. Missing for 10: independent hands-on verification of query-time embedding generation quality/reliability and broader corroboration beyond vendor docs.

   • [claimed-docs] “Import objects directly into Weaviate without having to manually specify embeddings”
   • [claimed-docs] “Import objects and vectorize them with the Weaviate Embeddings service. ](/weaviate/quickstart?import=vectorization#create-a-collection)[ …”
   • [claimed-docs] “Weaviate integrates with a variety of self-hosted and API-based models from a range of providers.”
   • [github] “Weaviate supports two approaches to store vectors: automatic vectorization at import using integrated models ... or direct import of pre-com…”
   • [github] “You can easily start Weaviate and a local vector embedding model with Docker.”
   • [claimed-docs] “Import objects and vectorize them with the Weaviate Embeddings service. Import pre-computed vector embeddings along with your data.”

   proof ↗⚑ flag

   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

Filtering

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

   weight 3 · round to Qdrant
   Weaviate~partialprobed3/10

   Evidence only hints at filtering capability via 'keyword filtering' combined with vector search (weaviate-gh-4) and mentions of inverted indexes for structured data (weaviate-probe-1), but there is no documentation addressing how structured metadata filters interact with vector search to preserve recall or latency. missing for 10: explicit docs on pre-filtering/post-filtering strategy, benchmarks or claims about recall/latency impact of combined filter+vector queries, and independent corroboration of filter performance.

   • [github] “It combines vector similarity search with keyword filtering, retrieval-augmented generation (RAG), and reranking in a single query interface…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.weaviate.io/llms.txt # Weaviate ## TL;DR Weaviate is an open-source vector database (Go) that sto…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Qdrant
   Weaviate—none0/10

   The evidence pack covers hybrid search, RAG, multi-tenancy, replication, backups, and model integrations, but contains no mention of Weaviate's filter operators (e.g., range, GeoRange, nested And/Or, ContainsAny/ContainsAll for arrays) despite these being real, documented Weaviate capabilities. Without citations describing filter syntax or examples, this story cannot be credited as delivered from this evidence pack alone.

   ⚑ flag

   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

Scaling

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

   weight 2 · round drawn
   Weaviate✓fullclaimed8/10

   Docs confirm multi-node distributed deployment with replication factor >1 for high availability, sharding via multi-tenancy (each tenant on a separate shard), and multiple deployment options including Kubernetes for cluster scaling. First-party documentation is strong but lacks independent hands-on validation of multi-node scaling specifically. Missing for 10: independent/community corroboration of production multi-node cluster scaling behavior, benchmarks on distributed performance.

   • [claimed-docs] “Multi-tenancy provides data isolation. Each tenant is stored on a separate shard. Data stored in one tenant is not visible to another tenant…”
   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1. This enables a variety of benefits such as…”
   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1.”
   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Qdrant
   Weaviate~partialclaimed5/10

   Docs confirm Weaviate replicates data across multi-node clusters via a replication factor >1 for high availability, but the evidence pack does not cite specifics of a documented consistency model (e.g., tunable consistency levels, quorum reads/writes) beyond the general HA claim. Missing for 10: explicit documentation of consistency levels/tunable consistency, cross-zone replication guarantees, and independent verification of HA behavior in production.

   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1. This enables a variety of benefits such as…”
   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1.”

   proof ↗⚑ flag

   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

Tenancy

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

   weight 2 · round to Qdrant
   Weaviate—none0/10

   The evidence pack covers multi-tenancy data isolation, replication, and backups but contains no mention of API keys, RBAC, roles, or per-collection permission enforcement — an applicable but unevidenced capability for a platform-engineer persona.

   ⚑ flag

   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

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

   weight 3 · round to Qdrant
   Weaviate~partialclaimed6/10

   Docs confirm per-tenant isolation via separate shards, auto-tenant creation, and replication for HA, which directly supports cheap multi-tenant isolation via per-tenant collections/shards (weaviate-docs-7, weaviate-docs-8, weaviate-docs-16, weaviate-docs-9, weaviate-docs-17). However, no evidence cites concrete documented limits (e.g., max tenants per node/cluster, cost/scale ceilings) that a platform engineer would need to plan capacity. missing for 10: explicit documented tenant-count limits or scaling guidance, independent benchmarks/case studies of large tenant counts.

   • [claimed-docs] “Multi-tenancy provides data isolation. Each tenant is stored on a separate shard. Data stored in one tenant is not visible to another tenant…”
   • [claimed-docs] “To change this behavior so Weaviate creates a new tenant, set `autoTenantCreation` to `true` in the collection definition.”
   • [claimed-docs] “By default, Weaviate returns an error if you try to insert an object into a non-existent tenant. To change this behavior so Weaviate creates…”
   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1. This enables a variety of benefits such as…”
   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Qdrant
   Weaviate—none0/10

   The evidence pack documents Weaviate's API/client libraries, hybrid search, RAG, and MCP server, but never compares API capabilities against a separate UI (e.g., Weaviate Cloud console) or claims feature parity between the two. Missing for 10: any explicit statement or example that every UI-console action (e.g., cluster management, monitoring, schema editing) can be replicated via the REST/GraphQL/gRPC API, and any independent confirmation of this parity.

   ⚑ flag

   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

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

   weight 3 · round drawn
   Weaviate~partialcommunity5/10

   Weaviate offers backup/restore across cloud storage providers and open client libraries (Python/JS/Go/Java) that could be used to pull data out, and the product itself is open-source, supporting a 'leave without lock-in' narrative. However there is no explicit documentation of a bulk data export feature or open interchange format (e.g., JSON/parquet dump) — backups are described as instance restores rather than portable exports. Missing for 10: explicit bulk-export/dump-to-open-format documentation, evidence of exporting vectors+metadata in a standard interchange format, and independent confirmation of successful full-data migration out of Weaviate.

   • [claimed-docs] “Seamless integration with widely-used cloud blob storage, such as AWS S3, GCS, or Azure Storage”
   • [claimed-docs] “Backup and Restore between different storage providers”
   • [claimed-docs] “Incremental backups that only store changed data, reducing backup and speeding up backup times”
   • [claimed-docs] “Choice of backing up an entire instance, or selected collections only”
   • [claimed-docs] “Follow the instructions below to install one of the official client libraries, available in Python, JavaScript/TypeScript, Go, and Java.”
   • [community] “Weaviate is pretty cool IMO. It is open source and fairly easy to get running locally... You can even run Weaviate as an embedded python pac…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Qdrant
   Weaviate✓fullprobed7/10

   Weaviate's GitHub repo and docs explicitly describe it as an open-source vector database, and a community comment independently corroborates that it is open source and can be run locally. missing for 10: explicit citation of the specific open-source license name (e.g., BSD-3-Clause) and confirmation that the full source (not just parts) is publicly available under that license.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.weaviate.io/llms.txt # Weaviate ## TL;DR Weaviate is an open-source vector database (Go) that sto…”
   • [community] “Weaviate is pretty cool IMO. It is open source and fairly easy to get running locally... You can even run Weaviate as an embedded python pac…”
   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”

   proof ↗⚑ flag

   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

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Weaviate✓fullprobed9/10

   Weaviate is explicitly open-source (Go) and offers self-hosted deployment via Docker/Kubernetes in addition to Weaviate Cloud, with community confirmation of easy local/self-hosted setup including an embedded mode. Missing for 10: no independent audit of self-hosted feature parity with the managed cloud offering (some features like Query Agent are noted cloud-only).

   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.weaviate.io/llms.txt # Weaviate ## TL;DR Weaviate is an open-source vector database (Go) that sto…”
   • [community] “Weaviate is pretty cool IMO. It is open source and fairly easy to get running locally... You can even run Weaviate as an embedded python pac…”
   • [claimed-docs] “Get answers from your data by using a natural language prompt/question. Cloud only”
   • [github] “You can easily start Weaviate and a local vector embedding model with Docker.”

   proof ↗⚑ flag

   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

Benchmarks

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

   weight 2 · round drawn
   Weaviate—none0/10

   No evidence pack items contain published benchmarks, latency numbers, recall metrics, or any quantitative performance comparisons; the docs focus on feature descriptions (hybrid search, multi-tenancy, backups, replication) without measured performance data. missing for 10: benchmark reports, latency/recall figures, third-party performance evaluations.

   ⚑ flag

   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

Index tuning

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

   weight 2 · round to Qdrant
   Weaviate—none0/10

   The evidence pack contains no mention of HNSW parameters (ef, efConstruction, maxConnections), index type selection (flat vs HNSW vs dynamic), or any recall/latency/memory tuning guidance — only general search, multi-tenancy, replication, and backup features are covered. Missing for 10: any documentation of HNSW graph parameter configuration, index type trade-off guidance, or benchmarks showing recall/latency/memory tuning.

   ⚑ flag

   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

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

   weight 2 · round to Qdrant
   Weaviate—none0/10

   The evidence pack contains no mention of vector quantization (PQ, BQ, SQ) or compression features, nor any documented accuracy/memory trade-offs, despite Weaviate actually shipping such features in reality; based solely on this evidence pack, there is no support. Missing for 10: any mention of quantization/compression config options, memory/storage savings benchmarks, or documented recall/accuracy trade-off data.

   ⚑ flag

   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

Pricing

1. developerPrototype on a meaningful free tier before paying anything

   weight 1 · round to Qdrant
   Weaviate~partialclaimed5/10

   Weaviate Cloud offers an 'Always free' 1 cluster tier per user that upgrades to paid anytime, which supports prototyping without payment. However, evidence doesn't detail the free tier's resource limits, duration, or whether it's sufficient for meaningful real-world prototyping, and self-hosted open-source use (free but requiring infra) is a separate path not tied to this pricing claim. missing for 10: details on free tier limits/quotas, independent user confirmation of the free tier being 'meaningful' for real prototyping, comparison to competitor free tiers.

   • [claimed-docs] “Always free — 1 cluster per user, upgrade to paid anytime.”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Weaviate—none0/10

   The only pricing evidence describes a free tier as '1 cluster per user, upgrade to paid anytime,' implying cluster-based provisioning rather than serverless usage-based per-unit billing; no evidence of transparent per-unit consumption pricing is present.

   • [claimed-docs] “Always free — 1 cluster per user, upgrade to paid anytime.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Qdrant
   Weaviate~partialclaimed3/10

   Weaviate can be self-hosted via Docker/Kubernetes or run in Weaviate Cloud, which implicitly gives users control over where their data physically resides, but there is no explicit documentation of region-selection or data-residency features for Weaviate Cloud. missing for 10: explicit region/data-residency configuration options, compliance certifications (e.g., GDPR region pinning), and any documentation on choosing a cloud region for hosted deployments.

   • [github] “Weaviate offers multiple installation and deployment options: Docker, Kubernetes, Weaviate Cloud”

   proof ↗⚑ flag

   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

2. ai-native userControl data retention and deletion

   weight 2 · round to Qdrant
   Weaviate—none0/10

   The evidence pack covers hybrid search, RAG, multi-tenancy, replication, and backups, but contains no documentation of object/collection deletion APIs, TTL-based expiration, or data retention policies that would let an AI-native user control how long data persists or ensure deletion. Multi-tenancy (isolation) and backups (durability) are adjacent but do not address retention/deletion controls.

   • [claimed-docs] “Multi-tenancy provides data isolation. Each tenant is stored on a separate shard. Data stored in one tenant is not visible to another tenant…”
   • [claimed-docs] “Weaviate allows data replication across a multi-node cluster by setting a replication factor > 1. This enables a variety of benefits such as…”
   • [claimed-docs] “Seamless integration with widely-used cloud blob storage, such as AWS S3, GCS, or Azure Storage”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Weaviate—none0/10

   No evidence pack item mentions telemetry, usage tracking, opt-out settings, or privacy configuration options for Weaviate; the axis applies to any self-hostable database product but no supporting documentation is provided.

   ⚑ flag

   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

Integrations

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

   weight 2 · round to Weaviate
   Weaviate~partialcommunity4/10

   Evidence confirms Weaviate is usable as a RAG backend with official client libraries and an MCP server, and a community report shows it being used with a LangChain retriever (WeaviateHybridSearchRetriever) in practice, but that same report flags a concrete functional gap (can't get it to work asynchronously). There is no first-party documentation in the pack of maintained LangChain/LlamaIndex integration pages, and LlamaIndex is not mentioned at all. Missing for 10: official docs/changelog for LangChain and LlamaIndex integrations, confirmation the async issue is resolved, and any first-party integration-maintenance statement.

   • [claimed-docs] “Weaviate can serve as a robust backend for RAG workflows, where vector search is used to retrieve context that enhances the output of genera…”
   • [claimed-docs] “These agents can leverage semantic insights to make decisions or trigger actions based on the data stored in Weaviate.”
   • [claimed-docs] “Follow the instructions below to install one of the official client libraries, available in Python, JavaScript/TypeScript, Go, and Java.”
   • [community] “Just migrated from Supabase + pgvector to Weaviate hoping to take advantage of langchain.retrievers.weaviate_hybrid_search.WeaviateHybridSea…”
   • [github] “It combines vector similarity search with keyword filtering, retrieval-augmented generation (RAG), and reranking in a single query interface…”

   proof ↗⚑ flag

   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

Sdks

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

   weight 2 · round drawn
   Weaviate✓fullclaimed8/10

   Official docs explicitly state client libraries are available in Python, JavaScript/TypeScript, Go, and Java, matching the story's exact language list. missing for 10: independent hands-on corroboration of each SDK's parity/quality, and no mention of versioning or release cadence across languages.

   • [claimed-docs] “Follow the instructions below to install one of the official client libraries, available in Python, JavaScript/TypeScript, Go, and Java.”

   proof ↗⚑ flag

   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

Core search

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

   weight 3 · round to Qdrant
   Weaviate~partialprobed5/10

   Weaviate's core function as a vector database with semantic/vector similarity search is well evidenced (docs-22, docs-26, gh-4, probe-1 confirm it stores vectors and runs ANN-style similarity search, often combined with keyword search), but the evidence pack never explicitly documents configurable distance metrics (e.g., cosine, dot product, L2) or ANN indexing parameters like HNSW settings. Missing for 10: explicit documentation of selectable distance metrics, HNSW/ANN index configuration options, and independent hands-on confirmation of metric selection working as expected.

   • [claimed-docs] “By indexing data with vectors, Weaviate supports searches based on both semantic similarity and keywords.”
   • [claimed-docs] “Weaviate supports searches based on both semantic similarity and keywords. This allows for more relevant results even when the query terms d…”
   • [github] “It combines vector similarity search with keyword filtering, retrieval-augmented generation (RAG), and reranking in a single query interface…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.weaviate.io/llms.txt # Weaviate ## TL;DR Weaviate is an open-source vector database (Go) that sto…”
   • [github] “Weaviate supports two approaches to store vectors: automatic vectorization at import using integrated models ... or direct import of pre-com…”

   proof ↗⚑ flag

   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

Hybrid

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

   weight 2 · round to Weaviate
   Weaviate✓fullclaimed8/10

   Weaviate natively supports BM25 keyword search combined with vector search via hybrid search (fusion algorithms), built directly into the database without needing a separate search engine like Elasticsearch. missing for 10: independent hands-on benchmarking of BM25-only relevance/performance, and clearer documentation on pure keyword-only query mode without vector component.

   • [claimed-docs] “Hybrid search combines vector search and keyword search (BM25) to leverage the strengths of both approaches.”
   • [claimed-docs] “Weaviate supports two strategies (`relativeScoreFusion` and `rankedFusion`) for combining vector and keyword search scores”
   • [claimed-docs] “A hybrid search runs both search types in parallel and combines their scores to produce a final ranking of results.”
   • [claimed-docs] “By indexing data with vectors, Weaviate supports searches based on both semantic similarity and keywords.”
   • [claimed-docs] “Weaviate supports searches based on both semantic similarity and keywords. This allows for more relevant results even when the query terms d…”
   • [github] “It combines vector similarity search with keyword filtering, retrieval-augmented generation (RAG), and reranking in a single query interface…”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Weaviate
   Weaviate✓fullcommunity9/10

   Weaviate's docs explicitly describe hybrid search combining vector and BM25 keyword search with two fusion algorithms (relativeScoreFusion, rankedFusion) run in parallel and merged into a final ranking, matching the story precisely. Community discussion confirms real-world usage of hybrid search fusion (with minor confusion over fusion algorithm internals, not a failure). Missing for 10: no independent benchmark or hands-on quality comparison of fusion ranking accuracy.

   • [claimed-docs] “Hybrid search combines vector search and keyword search (BM25) to leverage the strengths of both approaches.”
   • [claimed-docs] “Weaviate supports two strategies (`relativeScoreFusion` and `rankedFusion`) for combining vector and keyword search scores”
   • [claimed-docs] “A hybrid search runs both search types in parallel and combines their scores to produce a final ranking of results.”
   • [github] “It combines vector similarity search with keyword filtering, retrieval-augmented generation (RAG), and reranking in a single query interface…”
   • [community] “I feel like small formulas could clarify better these 2 fusion algorithms. I have read the article twice and checked some of the references …”

   proof ↗⚑ flag

   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

Reranking

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

   weight 2 · round to Weaviate
   Weaviate~partialclaimed5/10

   Weaviate's GitHub README explicitly states it combines vector search, keyword filtering, RAG, and reranking in a single query interface, indicating built-in reranking support, but the evidence pack lacks first-party docs detailing specific reranker modules (e.g., Cohere, transformers) or configuration guidance. missing for 10: dedicated reranker-module docs, list of supported reranking providers, hands-on validation of reranking quality/behavior.

   • [github] “It combines vector similarity search with keyword filtering, retrieval-augmented generation (RAG), and reranking in a single query interface…”

   proof ↗⚑ flag

   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