# Weaviate

Weaviate is an open-source vector database with built-in hybrid search, vectorizer modules and multi-tenancy. Learn how it stores, filters and searches embeddings.

## Overview

Weaviate is an open-source vector database. It stores objects, such as documents, products or support tickets, together with their [embeddings](/tools/embeddings), and lets you search them by meaning, by keywords, by structured filters, or by a mix of all three. It is written in Go, released under the BSD-3-Clause licence, and developed by Weaviate B.V., a company based in Amsterdam. You can run it yourself with Docker or [Kubernetes](/tools/kubernetes), embed it for testing, or use the company's managed cloud service.

What sets Weaviate apart is how much it does inside the database. It can call embedding models for you through modules, so you can insert plain text and let Weaviate create vectors. It has [hybrid search](/tools/hybrid-search) built in, combining vector similarity with [BM25](/tools/bm25) keyword scoring in one query. It supports multi-tenancy for applications that serve many separate customers, plus replication, compression and role-based access control.

Think of a well-run library with a very good librarian. You can ask for "books like this one", for "anything with the word 'tariff' in the title", or for "economics books published after 2020 that feel like this one", and the librarian handles all three in one go. Weaviate aims to be that librarian for your data.

## What it is

| Part | What it does |
|---|---|
| Collection | A named group of objects with a defined set of properties, similar to a table |
| Object | One stored item with properties and one or more vectors |
| Vector index | Fast nearest-neighbour search, by default [HNSW](/tools/hnsw); a flat index is also available |
| Inverted index | Supports keyword search and property filters |
| Modules | Plug-ins for vectorisers, rerankers and generative models from many providers |
| Named vectors | Several vectors per object, for example one for title and one for body |
| Tenants | Isolated partitions of a collection for multi-tenant applications |
| APIs | REST, gRPC and GraphQL, with clients for Python, TypeScript, Go, Java and C# |

## Where it came from

Bob van Luijt started Weaviate as an open-source project in 2016. In 2019 he co-founded a company around it, then called SeMI Technologies, with Etienne Dilocker; the company later rebranded as Weaviate. Version 1.0 was released in January 2021 and introduced the modular design that lets Weaviate plug in different vectoriser and generative models.

Over the following releases the project added features that became central to modern retrieval. Replication and hybrid search arrived around the end of 2022. Multi-tenancy and reranker modules followed in 2023. Named vectors, allowing several vectors per object, arrived in 2024. Vector compression options grew to include product quantisation, scalar quantisation, binary quantisation and, in 2025, rotational quantisation. Weaviate also offers a managed service, Weaviate Cloud, and has added agent-style services, such as a query agent, on top of the database. For the current feature set, always check the official documentation, since releases are frequent.

## How it works

### Step 1: Define a collection

You create a collection with properties, such as title, body, date and category, and choose how vectors are produced. You can bring your own vectors, or configure a vectoriser module so Weaviate calls an embedding model when you insert data.

### Step 2: Import objects

You add objects in batches. Weaviate stores the properties, builds an inverted index for text and filters, and inserts each vector into the vector index. Data is written to a log first so it survives restarts.

### Step 3: Index vectors

By default each vector goes into an HNSW graph, which links each vector to near neighbours across several layers so search can hop quickly towards the closest matches. For small collections, such as per-tenant data, a flat index that compares against every vector can be cheaper. A dynamic option starts flat and switches to HNSW as a collection grows.

### Step 4: Compress if needed

Vectors can be compressed so more fit in memory. Compression trades a little accuracy for large memory savings, and Weaviate can rescore top results with full vectors to recover accuracy.

### Step 5: Query

Weaviate supports several query types:

- Vector search: nearest neighbours to a query vector or text.
- Keyword search: BM25 over text properties.
- Hybrid search: runs both and fuses the results. The alpha parameter sets the balance, where 1 is pure vector and 0 is pure keyword.
- Filters: conditions on properties, such as date or category, applied during search.
- Generative search: retrieved objects are passed to a language model module to produce an answer, a built-in form of RAG.

A short example with the Python client:

```python
import weaviate

client = weaviate.connect_to_local()
articles = client.collections.get("Article")
result = articles.query.hybrid(query="refund policy for damaged items", alpha=0.5, limit=5)
for obj in result.objects:
    print(obj.properties["title"])
client.close()
```

### Step 6: Scale and isolate

Collections are split into shards that can be spread across nodes and replicated. With multi-tenancy, each tenant gets its own shard, so data is isolated and inactive tenants can be moved to cheaper storage.

## Key concepts and terms

| Term | Meaning |
|---|---|
| Vectoriser module | A plug-in that calls an embedding model during import and query |
| Hybrid search | One query combining vector and keyword results |
| Alpha | The weight between vector and keyword scores in hybrid search |
| Fusion | How two ranked lists are merged into one |
| HNSW | A graph index for approximate nearest-neighbour search |
| Flat index | Exhaustive comparison against all vectors |
| Named vectors | Several separately indexed vectors on one object |
| Multi-tenancy | Isolated data partitions per customer within one collection |
| Quantisation | Storing vectors in compressed form to save memory |
| Generative search | Retrieval followed by a language model answer inside the query |

## A worked example

