Migrate to the Index Server
Moving from another search engine or vector database is a data copy, a relevance check, and an endpoint swap — not a re-platforming project. The server speaks the OpenSearch 3.5 REST API and additionally exposes Qdrant, Pinecone and Chroma-compatible dialects, so in most cases your existing client keeps working. Pick your source below.
Which move is yours?
| Coming from | Why teams move | Keep your client? | Guide |
|---|---|---|---|
| Elasticsearch / OpenSearch | Same API, ~18–44% faster ingest in ~1/10th the memory, plus native vector + hybrid the old cluster never had. | Yes — OpenSearch clients unchanged; compat.flavor=elasticsearch for ES 8.x clients. |
Read → |
| Pinecone | Stop paying per-vector storage + read/write units + a separate per-token embedding API. Embed at ingest for $0/token on your own disk. | Yes — Pinecone-compatible dialect. | Read → |
| Chroma | Take the RAG prototype to production: server-side hybrid, fast filtered vectors (3 ms vs ~33 ms), auth/TLS/snapshots/HA. | Yes — Chroma-compatible dialect. | Read → |
| Weaviate | Same server-side hybrid, but over the familiar OpenSearch API with aggregations/facets — ~2× faster hybrid and ingest here. | Import + adopt the OpenSearch API (no Weaviate wire-dialect; Weaviate is GraphQL-native). | Read → |
| Qdrant | Consolidate: one engine for vector and keyword and hybrid and facets. (Qdrant is the fastest raw ANN here — we say so.) | Yes — Qdrant-compatible dialect. | Read → |
| Algolia | Self-host faceted search with no per-record/per-search billing, keep data in your VPC, and add vector + hybrid in the same engine (not a paid add-on). | Yes — Algolia-compatible dialect. | Read → |
Numbers reference the published Graviton benchmarks (AWS c8g.4xlarge, engines run one at a time). Each guide states the honest trade-offs too — a dedicated vector engine can still edge raw ANN latency, and Lucene phrase queries favor Elasticsearch/OpenSearch.
How every migration works
Whatever the source, the same three
tools do the work — two of them built into the admin console at
http://<host>:9200/console.
- Copy the data — Migrate tab. Point it at your source (Elasticsearch, OpenSearch, Pinecone, Chroma, Weaviate, Qdrant or Solr); it discovers indexes/collections, streams documents + vectors over, and records source-vs-target counts so completeness is part of the job. No exporter to write.
- Or re-embed from source text (recommended for vector stores).
Map a
knn_vectorfield with anembedblock and index the original text — the bundled inference engine embeds inline, so you get a clean mapping with hybrid enabled and never move (or pay to move) the old vectors. - Prove relevance — Evaluate tab. Replay your golden queries against the index server (and, optionally, your old system as a baseline) with overlap@10, top-1 agreement, NDCG@10 and per-side latency. "Same results, faster" becomes a measurement, not a claim.
# one line installs the server + inference engine as a service
curl -fsSL https://index-server.searchblox.com/install | sudo bash
# map embed-at-ingest once, then just index text
PUT /docs
{ "mappings": { "properties": {
"body": { "type": "text" },
"embedding": { "type": "knn_vector", "dimension": 1024,
"embed": { "source_field": "body", "model": "your-embed-model" } }
}}}
# hybrid (BM25 + vector, RRF) in one clause — server embeds the query text
POST /docs/_search
{ "query": { "hybrid": { "queries": [
{ "match": { "body": "export invoices" } },
{ "neural": { "embedding": { "query_text": "invoice export error", "k": 20 } } }
] } } }