Weaviate

Open-source vector database for semantic and AI search

Search Engines ★ 16.8k stars Medium setup BSD-3-Clause

Weaviate is an open-source vector database that stores objects and their vector embeddings for semantic search. It enables AI-powered similarity search, retrieval-augmented generation and hybrid queries.

Key features

  • Vector and hybrid search
  • Built-in vectorization modules
  • GraphQL and REST APIs
  • Horizontal scaling

Pros & cons

Strengths

  • Great for AI semantic search
  • Easy to start

Trade-offs

  • Memory hungry with large datasets

Weaviate replaces

Last reviewed Aug 26, 2026 · 772 words

One million 768-dimensional vectors cost about 3 GB of RAM in Weaviate before the index overhead, because HNSW keeps the vectors and the graph in memory, and float32 times 768 times a million is 3.07 GB. Add the graph links and the object metadata and a real million-object collection wants 5 to 6 GB. That is the number to run before pulling the image, and it explains both the catalogue's 2 GB minimum (fine for tens of thousands of chunks) and its only listed con (memory hungry at scale). For a home RAG setup over a few thousand documents, none of this bites; for a full email archive it decides the hardware.

One container, two ports, one flag to turn off

Weaviate, BSD-3-Clause, Go, around 16,800 stars, runs as a single container with REST on 8080 and gRPC on 50051. Both matter: the current client libraries do their bulk work over gRPC, so publishing only 8080 gives you slow imports and confusing errors. The quick-start Compose files enable anonymous access, which is convenient for 10 minutes and dangerous afterwards:

services:
  weaviate:
    image: cr.weaviate.io/semitechnologies/weaviate:latest
    ports:
      - "8080:8080"
      - "50051:50051"
    environment:
      AUTHENTICATION_ANONYMOUS_ACCESS_ENABLED: "false"
      AUTHENTICATION_APIKEY_ENABLED: "true"
      AUTHENTICATION_APIKEY_ALLOWED_KEYS: "replace-with-a-long-random-key"
      AUTHENTICATION_APIKEY_USERS: "admin"
      PERSISTENCE_DATA_PATH: /var/lib/weaviate
      ENABLE_MODULES: text2vec-ollama,generative-ollama
      DEFAULT_VECTORIZER_MODULE: text2vec-ollama
      CLUSTER_HOSTNAME: node1
    volumes:
      - ./weaviate-data:/var/lib/weaviate
    restart: unless-stopped

Set CLUSTER_HOSTNAME explicitly even on one node; if it changes between restarts the data directory stops matching and you get an empty database with your files still on disk.

The built-in vectorizer is the feature that removes a script

Most vector databases store vectors you computed elsewhere. Weaviate's modules compute them on the way in: point text2vec-ollama at your Ollama instance (apiEndpoint: http://host.docker.internal:11434, model: nomic-embed-text in the collection config) and every object you insert gets embedded, and every text query gets embedded with the same model, with no client-side code. The generative-ollama module goes a step further and has Weaviate call the LLM with retrieved objects as context, so a basic RAG query is one API call. There are equivalent modules for OpenAI, Cohere and a local transformers container. If you already have an embedding pipeline, disable the modules and bring your own vectors; the point is that a solo self-hoster does not have to write one.

Hybrid search is what justifies it over pgvector

Pure vector search misses exact terms: a part number, a surname, an error code. Weaviate keeps a BM25 keyword index next to the vector index and fuses them in a single hybrid query with an alpha between 0 (pure keyword) and 1 (pure vector); 0.5 to 0.7 is where most people land. Filters on metadata combine with either. Adding this to Postgres and pgvector means running full-text search yourself and merging results in application code, which is doable and a weekend. For a large collection, product or binary quantization cuts the in-memory vector footprint several-fold at a small recall cost, and that is the lever to pull before buying RAM.

Weaviate against Qdrant and Chroma for a home stack

Qdrant is the lighter rival: Rust, lower memory at rest, excellent filtering, no built-in vectorizers, so you embed client-side. Chroma is the simplest to start and the one most tutorials use, at the cost of scale and operational features. Weaviate is the middle: heavier than Qdrant, far more complete than Chroma, with the modules, multi-tenancy and a backup module (backup-filesystem with a path you mount) that the others make you script. The choosing a vector database post lays the field out; for chat UIs that bring their own store, check which back ends they support before choosing, because several default to Chroma or Qdrant and do not talk to Weaviate at all.

What I'd do

For a personal RAG setup over a few thousand documents on a box with 8 GB to spare, run Weaviate with text2vec-ollama, API-key authentication on, and the filesystem backup module pointed at a directory your regular backup already covers. It is the least code to a working semantic search, and hybrid queries fix the exact-match failures that make pure vector search feel broken. If memory is tight or you are on a Raspberry Pi, run Qdrant instead and embed in your own script. If the corpus is a few hundred notes, Chroma is enough and the rest is overkill.

Compare Weaviate

22 head-to-head comparisons.

Similar search engines apps