Qdrant vs HelixDB

Agent access

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

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

   HelixDB✓fullprobed9/10

   A probe confirms a live, working llms.txt at docs.helix-db.com/llms.txt describing HelixDB for agent consumption, and the docs/GitHub bootstrapper (helix chef) explicitly installs 'docs MCP' to let agents query docs directly, reinforcing agent-oriented documentation access. Missing for 10: independent (non-vendor) confirmation that agents actually consume and act correctly on the llms.txt content.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.helix-db.com/llms.txt # HelixDB > HelixDB combines a property graph, approximate vector search, an…”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”
   • [probe] “official MCP server documented at https://docs.helix-db.com/database/helix-cloud/connect/mcp”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Qdrant~partialcommunity6/10

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

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

   proof ↗⚑ flag

   HelixDB~partialprobed6/10

   Docs show a CLI-driven quickstart (initialize, start a local instance, run query, stop it) and an embedded in-process mode, both of which are amenable to scripting/CI automation, and a CLI is documented separately. However, there is no explicit CI/CD example, non-interactive flag documentation, or Docker/headless deployment guidance in the pack. missing for 10: explicit CI pipeline example, non-interactive/headless flags, containerized automation docs.

   • [claimed-docs] “Initialize HelixDB, start a local instance, run the generated query, and stop it”
   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [probe] “official CLI documented at https://docs.helix-db.com/cli/getting-started”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”

   proof ↗⚑ flag

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

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

   HelixDB✓fullprobed7/10

   HelixDB documents an official MCP server (helix-cloud/connect/mcp) with tools like helix_execute_read_query requiring scoped permissions, and a probe confirms this MCP endpoint exists; the helix chef bootstrapper also installs a 'docs MCP'. Missing for 10: independent/hands-on confirmation of an agent successfully connecting via this MCP server, and fuller documentation of the full tool set beyond read queries.

   • [claimed-docs] “helix_execute_read_query: execute exact v3 request_type: "read" JSON; requires database.query.read.”
   • [probe] “official MCP server documented at https://docs.helix-db.com/database/helix-cloud/connect/mcp”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   HelixDB✓fullprobed7/10

   HelixDB ships an official CLI (documented at docs.helix-db.com/cli/getting-started) used for init/start/stop workflows and a 'helix chef' bootstrapper that installs AI query skills, scaffolds projects, and seeds data — clearly geared toward AI-native/agentic workflows. missing for 10: independent hands-on confirmation of the CLI's AI-specific features and no detail on full command surface beyond quickstart/bootstrap.

   • [probe] “official CLI documented at https://docs.helix-db.com/cli/getting-started”
   • [claimed-docs] “Initialize HelixDB, start a local instance, run the generated query, and stop it”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”

   proof ↗⚑ flag

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

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

   HelixDB✓fullprobed8/10

   HelixDB exposes a documented, machine-readable public API surface: an OpenAPI spec (helixdb-probe-2), an llms.txt for LLM consumption (helixdb-probe-1), a unified operation-tree request model across Rust/TypeScript/Go/Python SDKs (helixdb-docs-6), a documented CLI (helixdb-probe-4), and an official MCP server with concrete tool definitions like helix_execute_read_query (helixdb-docs-8, helixdb-probe-3). This gives an AI-native user multiple first-party, documented entry points to drive the product programmatically. Missing for 10: independent/hands-on corroboration that the documented API surface is complete and stable in practice (community comments focus on the HelixQL query language's AI-friendliness rather than the API/documentation itself, so they don't concretely contradict this story).

   • [claimed-docs] “HelixDB v3 uses one operation-tree request model across the Rust, TypeScript, Go, and Python SDKs.”
   • [claimed-docs] “helix_execute_read_query: execute exact v3 request_type: "read" JSON; requires database.query.read.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.helix-db.com/llms.txt # HelixDB > HelixDB combines a property graph, approximate vector search, an…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.helix-db.com/openapi.json — contains "openapi" key”
   • [probe] “official MCP server documented at https://docs.helix-db.com/database/helix-cloud/connect/mcp”
   • [probe] “official CLI documented at https://docs.helix-db.com/cli/getting-started”

   proof ↗⚑ flag

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

   weight 2 · round to Qdrant
   Qdrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   HelixDB✓fullclaimed7/10

   HelixDB docs explicitly describe scoped API keys with read-only, read-write, or operation-restricted permissions for least-privilege credentials per service/environment (RBAC), and the MCP tool docs show specific permission scopes (e.g., database.query.read) required per operation, directly matching the story for issuing scoped credentials to an agent. Missing for 10: independent/hands-on verification that these scoped keys work as documented in practice, and more detail on credential issuance workflow (e.g., via CLI/dashboard) rather than just a feature description.

   • [claimed-docs] “Role-based access control. Scoped API keys with read-only, read-write, or operation-restricted permissions for least-privilege credentials p…”
   • [claimed-docs] “helix_execute_read_query: execute exact v3 request_type: "read" JSON; requires database.query.read.”
   • [claimed-docs] “Database-specific overrides can change the sustained rate, burst capacity, and query attempt budget.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

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

   HelixDB✓fullprobed8/10

   HelixDB documents official SDKs across Rust, TypeScript, Go, and Python built on a unified v3 operation-tree request model, plus a CLI and MCP integration for AI-native tooling. Missing for 10: independent hands-on validation of SDK quality/parity and more detail on SDK-specific docs beyond the overview page.

   • [claimed-docs] “HelixDB v3 uses one operation-tree request model across the Rust, TypeScript, Go, and Python SDKs.”
   • [probe] “official CLI documented at https://docs.helix-db.com/cli/getting-started”
   • [probe] “official MCP server documented at https://docs.helix-db.com/database/helix-cloud/connect/mcp”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Qdrant—none0/10

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

   ⚑ flag

   HelixDB—none0/10

   No evidence of webhook subscription or event-notification capability anywhere in the docs, CLI, MCP, or API references; the evidence covers queries, indexes, security, and multi-tenancy but nothing about event-driven webhooks.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   Qdrant—none0/10

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

   ⚑ flag

   HelixDB—none0/10

   The evidence describes HelixDB as a graph/vector/text database with MCP-based query access and an AI-assisted bootstrapper for scaffolding, but there is no mention of the product itself generating insights, summaries, or suggestions from stored data — it only lets external AI agents issue read/write queries against the data.

   ⚑ flag

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

   weight 3 · round drawn
   Qdrant—none0/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   HelixDB documents an MCP server for external AI agents/tools to connect to it, and a 'helix chef' bootstrapper that scaffolds projects, but there is no evidence of a built-in AI assistant inside the product itself that a user can delegate tasks to.

   • [claimed-docs] “helix_execute_read_query: execute exact v3 request_type: "read" JSON; requires database.query.read.”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”
   • [probe] “official MCP server documented at https://docs.helix-db.com/database/helix-cloud/connect/mcp”

   proof ↗⚑ flag

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

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

   HelixDB!disputedcontradicted3/10

   HelixDB offers an MCP server and a 'chef' bootstrapper that installs query skills for AI agents, suggesting some agentic tooling, but interaction still requires exact HelixQL syntax or precise JSON request_type payloads (helixdb-docs-8), not free natural-language commands. Multiple hands-on community reports explicitly contradict any natural-language-command capability, calling HelixQL an added 'barrier to entry' that isn't 'AI coding friendly' and asking to 'sidestep the DSL' so LLMs can generate queries more easily (helixdb-comm-1, helixdb-comm-2, helixdb-comm-5, helixdb-comm-10). Missing for 10: evidence of a true NL-to-query interface, first-party benchmarks showing NL command success, and resolution of the DSL-friction complaints.

   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”
   • [claimed-docs] “helix_execute_read_query: execute exact v3 request_type: "read" JSON; requires database.query.read.”
   • [community] “At the moment I wouldn't consider HelixDB because of HelixQL. With OpenCypher even older cheap models can generate queries... by creating He…”
   • [community] “Can I run this as an embedded DB like sqlite? Can I sidestep the DSL? I want my LLMs to generate queries and using a new language is going t…”
   • [community] “our new query language, HelixQL — But why? Why increase the barrier of entry for your system?”
   • [community] “This is very cool, and right up my alley. Hesitant to try it out because of the bespoke query language for now.”

   proof ↗⚑ flag

