Weaviate 1.40 Release

Weaviate v1.40 is now available open-source and on Weaviate Cloud. Two features reach general availability in this release: dropping a named vector, which frees the disk and index memory an unused vector was holding, and 4-bit Rotational Quantization. Two more are new: the HFresh index now takes multi-vector embeddings through MUVERA, and PathSeer joins ACORN and sweeping as a third filter strategy for HNSW. This post also catches up on the Search REST API, which changed a lot over the 1.39 patch line. It also covers a breaking change to vector configuration defaults to check before you upgrade. Here are the release highlights! Drop a named vector - General Availability 4-bit Rotational Quantization - General Availability Multi-vector embeddings on HFresh with MUVERA PathSeer filter strategy Search REST API (Preview) Vector configuration defaults (breaking change) Performance Improvements and Fixes Community Contributions Summary Breaking change If your server sets DEFAULT_VECTORIZER_MODULE, read Vector configuration defaults before you upgrade. Drop a named vector - General Availability​ Collections pick up vectors over time. You add a named vector to try a new embedding model, the new one wins, and the old one stays on every object, in every shard, taking up disk and index memory. Until now the only way out was to re-create the collection and re-import everything. v1.40 makes the drop vector index endpoint generally available. It has existed since v1.37 as an experimental feature that was off by default. In v1.40 it is on by default. A drop deletes the vector's index and removes its embedding from every object. The collection's other named vectors and all object data stay as they are. A drop cannot be undone To get the vector back, add it again and then re-vectorize or re-import your objects. How it works​ With the Python client (4.24.0 or newer), call delete_vector_index with the name of the vector: articles = client.collections.use("Article") articles.config.delete_vector_index("body_vector") Over REST it is one DELETE request: curl -X DELETE \ http://localhost:8080/v1/schema/Article/vectors/body_vector/index The call returns once Weaviate has accepted the drop. The cleanup itself runs in the background, shard by shard, and picks up where it left off after a restart. While the cleanup runs, the vector is still listed in the collection definition, and writes that target it are rejected. In a batch, only the objects that carry the dropped vector fail. The drop is finished when the vector disappears from the definition. A few more things to know: Permissions: You need update permission on the collection and on its data objects, because a drop rewrites every object. Inactive tenants: A tenant that is inactive holds up completion until it is activated and a later cleanup round reaches it. Reusing the name: Once the drop is finished you can add a vector with the same name again, even with a different dimensionality. The new index starts empty. The last vector: Dropping the only vector leaves a collection with no vectors. Objects and properties stay. The Python client is the first to wrap the endpoint. From any other language, send the REST request. Related resources How-to: Manage collections - Drop a named vector References: RESTful API - Schema 4-bit Rotational Quantization - General Availability​ 4-bit Rotational Quantization (RQ), a preview in v1.39, is now generally available. RQ rotates each vector, then stores every dimension as a small integer instead of a full float. The reason to turn it on is memory. On a million 1536-dimension vectors, 4-bit RQ used about 45% less memory than 8-bit RQ. A cluster of the same size holds more vectors, or you run a smaller one. Imports get faster too. Search quality holds up because Weaviate rescores the best candidates with the original vectors. How it works​ Many embedding models produce vectors that cluster around a point that is not zero. Centering, in Weaviate since v1.39.3, measures that point from a sample of your data and compresses relative to it. That brings 4-bit recall close to 8-bit. It is off by default because some models already do this. It only applies to 4-bit. Set rq.bits = 4 on an HNSW index. With Python client 4.23.1 or newer, turn on centering in the same call: from weaviate.classes.config import Configure client.collections.create( "Doc", vector_config=Configure.Vectors.self_provided( name="default", vector_index_config=Configure.VectorIndex.hnsw( quantizer=Configure.VectorIndex.Quantizer.rq(bits=4, centering=True), ), ), ) bits locks when RQ is first enabled on a vector, so pick the width before then. You can still enable RQ later on an uncompressed collection. Operators can set DEFAULT_QUANTIZATION=rq-4 to make 4-bit RQ the default for new HNSW indexes. Weaviate Cloud keeps 8-bit RQ as its default. 4-bit works on HNSW indexes only. The numbers and the engineering are in the 4-bit Rotational Quantization deep dive. Related resources Concepts: Vector quantization - Rotational quantization How-to: Compression - 4-bit RQ Blog: 4-bit Rotational Quantization Multi-vector embeddings on HFresh with MUVERA​ HFresh is Weaviate's disk-based vector index. It keeps a small index of centroids in memory and stores compressed vectors on disk, so it needs far less memory than HNSW. Until now it only took one vector per object. Late-interaction models such as ColBERT and ColPali produce a multi-vector embedding: one vector per token or image patch, instead of one vector per object. They rank well, but a page of text can turn into hundreds of vectors, which is the kind of data that strains memory. In v1.40, HFresh can index them. There is one condition. On HFresh, multi-vector embeddings need MUVERA encoding. MUVERA turns a set of vectors into a single fixed-length vector, so HFresh can search it like any other. How it works​ A multi-vector query on HFresh runs in three passes: searchProbe and rq.rescoreLimit, both set in the HFresh index config, control the first two passes. searchProbe sets how many posting lists are scanned. rq.rescoreLimit sets how many candidates survive the rescore. The survivors are then scored exactly against their original token vectors with MaxSim. MaxSim is the late-interaction score that matches each query token to its closest document token. To set it up, create a named vector with no vectorizer, MUVERA encoding, and an HFresh index: from weaviate.classes.config import Configure client.collections.create( "Page", vector_config=Configure.MultiVectors.self_provided( name="colbert", encoding=Configure.VectorIndex.MultiVector.Encoding.muvera(), vector_index_config=Configure.VectorIndex.hfresh(), ), ) The constraints: The vector needs "vectorizer": "none": You bring the token vectors yourself. MUVERA is required, and fixed at creation: multivector.muvera.enabled cannot be changed later. The encoding is always compressed with 1-bit RQ: PQ, SQ and BQ are rejected, and RQ cannot be turned off. multivector.enabled alone is not enough on HFresh If you set multivector.enabled without MUVERA, the collection is created, but it behaves as a regular vector without multi-vector support and rejects multi-vector imports and queries. Set multivector.muvera.enabled. Related resources Config references: Multi-vector embeddings on HFresh Concepts: Multi-vector embeddings on HFresh How-to: Multi-vector compression - MUVERA encoding Blog: HFresh, memory-efficient vector search PathSeer filter strategy​ A filtered vector search has to find the nearest objects that also pass a filter. On an HNSW index, the filterStrategy setting decides how the search walks the graph when many neighbors fail the filter. Until now you had two choices: acorn (the default) and sweeping. v1.40 adds a third, pathseer. It comes from the SIGMOD 2026 paper by Zhiyue Li et al., and the paper's first author, @lizhiyuell, contributed the implementation (#12137). In Weaviate's benchmarks PathSeer was the fastest strategy, or within a few percent of it, on random, topical and combined filters. ACORN stays ahead only on strongly negatively correlated filters, where the filter all but excludes the query's neighborhood. The PathSeer post has the full benchmarks and a walkthrough of the algorithm. How it works​ PathSeer walks the bottom layer of the graph like sweeping. While the result set is still filling, it also filter-checks the neighbors of each candidate's neighbors, like ACORN. Once the result set is full, it skips the non-matching neighbors of a non-matching candidate without computing their distance. It makes that call per node, so there is no new parameter to tune. It stores nothing extra. There is no import cost, no memory overhead, and you can switch an existing collection to it, or away from it, without reindexing. The flat-search cutoff still applies first: when a filter matches fewer objects than flatSearchCutoff, Weaviate scans those objects instead of walking the graph. To switch an existing named vector over: from weaviate.classes.config import Reconfigure, VectorFilterStrategy articles = client.collections.use("Article") articles.config.update( vector_config=Reconfigure.Vectors.update( name="default", vector_index_config=Reconfigure.VectorIndex.hnsw( filter_strategy=VectorFilterStrategy.PATHSEER, ), ) ) In a collection definition sent over REST, it is one field in the HNSW vectorIndexConfig: { "vectorIndexConfig": { "filterStrategy": "pathseer" } } Related resources Concepts: Filtering - PathSeer Blog: PathSeer, adaptive filtered vector search Search REST API (Preview)​ The Search REST API lets you search with plain JSON over HTTP/1.1, with no generated client and no GraphQL query strings. It arrived as an experimental, off-by-default feature in v1.39. A lot has changed since then. All of it shipped in 1.39 patches, and the API is now a preview. On by default from v1.