Weaviate AI Database

Smaller vectors. Faster imports. Almost no recall drama. Weaviate 1.39 adds 4-bit Rotational Quantization. It cuts memory usage while maintaining strong recall, with faster imports and search performance improvements across the RQ family. This blog covers the SIMD work behind it, how recall holds as datasets scale, and how RQ compares with TurboQuant. 8-bit RQ remains the default in Weaviate Cloud and now imports 16% faster. If reducing RAM usage and cost is the priority, 4-bit RQ is now available! Blog: https://weaviate.io/blog/4-bit-rotational-quantization?utm_source=linkedin&utm_medium=w_social&utm_campaign=RQ&utm_content=blog_annoucement_802531237

AI memory gets worse when you treat it as an ever-growing pile of chat history. Every turn adds more tokens, slower responses, and more outdated or contradictory information for the model to figure out at query time. People change their minds. Facts go stale. Eventually you have 50 memories about the same thing, all competing for space in the context window. @victorialslocum's new video explains how 𝗘𝗻𝗴𝗿𝗮𝗺 handles this differently. Raw messages are sent to Engram, then asynchronous pipelines: 1️⃣ Extract the facts that matter 2️⃣ Compare them with existing memories 3️⃣ Reconcile contradictions, duplicates, and updates 4️⃣ Store a relevant, pruned set of memories for retrieval Developers control extraction with 𝗧𝗼𝗽𝗶𝗰𝘀, which are plain-language descriptions of what matters to the application. Memories are also fully scoped: • 𝗣𝗿𝗼𝗷𝗲𝗰𝘁-𝘄𝗶𝗱𝗲 for memories shared across a team of humans or agents • 𝗨𝘀𝗲𝗿-𝘀𝗰𝗼𝗽𝗲𝗱 for memories isolated to an individual • 𝗨𝘀𝗲𝗿-𝗮𝗻𝗱-𝗽𝗿𝗼𝗽𝗲𝗿𝘁𝘆 𝘀𝗰𝗼𝗽𝗲𝗱 for combinations like `user_id` + `conversation_id` The video also walks through setting up a basic user-scoped memory project: choose the personalization template, use the default pipeline, create an API key, and manage memories and pipeline runs from the dashboard. Video: https://youtu.be/kX9IhyltvuQ More on Engram: https://weaviate.io/product/engram?utm_source=channels&utm_medium=w_social&utm_campaign=engram&utm_content=680216557 Demo: https://engram.playground.weaviate.io?utm_source=channels&utm_medium=w_social&utm_campaign=engram&utm_content=680216557

Not every search query needs maximum retrieval effort. Connor introduces the new query agent effort tiers in this video! 👇 Query Agent Search Mode now supports an effort parameter, so you can control how much work the agent puts into each request: • 𝗺𝗲𝗱𝗶𝘂𝗺 • 𝗵𝗶𝗴𝗵 • 𝘂𝗹𝘁𝗿𝗮𝗵𝗶𝗴𝗵 Higher effort scales computation in two places: 1️⃣ 𝗤𝘂𝗲𝗿𝘆 𝘄𝗿𝗶𝘁𝗶𝗻𝗴: the agent spends longer decomposing the request and translating it into structured searches 2️⃣ 𝗥𝗲𝗿𝗮𝗻𝗸𝗶𝗻𝗴: retrieved documents are evaluated more thoroughly before the final ranking is returned Test the tiers against your own accuracy, latency, and cost requirements - the right tier depends heavily on the workload! Read more in this blog: https://weaviate.io/blog/search-mode-effort?utm_source=channels&utm_medium=w_social&utm_campaign=query_agent&utm_content=680612748

Relevance is not the same thing as coverage. For the query "japan", standard vector search can return five highly relevant images that are also near-duplicates of each other. Hybrid search can hit the same problem when keyword and vector results converge on one dense cluster. MMR diversity selection reduces that repetition at query time. It selects results greedily, one at a time, balancing: • similarity to the query • similarity to results already selected With 𝗯𝗮𝗹𝗮𝗻𝗰𝗲=𝟭.𝟬, ranking stays focused on pure relevance. At `balance=0.5`, that first page can spread across Mount Fuji, a train, a monkey, ramen, and torii gates. MMR is now generally available in Weaviate 1.39 across every 𝗻𝗲𝗮𝗿_* search and hybrid search. It runs entirely at query time, so existing collections need no schema changes or reindexing. One important caveat: pass 𝗯𝗮𝗹𝗮𝗻𝗰𝗲 explicitly. Its default is 𝟬.𝟬, which prioritizes pure diversity and can wander surprisingly far from the query. Learn more: https://weaviate.io/blog/weaviate-1-39-release?utm_source=linkedin&utm_medium=w_social&utm_campaign=1.39_release&utm_content=honeypot_post_805687208#mmr-diversity-selection---general-availability