Api quality

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

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

   HelixDB~partialprobed4/10

   There's an OpenAPI spec exposed (openapi.json) and a quickstart doc that walks through initializing, running, and stopping a generated query, showing some runnable-example content, but no evidence of an actual interactive API reference UI (e.g., Swagger/Redoc-style 'try it out' explorer) tied to that spec. Missing for 10: evidence of an interactive browsable API reference with embedded runnable/executable examples, not just a static OpenAPI JSON file and CLI quickstart.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.helix-db.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Initialize HelixDB, start a local instance, run the generated query, and stop it”
   • [probe] “official CLI documented at https://docs.helix-db.com/cli/getting-started”

   proof ↗⚑ flag

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

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

   HelixDB✓fullprobed8/10

   A live probe confirms an OpenAPI spec is served at docs.helix-db.com/openapi.json returning HTTP 200 with an 'openapi' key, plus an llms.txt machine-readable doc endpoint, giving concrete evidence of downloadable machine-readable specs. Missing for 10: no independent/community confirmation of the spec's completeness or usage in the wild, and no first-party doc page explicitly describing/linking the OpenAPI spec as a supported artifact.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.helix-db.com/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.helix-db.com/llms.txt # HelixDB > HelixDB combines a property graph, approximate vector search, an…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Qdrant~partialcommunity6/10

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

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

   proof ↗⚑ flag

   HelixDB~partialclaimed6/10

   Docs describe running a local/embedded HelixDB instance (quickstart, embedded engine) and a one-shot 'helix chef' bootstrapper that scaffolds a project, starts a local instance, and seeds example data — effectively a local sandbox distinct from any production deployment. Scoped, environment-specific API keys (read-only/read-write) further support separating test vs prod credentials. However, there is no explicit 'sandbox mode' or staging/production isolation feature documented, and no community/hands-on confirmation that this local setup is used specifically to avoid touching production data. Missing for 10: explicit sandbox/staging environment documentation, isolation guarantees between local and prod data, and independent user confirmation of this workflow.

   • [claimed-docs] “Initialize HelixDB, start a local instance, run the generated query, and stop it”
   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”
   • [claimed-docs] “Role-based access control. Scoped API keys with read-only, read-write, or operation-restricted permissions for least-privilege credentials p…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Qdrant—none0/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   There is mention of a v3 request model and release notes, but no evidence of a formal API versioning scheme or documented deprecation policy for HelixDB's APIs/SDKs/query language.

   ⚑ flag

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

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

   HelixDB—none0/10

   The evidence pack contains no mention of batch/bulk insert, bulk update, or multi-item operation APIs; the closest is a single operation-tree request model (helixdb-docs-6) and ACID transactions (helixdb-docs-9), but neither describes performing operations across many items at once.

   ⚑ flag

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

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

   HelixDB—none0/10

   HelixDB is a graph/vector/text database with query and transaction capabilities, but no evidence describes event-driven triggers, rules engines, or automatic actions firing on data events; the evidence pack only covers queries, indexes, SDKs, MCP access, and access control.

   ⚑ flag

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

   weight 1 · round drawn
   Qdrant—none0/10

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

   ⚑ flag

   HelixDB—none0/10

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

   ⚑ flag

