Qdrant 1.19.2 Speeds Sparse-Vector Upserts, Fixes Zero-Result Filtered HNSW Searches and Adds GCS and Azure Snapshot Storage
Qdrant's v1.19.2 release notes list faster sparse-vector upserts, a fix for filtered HNSW searches returning no results, GCS and Azure Blob snapshot support, and two security changes.
Overview
The Qdrant vector database project published version 1.19.2 on October 5, 2026, according to its GitHub release page. The change log is split into Improvements, Bug Fixes and Security sections. Its headline items are a faster path for sparse-vector upserts, a fix for filtered searches over HNSW indexes that could return nothing, and snapshot support for two more object stores. It follows v1.19.1, which the project’s page dates to September 4, and v1.19.0, dated August 5.
What the Release Notes Say
Performance and operations
The notes for v1.19.2 say Qdrant will no longer “rewrite full sparse posting list on every upsert,” which the notes describe as “making sparse vector upserts significantly faster.” The notes give no benchmark figures for that change.
Other entries in the Improvements section of the v1.19.2 notes include:
- Proxy segments now persist their state, which the notes say “prevents WAL pinning and long recovery times on restart.”
- A fix so that HNSW index builds saturate all the threads assigned to them.
- Filter IDs are resolved once per search request, which the notes say improves performance.
- Support for GCS and Azure Blob Storage for collection snapshots, plus a configurable prefix for object-storage snapshots.
- The collections lock is no longer held during a Raft snapshot, which the notes say “previously blocked access to all collections.”
Bug fixes
The first item in the Bug Fixes section of the v1.19.2 notes addresses a filtering failure: “Fix zero search results when HNSW entry point does not satisfy filter.” The same section lists a fix for adding a named multivector to an indexed collection, which the notes say broke search, and a fix to the ordering of candidates for maximal marginal relevance (MMR) queries, described as “improving accuracy.”
Two storage-related entries concern crash and corruption risk. One prevents write tearing in all Gridstore storages, which the notes say “could previously corrupt storage.” Another fixes a mutable payload index that could not load after a torn write, “causing crash loop.” A further fix targets a stale snapshot transfer on a recovering peer, which the notes say was “breaking other peers.”
Security and configuration
The Security section of the release notes has two entries. The internal gRPC API will now accept only read-write API keys, and paths are no longer exposed in logs when a snapshot is uploaded without a collection configuration. Separately, the Improvements section adds a startup warning if no API keys are configured and allows the internal gRPC interface to be bound to a separate network interface. A bug fix also corrects the alt_api_key setting not being used in internal gRPC API calls.
Context: The 1.19 Line
The two earlier releases in the series focused on different areas. The v1.19.0 notes list “TurboQuant 4-bit as a datatype of primary vector storage,” described as storing only 4-bit quantized vectors to “spare disk space on original vectors,” along with a global quota API and a per-query IDF corpus for sparse vector search. The v1.19.1 notes list work to speed up and saturate memory bandwidth in quantized scoring with prefetching and a reworked, batched 4-bit TurboQuant SIMD implementation.
What We Don’t Know
- The release notes do not quantify how much faster sparse-vector upserts become, so the size of the gain is unreported.
- The notes do not say how many deployments were affected by the filtered-search or storage-corruption bugs, or which earlier versions first contained them.
- No independent benchmarks or third-party coverage of 1.19.2 were reviewed for this report; every detail above comes from the project’s own release pages.