Weaviate for RAG: Capabilities and Limits

Weaviate is an open-source vector database, written in Go, that you can self-host or run as Weaviate Cloud. For RAG its draw is three built-ins that cut glue code: native hybrid search, in-database vectorisation and multi-tenancy. Its main ceiling is memory — the vector index must live in RAM. This page states both the capabilities and the limits, up front.

What is Weaviate, and what makes it good for RAG?

An open-source vector database built around the HNSW index for approximate nearest-neighbour search, exposed over GraphQL and REST, and run either self-hosted (Docker, Kubernetes) or as the managed Weaviate Cloud. What makes it a comfortable RAG default is that three things other stacks bolt on are built in:

• Native hybrid search — vector similarity and BM25 keyword scoring in one query, no second system to run.
• In-database vectorisation and generation — modules embed your objects, and can run the generative step, without a separate embedding service.
• Multi-tenancy — isolate many tenants’ data inside one cluster, which matters the moment you serve more than one customer.

If you only need the general idea of what a vector database is, that background sits at vector databases. The rest of this page is Weaviate specifically — what it does well, and where it strains.

Does Weaviate do hybrid search — and how does vectorisation work?

Yes, and it is native. A hybrid query fuses vector similarity with BM25 keyword scoring, blended by an alpha weight: alpha=1.0 is pure vector, alpha=0 is pure keyword, and values between mix them. That means exact terms a dense embedding would blur — an error code, a part number — still get matched. The second built-in is vectorisation: a vectorizer module embeds your objects on import and a generative module can produce the answer in-database, so a minimal RAG needs no separate embedding call at all.

How the two scores actually combine — relative-score versus ranked fusion — is a mechanism in its own right, covered at hybrid search. What vectorisation is doing under the hood is at embeddings. Here the point is narrower: with Weaviate, hybrid and embedding are one system, not three.

Weaviate’s capabilities and limits, side by side

No capability without its ceiling. Each row pairs what Weaviate gives you with the limit that rides along — so the trade is visible before you commit, not after.

The two rows that bite first in production are memory and the operational failure modes. Both get their own section rather than a single cell, because both are where teams get surprised.

How much memory does Weaviate need at scale?

The HNSW index lives in memory, so RAM is your dataset-size ceiling — not your query speed. Weaviate’s own resource docs give the rule of thumb, and it is worth taking literally:

Memory usage = 2 × (footprint of all vectors)

# worked example: 1,000,000 objects, 384-dimensional, float32
one vector       = 384 × 4 B         = 1536 B
one million      = 1e6 × 1536 B      = 1.5 GB   of raw vectors
Memory usage     = 2 × 1.5 GB        ≈ 3 GB     of RAM

So a million small vectors is a few gigabytes; scale the object count or the dimension and the requirement scales with it. Weaviate ships two escape hatches when memory is the constraint, and this page names them because they are the honest answer to the ceiling: product quantization (PQ) compresses the vectors so more fit in RAM, and the disk-based HFresh index moves the index off memory entirely at a speed cost. What quantization does to a vector is covered at embeddings; whether that memory profile beats the alternatives is a decision question at which vector database.

What breaks Weaviate in production?

The failure modes are real and worth knowing before you self-host — these come straight from Weaviate’s published known issues page, kept in rather than glossed over. Each is operable with configuration; none is a secret:

• Memory-pressure shard-init failure (all versions) — a shard fails to initialise when RAM is tight; the fix is capacity and the resource-limit env vars, which ties back to the memory ceiling above.
• RAFT timeouts under heavy load (1.25 and later) — false failure detection triggers leader elections; tune RAFT_TIMEOUTS_MULTIPLIER and address the underlying resource pressure.
• RAFT bootstrap timeout with many collections or large schemas — the default 600-second bootstrap can be exceeded on a big cluster; raise the timeout and the startup probe.
• Empty-collections panic (1.28–1.31) — marked In Progress as of October 2025, so check your version against the known-issues page before you pin one.

Read honestly: these are the tax of a self-hosted distributed database, not disqualifiers — but “just run it yourself” hides them, and you should not be surprised in an incident. Whether that operational load is worth it versus a fully-managed option is the vector-database decision.

Is Weaviate free, and how does it compare to Pinecone and Qdrant?

The core is open-source and free to self-host; Weaviate Cloud is the paid managed option, with a free sandbox tier to start on. Against the two databases it is most often weighed against:

• Pinecone — fully managed with no self-host path: simpler operations, less control, and you do not touch the RAFT and memory knobs above because you never run the cluster.
• Qdrant — also open-source, filtering-first and leaner, with fewer built-in modules to inherit.

Which of the three actually wins for a given RAG build is not this page’s call to make — this profile draws the boundary between them; the scored survey ranks them. The scored verdict across Weaviate, Qdrant, Pinecone, Milvus and pgvector is at which vector database should you use, and the Qdrant deep-dive is at Qdrant for RAG.