A slow query is easy to spot. Explaining 𝘸𝘩𝘺 it's slow is the hard part. The latency could come from HNSW traversal, resolving a filter, BM25 scoring, compression rescoring, or fetching objects from disk. Each points to a completely different fix. 𝗤𝘂𝗲𝗿𝘆 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 𝗶𝗻 𝗪𝗲𝗮𝘃𝗶𝗮𝘁𝗲 makes that breakdown available for each specific search. Set 𝗾𝘂𝗲𝗿𝘆_𝗽𝗿𝗼𝗳𝗶𝗹𝗲 in the request metadata and the profile is returned alongside the response, organized by shard and node. The coordinating node collects timings from every shard involved, so distributed queries no longer require manually piecing together logs from multiple nodes. Consider a shard that takes 48.2ms: • Vector search: 8.4ms • Filter resolution: 2.1ms • Object hydration: 36.8ms HNSW isn't the bottleneck here. Object hydration is. Blindly increasing compute would miss the problem entirely. Page-cache misses, storage latency, a large result limit, or oversized objects are the more useful places to investigate. 𝗤𝘂𝗲𝗿𝘆 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 is generally available in Weaviate v1.38. Learn more about it in our blog: https://weaviate.io/blog/query-profiling?utm_source=channels&utm_medium=w_social&utm_campaign=blog_post&utm_content=diagram_post_805454162

Your agent remembers. But does it remember well? Getting memory running takes a few API calls. Making sure it remembers the right things takes a little more thought. Our new guide walks through four decisions that shape how Engram works in your setup: • what gets remembered • how memories are scoped and updated • which retrieval mode to read them back • where they belong in the prompt It uses real outputs and test runs to show what changes when you adjust each one, from filtering out passing noise to keeping dynamic memory from breaking prompt caching. Read the full guide: https://weaviate.io/blog/engram-memory-practical-guide?utm_source=linkedin&utm_medium=w_social&utm_campaign=engram&utm_content=blog_annoucement_808076097

Weaviate `v1.39.3` includes a fix for a high-severity credential disclosure vulnerability affecting Weaviate's Google-backed modules. The vulnerability affects `text2vec-google`, `multi2vec-google`, and `generative-google`, where an unvalidated `apiEndpoint` setting could cause Google credentials to be sent to an unintended host. Users running impacted versions of Weaviate (`< v1.39.3`) should upgrade to `v1.39.3` or later. Weaviate Cloud and Marketplace customers have already been patched and we have no indication that the vulnerability has been exploited. Thank you to Syed Anas Mohiuddin for responsibly reporting the issue through our Vulnerability Disclosure Program. Full details: https://weaviate.io/blog/weaviate-security-release-googlemodules-2026?utm_source=x&utm_medium=w_social&utm_campaign=security&utm_content=blog_announcement_807950336

How much compute should a single search get? Every retrieval app has to balance quality, latency, and cost. The problem is that not every request needs the same amount of compute. A support lookup may be straightforward, while an 800-token multi-step research question may need much more work. Configure everything for the hardest query and you overpay for the easy ones. Optimize only for speed and the difficult queries may fall apart. Weaviate's Query Agent now gives developers control over this tradeoff with an 𝗲𝗳𝗳𝗼𝗿𝘁 parameter in Search Mode. For each request, you explicitly choose `medium`, `high`, or `ultrahigh`. Weaviate's Query Agent now has an 𝗲𝗳𝗳𝗼𝗿𝘁 parameter in Search Mode, so you pick per request: `medium`, `high`, or `ultrahigh`. response = qa. search("What are Listwise Rerankers?", effort="ultrahigh") The 𝗲𝗳𝗳𝗼𝗿𝘁 setting controls how much work Search Mode puts into refining the results from the initial agentic search. Higher effort can improve retrieval accuracy, with additional latency and cost. With this, you're not hand-authoring query decomposition logic, you're not maintaining two retrieval stacks, and you're not paying maximum compute on every trivial lookup. Query Agent also knows your schema, so "find me some vintage shoes under $70" becomes a hard price filter plus semantic search, without you parsing that yourself. The benchmarks in our blog show why this control matters. On BRIGHT Biology, recall improves from roughly 𝟰𝟯% 𝗮𝘁 𝗺𝗲𝗱𝗶𝘂𝗺 𝗲𝗳𝗳𝗼𝗿𝘁, 𝘁𝗼 𝟱𝟬% 𝗮𝘁 𝗵𝗶𝗴𝗵, 𝗮𝗻𝗱 𝟱𝟳% 𝗮𝘁 𝘂𝗹𝘁𝗿𝗮𝗵𝗶𝗴𝗵. The gains vary by dataset, but the general pattern is that harder, reasoning-heavy searches benefit more from additional effort. Read more in our docs: https://weaviate.io/blog/search-mode-effort?utm_source=channels&utm_medium=w_social&utm_campaign=query_agent&utm_content=808276882