Backup

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

   weight 2 · round to Qdrant
   Qdrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   No evidence of any backup/snapshot or restore capability for collections; docs cover embedded storage, indexes, transactions, RBAC, and multi-tenancy but never mention backup or restore workflows. missing for 10: any documentation of snapshot creation, backup scheduling, or restore procedures.

   ⚑ flag

Freshness

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

   weight 2 · round to Qdrant
   Qdrant~partialcommunity4/10

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

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

   proof ↗⚑ flag

   HelixDB~partialclaimed3/10

   Docs claim ACID transactions across graph, vector, and text data in a single transaction, implying consistent updates, and search/filtering across nodes and edges, but there is no explicit documentation of upsert/delete operations or freshness/consistency guarantees for how quickly search results reflect changes. Missing for 10: explicit upsert/delete API documentation, documented latency/consistency model for index updates, and independent verification of update-to-search-visibility timing.

   • [claimed-docs] “ACID transactions across graph, vector, and text data in a single transaction.”
   • [claimed-docs] “Search and filtering on both nodes and edges, not just nodes.”
   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [claimed-docs] “Text indexes provide durable BM25 search over string properties on nodes or edges.”

   proof ↗⚑ flag

Portability

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

   weight 2 · round to Qdrant
   Qdrant~partialclaimed5/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   No evidence of a documented bulk-import/export mechanism for vectors and metadata in specific formats; docs cover vector indexes, transactions, and query capabilities but not batch load/dump tooling or file formats. missing for 10: bulk import/export commands or APIs, documented file formats (e.g. CSV/Parquet/JSON), and any example or CLI reference for data migration.

   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [claimed-docs] “ACID transactions across graph, vector, and text data in a single transaction.”
   • [claimed-docs] “Database-specific overrides can change the sustained rate, burst capacity, and query attempt budget.”

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

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

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

   proof ↗⚑ flag

   HelixDB✓fullcommunity8/10

   First-party docs explicitly describe an embedded mode ("run the same engine and queries in process with memory, disk, or object storage") and a quickstart/CLI flow for starting and stopping a local instance for development, corroborated by the helix chef bootstrapper that scaffolds and starts a local instance. Missing for 10: independent/hands-on confirmation that embedded mode works as described, and a direct answer to the community question about running it like an embedded SQLite-style DB.

   • [claimed-docs] “Initialize HelixDB, start a local instance, run the generated query, and stop it”
   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”
   • [community] “Can I run this as an embedded DB like sqlite? Can I sidestep the DSL? I want my LLMs to generate queries and using a new language is going t…”

   proof ↗⚑ flag

