Weaviate

Weaviate is an open-source vector database that stores data as objects alongside their vector embeddings, and retrieves them based on semantic similarity, keyword relevance, or a combination of both. Where most vector databases act as a pure storage and retrieval layer that expects you to handle embedding generation separately, Weaviate can do the embedding itself through built-in vectoriser modules that call your choice of embedding model at ingest time. The result is a database that handles more of the RAG (Retrieval-Augmented Generation) stack in one place: you send raw text, Weaviate embeds it, indexes it, and later retrieves and — optionally — synthesises answers from it using a connected LLM. It is available as an open-source self-hosted deployment or as Weaviate Cloud, a managed service.

How Weaviate works

Weaviate organises data into collections (previously called classes). Each collection defines a schema: the properties that objects in it have, the vectoriser that embeds them, and any generative module connected to it for answer synthesis.

The central flow for a RAG use case looks like this:

1. Ingest: You send objects (documents, records, chunks) to Weaviate. If a vectoriser module is configured, Weaviate calls the embedding model automatically and stores the resulting vector alongside the object. You can also send pre-generated vectors if you prefer to handle embedding externally.
2. Index: Weaviate builds an HNSW (Hierarchical Navigable Small World) graph over the vectors for approximate nearest-neighbour retrieval, alongside a BM25 inverted index for keyword search.
3. Retrieve: At query time, you send a natural language query. Weaviate embeds it (via the vectoriser) and searches the HNSW index for semantically similar objects. You can run a pure vector search, a pure keyword search, or a hybrid search that blends both scores — all in one query.
4. Generate: If a generative module is connected (OpenAI, Anthropic, Cohere, or others), Weaviate can pass the retrieved results to the LLM and return a synthesised answer rather than raw chunks. This is called generative search.

Multi-tenancy is a first-class feature: each tenant in a collection stores its data in a separate physical partition. Tenants can be active or inactive (off-loaded to cold storage to save cost), which matters when you have thousands of tenants but only a fraction active at once.

Weaviate 1.35 (December 2025) added Object TTL for automatic data expiration, zstd compression for lower storage costs, and AI Agents — Query, Transformation, and Personalization agents that let you interact with the database in plain language rather than writing queries manually.

What you can build with Weaviate

• Enterprise knowledge base: An internal search tool where employees query company documents, policies, and wikis in plain language. Weaviate’s hybrid search catches both semantic matches (“how do I submit expenses”) and exact phrase matches (policy document titles) in one pass.
• Multi-tenant SaaS search: A search feature for a B2B product where each customer’s data is isolated in its own Weaviate tenant. All customers share one cluster; the data remains partitioned and queries are scoped automatically.
• Customer support copilot: A system that retrieves relevant help articles from a Weaviate collection based on the customer’s question, passes them to an LLM, and returns a direct answer — reducing escalations without requiring support agents to search manually.
• Product recommendation engine: A catalogue where each product is stored with a text and image embedding. Queries match on both visual similarity and semantic product descriptions, with keyword filters applied for availability, price range, or category.
• Research paper discovery: An academic search tool that embeds abstracts and lets researchers find related work by example (upload a paper, find similar papers) or by concept (describe what you are looking for in plain language).
• Multimodal media search: A media library where images, video descriptions, and audio transcripts are indexed together. Users can search across all media types from a single text query, with each modality vectorised by the appropriate model.