Your CLAUDE.md tells Claude how to work on a project. It doesn't tell Claude what you actually did there. The feature you added last week. The approach you chose after trying two others. The library you rejected, and why. That history matters, but Claude Code's notes stay attached to the repo where they were written. Switch repos and the next session starts cold. We built the 𝗘𝗻𝗴𝗿𝗮𝗺 𝗽𝗹𝘂𝗴𝗶𝗻 𝗳𝗼𝗿 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 to give Claude long-term memory across sessions, codebases, and teams. Before each answer, it recalls short, relevant memories. Afterward, it saves the exchange asynchronously and extracts what is worth keeping. There is no "remember this" command. Memory becomes a side effect of normal work. Read the blog to see how it works and get started: https://weaviate.io/blog/engram-for-claude-code?utm_source=linkedin&utm_medium=organic_social&utm_campaign=engram_for_claude_code&utm_content=launch_post

Join Connor Shorten, Ivan Despot, and Alexander Ledbetter for a live look inside Weaviate's MCP Ecosystem! 📅 October 14, 2026 | 17:00–18:00 CEST See the Weaviate Database and Weaviate Query Agent MCP servers in action, and hear how Delegance Brokerage built their own MCP server on top of Weaviate. Save your spot 👇 https://weaviate.io/webinars/inside-weaviate-mcp-ecosystem?utm_source=linkedin&utm_medium=organic_social&utm_campaign=inside_weaviate_mcp_ecosystem_webinar&utm_content=speakers_post

There is no "best" embedding model. There's only the best one for your data, your task, and your latency budget. If you're still wondering which one to chose, Victoria made a video breaking it down. The short version: 𝗦𝘁𝗮𝗿𝘁 𝘄𝗶𝘁𝗵 𝘆𝗼𝘂𝗿 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝗹𝗲𝗮𝗱𝗲𝗿𝗯𝗼𝗮𝗿𝗱. The questions that matter: • Domain: legal, medical, e-commerce? Specialized models understand the terminology and what matters in it better • Modality and language: text-only, images, multilingual? • Task: a model that's strong at retrieval can behave very differently from one tuned for summarization • Size: bigger models capture more nuance but cost you latency and memory, and can overfit on top of that 𝗧𝗵𝗲𝗻 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗲 𝗼𝗻 𝘆𝗼𝘂𝗿 𝗼𝘄𝗻 𝗱𝗮𝘁𝗮. The MTEB leaderboard is a solid starting point for picking a baseline, but scores are self-reported and benchmark data may look nothing like yours (it may even be in the training data). You don't need much to start - 50 to 100 hand-labeled objects and a few queries with defined relevance judgments. In the blog post's example comparing OpenAI's small and large embedding models on a tiny pastry dataset, the two models tied on average precision and recall (0.5 and 0.58)... while taking turns beating each other on individual queries. Bigger wasn't better. It was just different. 𝗧𝗵𝗲𝗻 𝘁𝗵𝗲𝗿𝗲'𝘀 𝘁𝗵𝗲 𝗼𝗽𝗲𝗿𝗮𝘁𝗶𝗼𝗻𝗮𝗹 𝘀𝗶𝗱𝗲. Closed APIs mean rate limits and one more vendor to manage. Self-hosting open-source models means GPUs and maintenance. Weaviate Embeddings removes all this work: models hosted next to your data, no external API calls, no artificial limits on how fast you can embed, and pay-as-you-go pricing. Pick a small baseline, benchmark it on your own data, iterate from there. Video: https://www.youtube.com/watch?v=djp4205tHGU Blog: https://weaviate.io/blog/how-to-choose-an-embedding-model?utm_source=channels&utm_medium=w_social&utm_campaign=embeddings&utm_content=680073257 Weaviate Embeddings: https://weaviate.io/product/embeddings?utm_source=channels&utm_medium=w_social&utm_campaign=embeddings&utm_content=680073257

Why are you storing your images twice? If you're building multimodal search, you've probably seen this: your images, audio, or video live in S3, that's your source of truth. But to vectorize them, you send the raw bytes into your vector database... and then they just sit there. Same file, two places, two bills. You can easily fix this with the 𝗯𝗹𝗼𝗯𝗛𝗮𝘀𝗵 property type. You send the media in exactly the same way you always have, the vectorizer embeds the real content, and once that's done, Weaviate keeps a SHA-256 hash instead of the full payload. The vector and the searchable representation stay with Weaviate. The actual asset stays in object storage where it belongs. - No duplicated media sitting in your database eating disk - A clean split between your vector layer and your system of record - Weaviate compares hashes on update, so you only re-vectorize when the content actually changed No more guessing whether that image was modified, no more re-embedding thousands of files "just in case." Learn more in the blog: https://weaviate.io/blog/weaviate-1-37-release#blobhash-property-type?utm_source=channels&utm_medium=w_social&utm_campaign=1.37_release&utm_content=800980983