Managed cloud

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

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

   HelixDB~partialprobed5/10

   Helix Cloud is documented as a real managed offering with multi-tenancy, RBAC/API keys, and configurable rate limits, and a CLI plus OpenAPI spec exist, implying some programmatic control-plane surface. However there is no explicit documentation of an API/CLI command dedicated to provisioning or spinning up new cloud database instances programmatically, and community threads note pricing (~$600/mo) without confirming a self-serve programmatic provisioning flow. Missing for 10: explicit provisioning API/CLI examples (create/delete/scale a Helix Cloud instance), infra-as-code (e.g. Terraform) support, and independent confirmation of automated provisioning working end-to-end.

   • [claimed-docs] “Helix Cloud focuses on row-level isolation, which lets you implement any tenancy model at the application layer without structural constrain…”
   • [claimed-docs] “Role-based access control. Scoped API keys with read-only, read-write, or operation-restricted permissions for least-privilege credentials p…”
   • [claimed-docs] “Database-specific overrides can change the sustained rate, burst capacity, and query attempt budget.”
   • [probe] “official CLI documented at https://docs.helix-db.com/cli/getting-started”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.helix-db.com/openapi.json — contains "openapi" key”
   • [community] “can you host this yourself or do you need to use helix-cloud? ... it looks like that starts at like $600/mo which is above my experimentatio…”

   proof ↗⚑ flag

Self managed

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

   weight 1 · round to Qdrant
   Qdrant~partialclaimed4/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   No evidence of a Helm chart, Kubernetes operator, or any Kubernetes-specific deployment guidance; the evidence pack only covers local/embedded quickstart, Helix Cloud (managed multi-tenant), CLI, and MCP setup. Community threads even question self-hosting options versus Helix Cloud, with no mention of K8s tooling.

   • [claimed-docs] “Initialize HelixDB, start a local instance, run the generated query, and stop it”
   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [community] “can you host this yourself or do you need to use helix-cloud? ... it looks like that starts at like $600/mo which is above my experimentatio…”
   • [probe] “official CLI documented at https://docs.helix-db.com/cli/getting-started”

   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 Qdrant
   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

   HelixDB—none0/10

   Evidence shows vector indexes for storing and ranking embeddings, but there is no mention of built-in embedding generation or configurable model providers at ingest/query time — users still appear to supply vectors themselves. missing for 10: any documentation of built-in embedding generation, model provider configuration, or automatic text-to-vector conversion at ingest/query time.

   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [claimed-docs] “ACID transactions across graph, vector, and text data in a single transaction.”
   • [claimed-docs] “Search and filtering on both nodes and edges, not just nodes.”

   proof ↗⚑ flag

Filtering

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

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

   HelixDB~partialcommunity6/10

   Docs explicitly describe pre-filtering an exact candidate set via graph traversal before vector ranking, plus vector indexes with distance metrics, search/filtering on nodes and edges, and text/BM25 indexes that can combine with vector search — supporting metadata-constrained vector search. However there is no benchmark or independent evidence quantifying recall/latency impact of filtering, and community comments raise concerns about performance on multi-hop queries and small benchmark datasets, which is adjacent but not a direct contradiction of filtered-vector-search quality. missing for 10: quantified recall/latency benchmarks specifically for filtered vector search, independent hands-on validation that filtering doesn't degrade recall/latency.

   • [claimed-docs] “traverse and filter an exact candidate set before vector ranking, so results cannot escape graph or permission boundaries.”
   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [claimed-docs] “Search and filtering on both nodes and edges, not just nodes.”
   • [claimed-docs] “Text indexes provide durable BM25 search over string properties on nodes or edges.”
   • [community] “We've been having some issues with intermittent performance on multi hop queries. What's your p99 like for multi hops?”
   • [community] “page says your benchmark runs on 5M of records only. Is it incredibly small dataset in current world... count(*) query having 5s latency on …”

   proof ↗⚑ flag

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

   weight 2 · round to Qdrant
   Qdrant~partialclaimed5/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   Docs mention generic 'search and filtering on nodes and edges' and vector/text indexes, but there is no evidence of range queries, geo filters, nested boolean logic, or array-membership filtering in HelixQL. missing for 10: range filter examples, geo/spatial filter support, nested AND/OR/NOT boolean composition, array/IN membership filters.

   • [claimed-docs] “Search and filtering on both nodes and edges, not just nodes.”
   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [claimed-docs] “Text indexes provide durable BM25 search over string properties on nodes or edges.”

   proof ↗⚑ flag