An illustrative software company runs a help assistant for 800 business customers. Each customer has its own documents, between a few hundred and 50,000 chunks.

1. The team creates one collection, HelpChunk, with properties text, title, product and updated_at, and enables multi-tenancy. Each customer becomes a tenant.
2. They configure a vectoriser module for an embedding model with 1,024 dimensions. In total there are about 6 million chunks.
3. Uncompressed, 6 million vectors of 1,024 float32 values need about 24.6 GB for vectors alone. With 8-bit compression this drops to about a quarter.
4. Small tenants use a flat index; large ones use HNSW.
5. A user query runs as a hybrid search with alpha 0.6, filtered by product and limited to the user's tenant. It returns 20 chunks in tens of milliseconds.
6. A reranker module reorders the 20 and the top 5 go to a language model for the answer.
7. On a labelled set of 400 questions, hybrid search finds a correct chunk in the top 5 for about 88 per cent of queries, against about 79 per cent for vector search alone, in this example.

The numbers are illustrative, but the design, tenants for isolation, hybrid queries, compression and reranking, reflects typical Weaviate use.

## Strengths and limitations

**Strengths:**

- Built-in hybrid search with configurable fusion.
- Modules for many embedding, reranking and generative providers.
- Native multi-tenancy with per-tenant isolation.
- Several compression options and index types.
- Open source with self-hosted and managed options.
- Rich filtering and multiple vectors per object.

**Limitations:**

- Running a cluster well needs operational knowledge of memory, shards and replication.
- HNSW indexes are memory-hungry without compression.
- Module-based vectorisation ties import speed to external model APIs.
- Not a general relational database; complex joins and transactions belong elsewhere.
- Frequent releases mean configuration advice can date quickly.

## How it compares with alternatives

| System | Type | Notable strengths | Consider when |
|---|---|---|---|
| Weaviate | Open-source vector database (Go) | Hybrid search, modules, multi-tenancy | You want search features built in |
| [Qdrant](/tools/qdrant) | Open-source vector engine (Rust) | Payload filtering, quantisation, sparse vectors | Filtering-heavy, performance-focused workloads |
| [Milvus](/tools/milvus) | Open-source distributed vector database | Many index types, very large scale | Billions of vectors, separate compute and storage |
| [pgvector](/tools/pgvector) | PostgreSQL extension | Vectors beside relational data | You already run Postgres at moderate scale |
| [Pinecone](/tools/pinecone) | Managed service | Fully managed, serverless | You want no infrastructure to run |

## Practical guidance and best practices

1. Decide early whether you bring your own vectors or use a vectoriser module, and record the model name and version.
2. Use multi-tenancy rather than one collection per customer when you serve many tenants.
3. Tune hybrid alpha on a labelled query set instead of guessing.
4. Enable compression for large collections and measure recall before and after.
5. Use filters for hard constraints such as tenant, language or permissions.
6. Batch imports and monitor memory as the HNSW graph grows.
7. Plan replication and backups for production clusters.
8. Pin client and server versions and read release notes before upgrading.

## Common mistakes

- Creating thousands of separate collections instead of using tenants.
- Mixing vectors from different embedding models in one vector field.
- Running HNSW on very large uncompressed collections and running out of memory.
- Relying on pure vector search for queries full of product codes or names.
- Forgetting that changing the vectoriser means re-importing data.
- Using the GraphQL API for new code when the current clients recommend gRPC-based APIs.

## Frequently asked questions

### Is Weaviate free?

The database is open source under the BSD-3-Clause licence and free to self-host. The managed Weaviate Cloud service is paid, with plans listed on the company's site.

### Do I need to create embeddings myself?

No. You can configure a vectoriser module and let Weaviate call an embedding model, or you can supply your own vectors. Many production teams bring their own for full control.

### How does hybrid search merge results?

Weaviate runs a vector search and a BM25 search, then fuses the two ranked lists. It offers a rank-based fusion and a score-based fusion, and alpha sets how much weight each side gets.

### Can Weaviate handle many customers in one deployment?

Yes. Multi-tenancy gives each tenant its own shard inside a collection, which isolates data and allows inactive tenants to be offloaded.

### Is Weaviate suitable for RAG?

Yes. It is commonly used as the retrieval layer, and it can also call a generative model directly in a query. See [naive RAG](/tools/naive-rag) for the basic pattern.

### How do I query it?

Use the official clients for Python, TypeScript, Go, Java or C#. Under the hood they use REST and gRPC; a GraphQL API is also available.

## Glossary

- Vector database: a database built to store and search embeddings.
- BM25: a classic keyword relevance score.
- Shard: a partition of a collection's data.
- Replication: keeping copies of data on several nodes.
- Recall: share of true nearest neighbours that a search returns.
- Reranker: a model that reorders a short list of results.
- Tenant: one isolated customer's data partition.
- Rescoring: recomputing scores of top results with full-precision vectors.

## Summary

Weaviate is an open-source vector database written in Go, started by Bob van Luijt in 2016 and developed by the Amsterdam-based company Weaviate B.V. It combines vector search, BM25 keyword search and filtering in single queries, can create embeddings and generate answers through modules, and supports multi-tenancy, replication and several compression methods. It suits retrieval and RAG systems that want rich search built into the database, provided teams plan for memory use, tuning and cluster operations.