Weaviate: hybrid search and multi-location

#What sets Weaviate apart from other vector databases

Weaviate is an open-source vector database whose code is published on GitHub. Unlike libraries such as FAISS, it is a server: it stores objects (text and properties), vectors, and the search index, and responds to queries through an API. Three features distinguish it from a simple vector store. The first is built-in encoding: you insert objects, a configured module transforms the text into vectors, and queries are written in natural language rather than as arrays of floating-point numbers. This choice eliminates a class of bugs (incompatible dimensions, a question encoded with a different model from the corpus), since the same module processes both sides.

The second is hybrid search, which combines keywords and vectors in a single query. The third is multi-tenancy: a single deployment can host multiple isolated datasets, one per customer, service, or user. The price of these features is a component that has to run, with its memory, backups, and updates, whereas ChromaDB in file mode is just a Python library.

#Keep everything local: three settings to check

An encoding module is a dependency with a location. Choosing a vectorizer hosted by a third party means sending each of your documents and each of your questions elsewhere; choosing the Ollama module keeps the computation on your hardware. Two other settings are less visible and deserve the same attention.

The vectorizer

Use text2vec-ollama, which calls your local Ollama instance; the documentation says it does not require an API key in this case. Watch the address: if Weaviate runs in a container and Ollama runs on the host machine, the documentation recommends host.docker.internal so the container can reach the host.

Telemetry

Weaviate's documentation indicates that it collects telemetry data by default: server version, operating system, modules used, number of objects and collections, sent every 24 hours; it specifies that none of your data's content is collected. To disable it, set DISABLE_TELEMETRY to true. In an installation that must remain hermetic, set it.

Anonymous access

The quick-start docker run command sets AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED to true, and the documentation strongly discourages anonymous access outside development or evaluation. As soon as port 8080 is reachable from anything other than your workstation, enable API-key authentication.

#Install Weaviate with Docker and Ollama

1. 01
   Have Ollama and an embedding model

   Install Ollama and download the model with ollama pull bge-m3.
2. 02
   Write the docker-compose.yml file

   It declares the Weaviate container, its data volume, activation of the Ollama module, disabled telemetry, and host access.
3. 03
   Start and verify

   Run docker compose up -d, then test the address http://localhost:8080/v1/meta: the response lists the active modules.
4. 04
   Create a collection linked to the module

   The collection indicates which model Ollama vectorizes which properties.

services:
  weaviate:
    image: cr.weaviate.io/semitechnologies/weaviate:1.39.7
    ports:
      - "8080:8080"
      - "50051:50051"
    volumes:
      - weaviate_data:/var/lib/weaviate
    restart: on-failure:0
    extra_hosts:
      - "host.docker.internal:host-gateway"   # utile sous Linux pour joindre Ollama sur l'hôte
    environment:
      QUERY_DEFAULTS_LIMIT: 25
      AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: 'true'   # à fermer si le port est exposé
      PERSISTENCE_DATA_PATH: '/var/lib/weaviate'
      ENABLE_MODULES: 'text2vec-ollama'
      DISABLE_TELEMETRY: 'true'
      CLUSTER_HOSTNAME: 'node1'
volumes:
  weaviate_data:

Version 1.39.7 is the version of Weaviate’s official documentation at the time of writing; use the current version shown on the installation page. Ports 8080 (HTTP) and 50051 (gRPC) are the ones used in the documentation’s quick start.

#The schema: collections, properties, vectorizer, tenants

import weaviate
from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(
    "Document",
    vector_config=[
        Configure.Vectors.text2vec_ollama(
            name="contenu_vecteur",
            source_properties=["contenu"],
            api_endpoint="http://host.docker.internal:11434",
            model="bge-m3",
        )
    ],
    properties=[
        Property(name="contenu", data_type=DataType.TEXT),
        Property(name="source", data_type=DataType.TEXT),
    ],
)

coll = client.collections.use("Document")
coll.data.insert_many([
    {"contenu": "Le délai de préavis est de trois mois.", "source": "contrat.pdf"},
    {"contenu": "Le loyer est révisé chaque année au 1er janvier.", "source": "bail.pdf"},
])
client.close()

The structure follows the official documentation: vector_config, a named vectorizer, source properties, and an Ollama access point. Weaviate vectorizes text-type properties by default, sorting them alphabetically and then concatenating them; source_properties lets you restrict the calculation to the relevant property and keep the filename out of the vector.

#Hybrid search in Weaviate

Semantic search finds passages with similar meaning and fails on exact strings: an invoice number, a part number, an error code, or a proper name. Weaviate's hybrid search combines the results of a vector search and a BM25F keyword search by merging the two result sets, with configurable weights and a configurable fusion method. The alpha parameter controls the balance: according to the documentation, 1 corresponds to pure vector search and 0 to pure keyword search. Without alpha, the effective weighting depends on your client: always set it explicitly.