Scaling

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

   weight 2 · round to Qdrant
   Qdrant✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   No evidence of sharding, clustering, or distributed multi-node deployment; docs focus on embedded/single-instance database and Helix Cloud's row-level multi-tenancy at the application layer, not horizontal scaling across nodes. Community threads even question source availability and self-hosting scale, but nothing confirms distributed/sharded architecture.

   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [claimed-docs] “Helix Cloud focuses on row-level isolation, which lets you implement any tenancy model at the application layer without structural constrain…”
   • [community] “Where's the source code for the database itself? Looks like the repo is just a client.”
   • [community] “page says your benchmark runs on 5M of records only. Is it incredibly small dataset in current world... count(*) query having 5s latency on …”

   proof ↗⚑ flag

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

   weight 2 · round to Qdrant
   Qdrant~partialcommunity6/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   No evidence of any replication, multi-node clustering, or documented consistency model; docs mention row-level tenancy isolation and RBAC but nothing about cross-node/zone replication or HA guarantees. missing for 10: replication architecture, multi-zone/multi-node deployment topology, consistency model documentation (e.g., CP/AP tradeoffs), failover/HA guarantees.

   • [claimed-docs] “Helix Cloud focuses on row-level isolation, which lets you implement any tenancy model at the application layer without structural constrain…”
   • [claimed-docs] “Role-based access control. Scoped API keys with read-only, read-write, or operation-restricted permissions for least-privilege credentials p…”

   proof ↗⚑ flag

