Weaviate launched Weaviate Database 1.39 on August 4, 2026, then published its detailed overview on August 27. The weaviate release promotes the Boost API and Maximal Marginal Relevance (MMR) diversity selection to general availability, previews 4-bit Rotational Quantization, and introduces experimental REST search for simpler HTTP access to vector and hybrid retrieval.
The Weaviate release date therefore has two useful markers: the 1.39.x line first became available on August 4, while the company explained its headline features on August 27. The software is available through the open-source repository and Weaviate Cloud, although the company cautions that preview or configuration-dependent features may follow a different schedule on managed clusters.
What changed in the Weaviate release 1.39?
This Weaviate release changes both result ranking and the infrastructure beneath it. Boost is now a supported query-time rescoring layer: it evaluates up to 20 conditions after the primary search, then blends those scores with the original relevance order. MMR is also generally available and can diversify hybrid and near_* results before the final page is returned. For storage, preview-stage RQ4 encodes each rotated vector dimension with 4 bits rather than a 32-bit float. Weaviate's worked 1,536-dimension example occupies 784 bytes per vector, including its 16-byte header, versus 6,144 bytes for raw float32 data. The experimental REST interface addresses another gap by accepting JSON over HTTP/1.1. Together, these additions target three practical constraints in retrieval systems: repetitive answers, memory-heavy vector indexes, and client environments where generated gRPC libraries or GraphQL strings add unwanted complexity. They do not, however, share the same maturity level.
How do Boost and MMR change result quality?
Boost adjusts ranking without acting as a filter
The official Weaviate release overview describes Boost as a rescorer that runs after the primary query fetches candidates. It supports four condition types: filter, property_value, time_decay, and numeric_decay. An outer weight blends the boost score with the original relevance score; the documented default is 0.5. Each condition has its own weight, which can be negative to demote a match.
In this Weaviate release, Boost accepts between 1 and 20 conditions. Its candidate depth defaults to 100 and is capped by QUERY_MAXIMUM_RESULTS; operators can change the cluster default with QUERY_BOOST_DEFAULT_DEPTH. It works across hybrid, bm25, near_text, near_vector, near_object, near_media, and near_image in both query and generate namespaces. It does not apply to fetch_objects, which has no relevance score. If Boost and a reranker are combined, the reranker runs last. The Boost configuration guide is therefore essential before teams stack both mechanisms.
MMR reduces duplicate-looking results
The Weaviate release moves MMR into general availability. MMR selects results one at a time by balancing query relevance against similarity to items already selected. Its balance value runs from 0.0 to 1.0: 1.0 preserves pure relevance, while 0.0 maximizes diversity. The documented default is 0.0, so omitting it can produce a much broader page than expected. Teams should set the value explicitly and evaluate retrieval quality on their own corpus.
The feature runs after hybrid candidates are merged but before a reranker. Its MMR limit sets the returned page size and cannot exceed the parent query limit, which defines the candidate pool. Hybrid MMR requires Python client 4.23.0 or newer. It is unavailable for BM25-only searches because there are no vectors for measuring distance, and it does not support multi-vector collections. This focus on inspectable retrieval behavior also appears in BriefFlash's coverage of OpenSearch agentic observability, where verifying how a system reached an answer matters as much as the answer itself.
What does 4-bit Rotational Quantization trade off?
4-bit Rotational Quantization, or RQ4, first rotates vector values so they are distributed more evenly, then encodes each dimension with a compact integer code. Weaviate calculates storage as 16 + ceil(outputDim / 2) bytes, where outputDim = 64 * ceil(inputDim / 64). A 1,536-dimension vector therefore uses 784 bytes rather than 6,144 bytes of raw float32, a 7.84-fold reduction. Dimensions that are not multiples of 64 are rounded upward; a 1,000-dimension input is encoded at an output dimension of 1,024. RQ4 is preview-only and works on HNSW indexes, including cosine, dot, and L2-squared distance metrics. It is not accepted by flat indexes or the flat side of a dynamic index. The bit width becomes fixed when RQ is first enabled, with no documented migration from 8-bit to 4-bit codes, so production teams should benchmark recall, rescoring latency, memory, and rebuild strategy before committing a collection schema.
The Weaviate release exposes RQ4 through the cluster-wide setting DEFAULT_QUANTIZATION=rq-4, which makes it the default for new HNSW vector indexes. Weaviate says that configuration uses a rescoreLimit of 20. Because quantization exchanges numerical precision for compact storage and faster memory access, the preview should be treated as an engineering experiment, not an automatic upgrade. Our related report on 4-bit quantization-aware healing shows why the term “4-bit” alone does not predict quality: the compression method, evaluation set, and recovery or rescoring stage all affect the result.
How does the experimental Search REST API work?
Weaviate positions REST search between its existing gRPC and GraphQL options. gRPC offers a typed, high-performance path but needs HTTP/2 and generated client code. GraphQL works broadly but requires query-string construction and uses _additional for metadata. The new REST interface accepts camelCase JSON over HTTP/1.1 and returns a common {results, tookMs} envelope, which suits shell scripts, serverless functions, edge workers, API gateways, and documented tool calls.
The Weaviate release version 1.39.0 introduced POST /v1/search/{collection}/near-text. Patch 1.39.1 added BM25, hybrid, near-object, and aggregate routes, producing five endpoints in total. They are off by default and require EXPERIMENTAL_REST_SEARCH_ENABLED on each node. When disabled, the routes return HTTP 422 with configuration guidance rather than HTTP 404. The request and response shapes are not frozen, no official Weaviate client wraps them yet, and Boost, MMR, reranking, generative search, and group-by are unavailable through this REST layer. Those constraints matter for enterprise agent deployments already struggling with data and governance readiness.
What else should operators review?
The weaviate release also makes HNSW snapshots automatic and generally available. Weaviate now refreshes a compact graph snapshot in the background and deletes commit logs covered by a safely written snapshot. That should reduce long-term disk use and make restart time steadier. Disk usage can temporarily rise while the new snapshot is written, and inactive tenant shards retain old files until loaded. Five former snapshot environment variables are now ignored, while PERSISTENCE_HNSW_MAX_LOG_SIZE remains active with a documented default of 500 MiB.
The Weaviate release notes also cover the /v1/grpc-web/ path on the REST port, which has been enabled by default since version 1.38.3; lower latency histogram buckets down to 100 microseconds; BM25 path work; cross-property keyword AND; async-replication fixes; HFresh memory and disk improvements; and more reliable backup and replica-movement behavior. The GitHub 1.39.0 release notes contain the full engineering change list. As of August 27, GitHub identifies version 1.39.2 as the latest 1.39 patch.
Should teams upgrade immediately?
This Weaviate release gives teams already using Boost or MMR previews a clearer production-support signal, but they should still test query ordering against stored relevance judgments. RQ4 and REST search remain preview or experimental features, so isolate them behind configuration, record schema choices, and avoid depending on an unversioned response shape.
For this Weaviate release, self-hosted operators should move one minor version at a time, confirm client compatibility, preserve temporary disk headroom for snapshot creation, and deploy the latest stable patch in the 1.39 line rather than pinning to 1.39.0. Weaviate's release support policy covers the latest three minor versions and recommends the newest stable patch for the chosen minor release.
Key Takeaways
- Boost and MMR are now generally available, but they solve different problems: Boost changes business-aware ranking, while MMR reduces repetition.
- Preview-stage RQ4 stores a 1,536-dimension vector in 784 bytes versus 6,144 bytes for raw float32, but it is limited to HNSW and its bit width cannot be changed later.
- REST search remains experimental and off by default; version 1.39.1 or newer exposes five JSON endpoints, with no official client wrapper yet.
- Automatic HNSW snapshots remove covered commit logs, but operators still need temporary disk headroom during snapshot creation and should test upgrades on the latest patch.
FAQ
What is the Weaviate 1.39 release date?
Weaviate's release table lists August 4, 2026, as the first release date for the 1.39.x line. The company published its detailed Weaviate 1.39 feature overview on August 27, 2026.
Is 4-bit Rotational Quantization production-ready in Weaviate 1.39?
No. Weaviate labels 4-bit Rotational Quantization as a preview feature. It supports HNSW indexes, not flat indexes, and its behavior or defaults may change in a future release.
How do I enable the Weaviate Search REST API?
Set EXPERIMENTAL_REST_SEARCH_ENABLED to a supported truthy value on every Weaviate node. The interface is off by default, remains experimental, and has five endpoints on version 1.39.1 or newer.
