Qdrant 1.13 joined GPU indexing with collection-level operational limits
Qdrant released version 1.13 on January 23, 2025, adding GPU-accelerated HNSW indexing, strict-mode controls and a new storage engine.
Historical reporting: Qdrant’s dated 1.13 post announces GPU-accelerated HNSW indexing, strict mode, HNSW graph compression and a new storage engine on January 23, 2025. The public repository provides release and implementation context. Qdrant’s benchmark and architecture claims belong to its supplied hardware, datasets and settings; they do not show a fixed speedup or retrieval-quality result for another collection.
Key takeaways
- GPU indexing targeted index construction, a separate concern from query-time retrieval quality.
- Strict mode made collection limits an explicit configuration surface.
- Compression and storage changes require testing with a workload’s own vectors, filters and update rate.
Qdrant released version 1.13 on January 23, 2025[source 1]
Qdrant’s January 23, 2025 release post presents version 1.13 as a combined indexing, storage and operations update. Its named changes include GPU-accelerated HNSW indexing, strict mode, HNSW graph compression, named-vector filtering and a new storage engine. This is more substantive than a patch-level correction because it changes where index construction can run and exposes new controls over collection operations. The release date and feature list establish the event. They do not establish that a database using earlier versions automatically adopted the new paths, or that a retrieval application became more accurate, cheaper or safer without measurement in its own configuration.
GPU acceleration was presented for HNSW index construction[source 1][source 2]
The post describes GPU-accelerated indexing for HNSW, the approximate-nearest-neighbor graph used by many vector workloads. Index construction and query serving are related but separate measurements. A faster build can reduce ingestion delay without determining recall, filtered-query latency, memory usage or behavior under concurrent writes. Qdrant’s release includes vendor benchmarks and hardware examples to demonstrate its implementation; those results depend on the vectors, graph parameters, GPU, CPU, storage and ingestion process chosen for the test. Teams evaluating the feature need a representative corpus and update pattern, then should record build time and retrieval quality together rather than treating a hardware claim as a complete application result.
Strict mode exposed collection operation limits as a configured control[source 1][source 2]
Qdrant describes strict mode as a way to enforce restrictions on a collection. That makes operational boundaries visible in the database configuration instead of leaving every client to impose its own limits. The exact utility depends on which limits a deployment enables and how clients react to rejection, throttling or resource pressure. A collection with a strict-mode setting still needs identity, authorization, monitoring and recovery behavior outside the setting. The release is meaningful because it lets an operator put some guardrails adjacent to the collection that receives writes and searches. It does not convert an application policy into a database fact or prove that an untrusted caller cannot reach another access path.
Compression and a new storage engine made resource tradeoffs part of the release[source 1][source 2]
Version 1.13 also introduced HNSW graph compression and a new storage architecture, according to Qdrant. Those changes make a familiar retrieval tradeoff concrete: memory, disk I/O, indexing time and query behavior can move together. Compression is not a generic free gain because its effect depends on vector dimensions, quantization, filters, graph settings and the hardware that serves the collection. A meaningful before-and-after record should hold the corpus, queries, relevant metrics and resource limits fixed. The project’s code and release history allow implementation inspection, but they are not proof that an organization’s production collection has the same segment layout, workload or result quality as Qdrant’s tests.
Sources
- Qdrant: 1.13 release (January 23, 2025)
- Qdrant public repository releases
Continue reading
Related reading
News analysisQdrant Cloud Inference put embedding generation, storage and indexing behind one API call3 min read
News analysisMilvus 2.6 made storage format and cost controls part of billion-scale retrieval claims3 min read
News analysisPinecone made Assistant generally available with chat, context and document-format additions3 min read