Tenancy

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

   weight 2 · round to Qdrant
   Qdrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   HelixDB~partialclaimed6/10

   Docs confirm scoped API keys with read-only/read-write/operation-restricted roles and least-privilege credentials per service/environment (helixdb-docs-11), plus row-level isolation for tenancy (helixdb-docs-7) and per-database rate/limit overrides (helixdb-docs-13). However, there's no evidence of true per-collection (per-node-type/index) permission scoping — isolation is described at row-level/application-layer, not as fine-grained collection ACLs, and no independent/hands-on confirmation exists. Missing for 10: explicit per-collection/per-schema-object permission granularity, independent validation of RBAC enforcement in production.

   • [claimed-docs] “Role-based access control. Scoped API keys with read-only, read-write, or operation-restricted permissions for least-privilege credentials p…”
   • [claimed-docs] “Helix Cloud focuses on row-level isolation, which lets you implement any tenancy model at the application layer without structural constrain…”
   • [claimed-docs] “Database-specific overrides can change the sustained rate, burst capacity, and query attempt budget.”

   proof ↗⚑ flag

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

   weight 3 · round to Qdrant
   Qdrant✓fullclaimed7/10

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

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

   proof ↗⚑ flag

   HelixDB~partialclaimed3/10

   Helix Cloud docs describe only row-level isolation implemented at the application layer, explicitly noting 'no structural constraints on the database' rather than native namespaces, partitions, or per-tenant collections; RBAC/scoped API keys and rate-limit overrides exist but are not tied to a documented per-tenant isolation model with limits. missing for 10: native namespace/partition/collection-based tenant isolation, documented per-tenant resource limits, and any benchmark or case study showing cheap multi-tenant scaling.

   • [claimed-docs] “Helix Cloud focuses on row-level isolation, which lets you implement any tenancy model at the application layer without structural constrain…”
   • [claimed-docs] “Role-based access control. Scoped API keys with read-only, read-write, or operation-restricted permissions for least-privilege credentials p…”
   • [claimed-docs] “Database-specific overrides can change the sustained rate, burst capacity, and query attempt budget.”

   proof ↗⚑ flag

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

   weight 2 · round to Qdrant
   Qdrant~partialprobed6/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   The evidence pack documents SDKs, CLI, MCP server, and OpenAPI spec but never describes a HelixDB UI/console or compares its feature set against the API, so there's no basis to confirm API-UI parity. missing for 10: any description of a HelixDB web console/UI feature set, and evidence that all such features are also exposed via API/CLI/SDK.

   ⚑ flag

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

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

   HelixDB—none0/10

   While HelixDB is Apache 2.0 open source (helixdb-docs-12) and can run embedded/self-hosted (helixdb-docs-2), there is no evidence of an explicit data export/migration tool or open-format data dump capability, and community comments explicitly raise vendor lock-in concerns about the bespoke query language (helixdb-comm-3, helixdb-comm-8) with no rebuttal shown for data portability.

   • [claimed-docs] “Open source: Apache 2.0 licensed and developed in the open on GitHub.”
   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [community] “> so much easier that it's worth a bit of a learning curve — I think you misspelled 'vendor lock in'”
   • [community] “can you host this yourself or do you need to use helix-cloud? ... it looks like that starts at like $600/mo which is above my experimentatio…”

   proof ↗⚑ flag

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

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

   HelixDB!disputedcontradicted4/10

   HelixDB's docs and site state it is Apache 2.0 licensed and developed in the open on GitHub, with a public repo. However, a firsthand community report explicitly questions this, noting 'Where's the source code for the database itself? Looks like the repo is just a client,' suggesting the core engine may not be fully open despite the license claim. missing for 10: a rebuttal or confirmation that the full database engine (not just client/SDK code) is in the public repo, and independent verification of build-from-source for the core engine.

   • [claimed-docs] “Open source: Apache 2.0 licensed and developed in the open on GitHub.”
   • [github] “helix chef is an interactive, one-shot bootstrapper. It installs the HelixDB query skills and docs MCP, scaffolds a project, starts a local …”
   • [community] “Where's the source code for the database itself? Looks like the repo is just a client.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

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

   HelixDB✓fullcommunity8/10

   HelixDB docs show a working local self-host quickstart, an embedded-database mode (memory/disk/object storage), and Apache-2.0 open-source licensing, directly supporting self-hosting the core engine. Community skepticism (e.g., asking whether the public repo is 'just a client') raises an open question but is not a confirmed hands-on failure, so it tempers confidence rather than the verdict. Missing for 10: independent third-party confirmation that a self-hosted instance matches Helix Cloud's full feature set, and clarification of the 'is the core engine actually in the repo' community question.

   • [claimed-docs] “Initialize HelixDB, start a local instance, run the generated query, and stop it”
   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [claimed-docs] “Open source: Apache 2.0 licensed and developed in the open on GitHub.”
   • [community] “Where's the source code for the database itself? Looks like the repo is just a client.”
   • [community] “can you host this yourself or do you need to use helix-cloud? ... it looks like that starts at like $600/mo which is above my experimentatio…”

   proof ↗⚑ flag

Benchmarks

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

   weight 2 · round drawn
   Qdrant—none0/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   The evidence pack contains no first-party (claimed-docs) benchmark tables, latency, or recall numbers for HelixDB; the only performance data referenced comes from community discussion (e.g., a mention of a benchmark page running on 5M records with 5s count(*) latency, and unanswered questions about p99 multi-hop latency), which is not corroborated by any vendor-tier documentation in this pack. Because disputed verdicts require citations from two distinct tiers and only community-tier evidence exists here, this axis cannot be marked disputed and instead shows no vendor-backed performance evidence. missing for 10: published first-party benchmark methodology, latency percentiles (p50/p95/p99), recall metrics for vector/BM25 search, and independent reproduction of any performance claims.

   • [community] “We've been having some issues with intermittent performance on multi hop queries. What's your p99 like for multi hops?”
   • [community] “page says your benchmark runs on 5M of records only. Is it incredibly small dataset in current world... count(*) query having 5s latency on …”

   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
   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

   HelixDB—none0/10

   Docs mention that vector indexes require a dimension and distance metric, but there is no evidence of exposing HNSW-specific tuning knobs (e.g., M, ef_construction, ef_search) or alternative index types that would let an ml-engineer trade recall against latency/memory. Community threads even raise unresolved performance concerns on multi-hop queries with no mention of tunable index parameters.

   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [community] “We've been having some issues with intermittent performance on multi hop queries. What's your p99 like for multi hops?”
   • [community] “page says your benchmark runs on 5M of records only. Is it incredibly small dataset in current world... count(*) query having 5s latency on …”

   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
   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

   HelixDB—none0/10

   Evidence covers vector indexes (dimension/distance metric) but nowhere mentions quantization, compression, or any documented accuracy/memory trade-off; no evidence of such a feature existing. missing for 10: quantization/compression feature docs, memory/storage savings data, accuracy trade-off benchmarks.

   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”

   proof ↗⚑ flag

