Comparison
YDB-Qdrant vs standalone Qdrant
Last updated: June 6, 2026
YDB-Qdrant is a Qdrant-compatible layer for applications that already depend on YDB. Standalone or managed Qdrant is the right choice when vector search is a dedicated production workload and the team needs broader Qdrant API coverage, specialized indexing, and vector database operations.
Short answer
Choose YDB-Qdrant when the main value is YDB co-location and a focused Qdrant-compatible REST subset. Choose standalone Qdrant or managed Qdrant when full Qdrant behavior, ANN indexing, and dedicated vector database operations matter more than keeping vectors in YDB.
Comparison matrix
| Decision point | YDB-Qdrant | Standalone or managed Qdrant |
|---|---|---|
| Primary role | Qdrant-compatible REST layer over YDB. | Dedicated vector database and semantic search engine. |
| Storage | Collection metadata and points are stored in YDB-backed tables. | Qdrant controls its own vector database storage and indexing model. |
| Search | Exact top-k over YDB-backed data. | Purpose-built vector search with Qdrant indexing. |
| API coverage | Focused subset: collections, points, search, query, delete, and index compatibility calls. | Full Qdrant API surface and client ecosystem. |
| Operations | Reuses the YDB operational footprint where that is the existing platform boundary. | Operates as a separate vector database or managed vector service. |
| Agent readiness | Publishes OpenAPI, llms.txt, agent cards, SKILL.md, and a separate hosted Code Indexer MCP surface. | Use Qdrant-native docs, clients, and deployment patterns. |
Choose YDB-Qdrant when
- Your application already uses YDB as a primary database or operational platform.
- You need a Qdrant-compatible REST subset for collections, points, search, query, and delete operations.
- Exact top-k search is acceptable for the current workload.
- You want a self-hostable Node.js package and HTTP server.
- You are building IDE-agent memory, RAG prototypes, internal semantic search, or small-to-medium vector collections.
Choose standalone or managed Qdrant when
- You need full Qdrant API compatibility.
- You need specialized ANN indexing and vector-database performance tuning.
- You need advanced Qdrant features outside the current YDB-Qdrant REST subset.
- Vector search is a primary production workload with strict latency targets.
- A separate dedicated vector database is acceptable or preferred operationally.
Architecture difference
YDB-Qdrant stores collection metadata in qdr__collections, points in qdrant_all_points, and path lookups in qdrant_points_by_file. It keeps vectors and payloads close to YDB-backed application data. Standalone Qdrant operates as a dedicated vector database with its own storage, indexing, clustering, and operational controls.