From Weaviate to the Index Server

September 2026 · 7 min read

Weaviate is a genuinely capable open-source vector database — hybrid search, a module ecosystem, and a GraphQL-first API. It's a fair choice, and this isn't a takedown. It's for the teams who've concluded they'd rather drive vector, keyword, and hybrid search over the OpenSearch REST API that the rest of their stack already speaks — with faster hybrid latency, higher ingest, and aggregations/facets in the same engine — and want to know what moving looks like and where Weaviate still wins.

The real difference: the API and the surface

Both engines do server-side hybrid (BM25 + vector). The day-to-day difference is what you write and what else the engine gives you:

	Weaviate	Index Server
Primary API	GraphQL (plus REST/gRPC)	OpenSearch 3.5 REST — `opensearch-py`/`-java` connect unchanged
Hybrid query	GraphQL `hybrid(query, vector, fusionType)`	one query-DSL clause `{"hybrid":{"queries":[…]}}`
Full-text + facets	BM25 + filters	BM25 + aggregations, facets, geo, `_cat`/`_count`/scroll — a full search server
Elasticsearch clients	—	`compat.flavor=elasticsearch` presents as ES 8.x

If your application (or platform — SearchBlox SearchAI 12.2 runs on it in production) already speaks OpenSearch, "adding vectors" stops being a second system with a second query language and becomes a mapping change plus a neural or hybrid clause.

The numbers (and where Weaviate wins)

From our published Graviton benchmarks (20k × 384-dim + a 20k text+vector hybrid corpus, engines run one at a time on a c8g.4xlarge):

metric	SearchAI 1.3.0	Weaviate
hybrid k=10 p50 (ms)	3.70	7.58
vector ingest (docs/s)	4,383	2,063
kNN k=10 p50 (ms)	3.19	8.30
filtered kNN p50 (ms)	3.03	4.86
recall@10	1.00 (low ef)	0.99 (ef≈1024)
server RSS (MB)	527	282

Honest scorecard: SearchAI answers hybrid queries ~2× faster, ingests ~2× faster, reaches full recall at a much lower ef, and adds the whole full-text/aggregation surface — but Weaviate is the lighter process (282 MB vs 527 MB here) and brings a mature module ecosystem (generative, reranker, and multi-modal modules) and a GraphQL model some teams prefer. If those modules or GraphQL are central to your app, that's a real reason to stay.

Migrating

There's no Weaviate wire-dialect here (Weaviate is GraphQL-native), so the move is a data import plus adopting the OpenSearch API — both are straightforward:

Console Migrate tab — connects to your Weaviate instance, types the schema, and streams objects + vectors over the cursor API; it records source-vs-target counts so completeness is part of the job.
Re-embed from source text (recommended) — index the original text and let the bundled inference engine embed inline via an embed mapping. You get a clean mapping with hybrid enabled and never move the old vectors.

PUT /docs
{ "mappings": { "properties": {
  "body": { "type": "text" },
  "embedding": { "type": "knn_vector", "dimension": 1024,
                 "embed": { "source_field": "body", "model": "your-embed-model" } }
}}}

# hybrid, one clause — the server embeds the query text itself
POST /docs/_search
{ "query": { "hybrid": { "queries": [
    { "match": { "body": "export invoices" } },
    { "neural": { "embedding": { "query_text": "invoice export error", "k": 20 } } }
] } } }

Prove it before you commit

The console's Evaluate tab holds golden query sets and can replay them against the index server (and a baseline) with overlap@10, top-1 agreement, NDCG@10 and per-side latency — so "same results, faster" is a measurement, not a claim.

One line installs the server and inference engine:

curl -fsSL https://index-server.searchblox.com/install | sudo bash

Start with the Getting Started guide or a build from the downloads page; the full comparison and honest edges are on the benchmarks page.