Weaviate

The third answer to where vectors live

This site has already covered two positions on where to put your embeddings. Supabase Vector says use the database you already run. LanceDB says do not run a database at all.

Weaviate is the third: run a service whose only job is search.

That sounds like the expensive option, and operationally it is. What you get for it is a system where retrieval quality is the product rather than a feature attached to storage, which shows up in two places a general-purpose store usually leaves to you.

Hybrid search, and the queries pure vector search loses

Vector search has a well-known blind spot, and it is the one your users find first.

It matches on meaning, which is what you wanted right up until someone searches for ERR_CONN_4021 or a part number or a customer's surname. Those have no meaning to embed. The model has never seen that string, it lands somewhere arbitrary in the space, and you get back documents about connection errors in general rather than the one page documenting that code.

Keyword search has the opposite blind spot. It finds the exact string and misses every document phrasing the same idea differently.

Hybrid search runs both and merges. In Weaviate's own words: "Hybrid search combines the results of a vector search and a keyword (BM25F) search by fusing the two result sets." You can build this yourself on top of two systems; the argument for a store that has it is that fusing two ranked lists correctly is fiddlier than it looks, and here it is one query parameter.

Two fusion methods are documented. Relative Score Fusion, the default since v1.24, uses "the keyword and vector search relative scores instead of the search rankings". Ranked Fusion uses rank positions instead. The distinction matters when one engine is confident and the other is not: score fusion can let a strong keyword match win outright, while rank fusion only knows it came first.

Setting alpha, and why there is no default to lean on

One number controls the blend. Alpha of 1 is pure vector search, 0 is pure keyword.

Then the documentation says something more useful than a default would be: "If you do not set alpha, the effective weighting depends on your client."

Read that as an instruction. Set it explicitly, in code, with a comment saying why. Leaving it out does not give you a sensible middle. It gives you whatever your client library picked, which means the same query can rank differently from two languages against the same data. That is a bug that takes a long time to find.

As for what to set it to: it depends on your corpus, and nobody can tell you without seeing your queries. Technical documentation full of identifiers and error codes wants more keyword weight. A knowledge base of prose wants more vector. The way to decide is the way context evaluation describes: a set of real queries with known correct answers, run at several values.

Choosing an index for the shape of your data

The second thing a search-focused store gives you is a real choice of index, where a general-purpose one gives you whichever it implements.

Four types, with the documentation's own guidance:

The flat index describes an architecture rather than a size. HNSW is a graph: fast to search, expensive to build, and resident in memory. Flat is "a simple, lightweight index that is fast to build and has a very small memory footprint", which sounds worse until you have ten thousand customers with two hundred documents each. Ten thousand HNSW graphs is a memory problem you cannot buy your way out of. Ten thousand flat indexes is fine, because a brute-force scan over two hundred vectors is instant.

Dynamic exists for the case where you cannot know in advance: it "automatically switch[es] from flat to HNSW indexes" once a collection passes a threshold, which is the sensible default for multi-tenant data where one tenant might become large.

HFresh is the newest of the four, "a cluster-based vector index that uses HNSW for the centroid index", using quantization to keep memory down, 8-bit for centroids, 1-bit for on-disk posting lists. I am reporting its documented positioning rather than measured behavior; memory-efficiency claims are the kind worth testing on your own vectors.

When a search service earns its operational cost

Be honest about the comparison, because the alternatives on this site are good.

Run Postgres with pgvector if you already run Postgres and your corpus is moderate. One system to back up, one to monitor, one your team knows. That argument wins more often than vendor comparisons admit.

Run no server if your data is embedded in one application, or multimodal, or you are optimizing for a local development story.

Run a search service when retrieval quality is the product rather than a feature of it. The concrete signals: your queries mix exact identifiers with natural language, so you need hybrid search and do not want to build the fusion; your data is many small isolated datasets rather than one large one, so index choice matters; or search needs to scale independently of the application, which an embedded library cannot do and a shared Postgres does awkwardly.

If none of those describes you, the simpler answer is probably right. The first one is the most common reason to move: exact-match failure is the retrieval bug users report most, and embeddings cannot fix it.

Further reading

• Weaviate, Hybrid search: fusion algorithms, alpha, and the BM25F keyword side.
• Weaviate, Vector indexes: the four index types and their documented use cases.
• Purpose and functionality: what this category of store does at all.
• Supabase Vector and LanceDB: the two cheaper answers.