coll = client.collections.use("Document")
res = coll.query.hybrid(query="préavis contrat CDI", alpha=0.5, limit=5)
for o in res.objects:
    print(o.properties["source"], o.properties["contenu"][:80])

Since version 1.24, the default merge method has been relative-score merging; the alternative is rank merging. The principle and the choice between the two are explained in the guide on hybrid search. On a technical corpus, this is often the difference between a system you trust and one you abandon: pure-vector failures occur precisely on searches that users consider trivial.

#Multi-tenancy: one tenant per user group

Multi-tenancy partitions a collection into fragments, one per tenant. The documentation describes it as follows: each tenant is stored in a separate fragment, and one tenant's data is not visible to another. It is disabled by default and enabled in the collection definition with multi_tenancy_config. If multiple groups query the same system (SMB customers, company departments, family members), it is a structural answer to the question “can this person retrieve this document?”, much safer than a filter applied afterward, and infinitely safer than an instruction in the prompt.

from weaviate.classes.config import Configure
from weaviate.classes.tenants import Tenant

client.collections.create(
    "DocumentClient",
    multi_tenancy_config=Configure.multi_tenancy(enabled=True),
)
coll = client.collections.use("DocumentClient")
coll.tenants.create([Tenant(name="client_a"), Tenant(name="client_b")])

# Toute requête passe par un tenant : les autres restent invisibles
res = coll.with_tenant("client_a").query.hybrid(query="préavis", limit=3)

Tenants are lightweight: the documentation says you can have 50,000 or more active fragments per node. They have a state (ACTIVE, INACTIVE, OFFLOADED): an inactive tenant is stored on disk and uses no memory, making it possible to host many small datasets while keeping active only those in use. A tenant name accepts only alphanumeric characters, underscores, and hyphens.

#What it costs to run Weaviate

Weaviate is a real service: a container, persistent storage, and memory proportional to your vectors. The sizing documentation is clear about the constraint: the HNSW index must be stored in memory, memory determines the maximum dataset size, and it does not directly affect query speed. The documentation’s rule of thumb is to allow for twice the memory footprint of all vectors.

empreinte d'un vecteur = dimensions × 4 octets (float32)
mémoire estimée   = 2 × nombre de vecteurs × empreinte d'un vecteur

Exemple, bge-m3 (1 024 dimensions) :
  1 024 × 4 = 4 096 octets par vecteur
  100 000 passages → 2 × 100 000 × 4 096 ≈ 0,8 Go
  1 000 000 passages → 2 × 1 000 000 × 4 096 ≈ 8,2 Go

The 1,024 dimensions of bge-m3 are an assumption here that you should verify against your model's specifications. For a personal or small-business corpus (a few tens of thousands of passages), index memory usage is low; it becomes an issue at several million passages. Weaviate offers vector compression: the documentation recommends rotational quantization (RQ) and also mentions product quantization (PQ), binary quantization (BQ), and scalar quantization (SQ), at the cost of a slight loss of information. Add the local encoding module: Ollama runs an embeddings model on the same machine as your language model. On a single machine, decide which of the two gets the GPU, or accept that indexing and inference will compete with each other.

#Provide your own vectors, or migrate from ChromaDB

The encoding module is not required. Weaviate's documentation describes the “bring your own vectors” approach: instead of letting the database calculate embeddings, you provide ones you already have, whether customized or pre-generated. In the Python client, you then declare a named vector with Configure.Vectors.self_provided. This is the most cost-effective migration path from ChromaDB: you reread the documents and vectors already calculated (Chroma can return them with the include option), then send them to Weaviate without calling the embedding model again. Two checks prevent surprises: vector dimensions must be consistent across the entire collection, and queries must be encoded with the original model, since Weaviate will not do this for you.

When should you prefer built-in encoding? If you want queries to be written directly as text, adding documents to require no computation code, and the model's consistency to be guaranteed by the configuration. When should you prefer your own vectors? If you already have an embeddings pipeline, need to use a model that no module offers, or want to be able to change vector databases without recalculating everything.

#Weaviate or another vector database

If you are unsure, start with the simplest solution: ChromaDB for a prototype, then migrate to a service when a specific need arises (isolation, native hybrid search, volume). The choice is reversible as long as you keep the source documents and indexing script.

#Frequently asked questions about Weaviate

• Hybrid search: BM25 + vector search
• Qdrant: the vector database for local RAG
• pgvector: vector search in PostgreSQL
• FAISS: the library behind vector search
• Local RAG with ChromaDB and Ollama

• Source: Weaviate, hybrid search
• Source: Weaviate, Ollama module
• Source: Weaviate, telemetry
• Source: Weaviate, resources and memory