Pricing

1. developerPrototype on a meaningful free tier before paying anything

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

   HelixDB~partialcommunity5/10

   HelixDB is Apache 2.0 open source and can be run locally/embedded entirely free for prototyping (helixdb-docs-12, helixdb-docs-1, helixdb-docs-2), satisfying the 'free before paying' story via self-hosting. However, for the managed Helix Cloud offering there is no documented free tier, and a community report states cloud pricing starts around $600/mo, well above an experimentation budget (helixdb-comm-8), contradicting a 'meaningful free tier' for the hosted product path. missing for 10: an explicit low/no-cost Helix Cloud tier, first-party pricing page confirming free-tier limits, and evidence rebutting the $600/mo complaint.

   • [claimed-docs] “Open source: Apache 2.0 licensed and developed in the open on GitHub.”
   • [claimed-docs] “Initialize HelixDB, start a local instance, run the generated query, and stop it”
   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [community] “can you host this yourself or do you need to use helix-cloud? ... it looks like that starts at like $600/mo which is above my experimentatio…”
   • [claimed-docs] “Database-specific overrides can change the sustained rate, burst capacity, and query attempt budget.”

   proof ↗⚑ flag

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

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

   HelixDB—none0/10

   No evidence in the pack shows HelixDB offering serverless, usage-based, per-unit transparent pricing; the only pricing signal is a community report that Helix Cloud 'starts at like $600/mo' — suggesting a flat/tiered plan rather than metered usage-based billing. Rate-limit docs (sustained rate, burst capacity) describe throttling, not a pricing model.

   • [community] “can you host this yourself or do you need to use helix-cloud? ... it looks like that starts at like $600/mo which is above my experimentatio…”
   • [claimed-docs] “Database-specific overrides can change the sustained rate, burst capacity, and query attempt budget.”

   proof ↗⚑ flag

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

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

   HelixDB—none0/10

   HelixDB can be self-hosted or embedded (giving implicit control over data location), but there is no evidence of an explicit region/residency selection feature for Helix Cloud or any documented data-residency controls. missing for 10: explicit region selection options, data residency guarantees/documentation, compliance certifications tied to geography.

   • [claimed-docs] “Embedded database — run the same engine and queries in process with memory, disk, or object storage.”
   • [claimed-docs] “Helix Cloud focuses on row-level isolation, which lets you implement any tenancy model at the application layer without structural constrain…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Qdrant—none0/10

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

   ⚑ flag

   HelixDB—none0/10

   HelixDB is a graph/vector/text database product; the evidence pack contains no statement about AI-training data usage policies, opt-out mechanisms, or data-use commitments regarding customer data. This is an applicable axis for any cloud-hosted data product (buyers can reasonably ask about data-training policy), but no evidence addresses it.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Qdrant
   Qdrant~partialclaimed5/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   No evidence pack items address data retention policies, deletion controls, TTL/expiry, or user-initiated data purge; documentation covers RBAC, multi-tenancy, and query features but nothing about retention/deletion controls for AI-native users.

   ⚑ flag

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

   weight 2 · round drawn
   Qdrant—none0/10

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

   ⚑ flag

   HelixDB—none0/10

   No evidence pack item mentions telemetry, usage analytics, or an opt-out setting for HelixDB; the docs cover open-source licensing, security, and MCP but not data collection practices. missing for 10: any mention of telemetry collection, opt-out flags/env vars, or privacy policy addressing usage tracking.

   ⚑ flag

Integrations

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

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

   HelixDB—none0/10

   The evidence pack shows HelixDB has SDKs for Rust/TS/Go/Python and an MCP server, but there is no mention of any maintained LangChain, LlamaIndex, or other RAG/agent-framework integration. Community feedback even highlights the custom HelixQL query language as a barrier to easy AI-framework tooling, reinforcing the absence of first-class integrations.

   • [claimed-docs] “HelixDB v3 uses one operation-tree request model across the Rust, TypeScript, Go, and Python SDKs.”
   • [community] “At the moment I wouldn't consider HelixDB because of HelixQL. With OpenCypher even older cheap models can generate queries... by creating He…”
   • [community] “Can I run this as an embedded DB like sqlite? Can I sidestep the DSL? I want my LLMs to generate queries and using a new language is going t…”
   • [community] “This is very cool, and right up my alley. Hesitant to try it out because of the bespoke query language for now.”

   proof ↗⚑ flag

Sdks

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

   weight 2 · round to Qdrant
   Qdrant✓fullcommunity8/10

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

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

   proof ↗⚑ flag

   HelixDB~partialclaimed5/10

   Docs explicitly state a single operation-tree request model spanning Rust, TypeScript, Go, and Python SDKs, covering three of the four named languages plus Rust instead of Java. No evidence of a Java SDK exists in the pack. missing for 10: Java SDK, independent/hands-on corroboration of SDK quality across languages, deeper per-language SDK docs.

   • [claimed-docs] “HelixDB v3 uses one operation-tree request model across the Rust, TypeScript, Go, and Python SDKs.”

   proof ↗⚑ flag

Core search

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

   weight 3 · round to Qdrant
   Qdrant✓fullcommunity9/10

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

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

   proof ↗⚑ flag

   HelixDB✓fullprobed8/10

   Docs explicitly describe vector indexes ranking node/edge embeddings by distance, requiring a non-zero dimension and a distance metric, plus approximate vector search confirmed in the llms.txt probe. This directly matches the ANN + configurable distance metric story, and it's combined with graph filtering for hybrid search. Missing for 10: no independent benchmark or hands-on confirmation of ANN recall/performance, and no enumeration of which specific distance metrics (cosine, L2, dot) are supported.

   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.helix-db.com/llms.txt # HelixDB > HelixDB combines a property graph, approximate vector search, an…”
   • [claimed-docs] “traverse and filter an exact candidate set before vector ranking, so results cannot escape graph or permission boundaries.”

   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 HelixDB
   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

   HelixDB✓fullprobed8/10

   Docs explicitly describe durable BM25 text indexes over string properties on nodes/edges as a native feature, confirmed by llms.txt describing BM25 full-text search as a first-class part of the engine alongside graph and vector search — no separate search engine needed. Missing for 10: independent hands-on benchmarks or community confirmation of full-text search quality/performance in practice.

   • [claimed-docs] “Text indexes provide durable BM25 search over string properties on nodes or edges.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.helix-db.com/llms.txt # HelixDB > HelixDB combines a property graph, approximate vector search, an…”
   • [claimed-docs] “Search and filtering on both nodes and edges, not just nodes.”

   proof ↗⚑ flag

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

   weight 3 · round to Qdrant
   Qdrant✓fullclaimed8/10

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

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

   proof ↗⚑ flag

   HelixDB~partialprobed5/10

   HelixDB documents separate vector indexes (distance-based ranking) and BM25 text indexes, and describes a unified operation-tree model that 'combines a property graph, approximate vector search, and BM25 full-text search' in one query engine, implying they can be used together. However, there is no explicit documentation of a fusion-ranking mechanism (e.g., weighted score combination or reciprocal rank fusion) that merges BM25 and vector scores into a single ranked result set within one query. Missing for 10: explicit fusion-ranking algorithm/API, a worked example combining BM25 and vector scores in one query, and independent confirmation of hybrid ranking quality.

   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [claimed-docs] “Text indexes provide durable BM25 search over string properties on nodes or edges.”
   • [claimed-docs] “traverse and filter an exact candidate set before vector ranking, so results cannot escape graph or permission boundaries.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.helix-db.com/llms.txt # HelixDB > HelixDB combines a property graph, approximate vector search, an…”

   proof ↗⚑ flag

Reranking

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

   weight 2 · round drawn
   Qdrant—none0/10

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

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

   proof ↗⚑ flag

   HelixDB—none0/10

   HelixDB documents vector, BM25 text, and hybrid graph-filtered vector search, but there is no evidence of built-in or first-party-integrated reranking models (e.g., cross-encoder rerankers) applied to search results; the pack only covers indexing and candidate retrieval, not a reranking stage.

   • [claimed-docs] “Vector indexes rank node or edge embeddings by distance. Every definition requires a non-zero dimension and a distance metric.”
   • [claimed-docs] “Text indexes provide durable BM25 search over string properties on nodes or edges.”
   • [claimed-docs] “traverse and filter an exact candidate set before vector ranking, so results cannot escape graph or permission boundaries.”

   proof ↗⚑ flag