Home / Comparisons / Search Engine vs Vector Database for Semantic Search

Search Engine vs Vector Database for Semantic Search

A vector database such as Weaviate is built around a vector index and adds keyword search alongside it. Weaviate’s counterparts in the search engine family, such as Elasticsearch or OpenSearch, are built around an inverted index for keyword search and have added vector search. Today both families can run keyword, vector and hybrid queries, so the choice is less about whether semantic search is possible. It turns on defaults, depth and operations. Search engines are strongest when text analysis, aggregations, logs or an existing cluster matter most. Vector databases are strongest when vectors are the main workload, with built-in embedding model integrations, vector compression, multi-tenancy and filtered vector search tuned for scale. Memory is the shared constraint. Ten million 768-dimension float32 vectors take 30.72 GB before compression, whichever engine holds them.

What is the difference between a search engine and a vector database?

The difference is the starting point: a search engine is designed first for matching words in documents, and a vector database is designed first for finding the nearest vectors to a query vector. Each has grown towards the other, but the core shapes the defaults.

A traditional search engine stores text in an inverted index: for each word, the list of documents that contain it. Analyzers handle stemming, stop words and language rules, and BM25 ranks the matches. Search engines built on Apache Lucene work this way. Vector fields came later, indexed with HNSW graphs inside the same engine.

A vector database such as Weaviate stores an embedding for each object and indexes those embeddings for nearest neighbour search. Weaviate’s documentation describes an inverted index stored next to the HNSW index in each shard, used for filters and BM25 keyword search. Its FAQ frames the difference the same way: Weaviate stores data as vectors natively as well as in inverted indexes, which other systems rely on alone. Background on the vector side is in semantic search vs vector search.

How does vector search differ from traditional search?

Vector search ranks documents by closeness in meaning, through embeddings, while traditional search ranks them by overlap of words, through an inverted index and a formula such as BM25. Each finds results the other misses.

Traditional keyword search returns documents that contain the query’s words or their stems. It is precise for names, codes and exact phrases, cheap to run and easy to explain. It misses documents that use different words for the same idea, such as “rucksack” for “backpack”, unless synonyms are configured by hand. Vector search finds those matches because similar meanings sit close together in embedding space, but it can miss exact identifiers and rare terms.

That is why the best semantic search systems usually combine both in hybrid search. The detailed trade-off is in BM25 vs vector search and semantic search vs keyword search. Whether you choose a search engine or a vector database, you will likely run both kinds of retrieval.

How do search engines handle semantic search?

Search engines handle semantic search by adding vector fields with approximate nearest neighbour indexes, plus options to run embedding models and to fuse vector and keyword results. The implementation sits on top of their existing keyword architecture.

Elasticsearch offers a dense vector field type with approximate kNN search on HNSW, quantization options, a learned sparse model called ELSER, and hybrid ranking through reciprocal rank fusion. OpenSearch offers a k-NN plugin with Lucene and Faiss engines, a neural search plugin that calls embedding models, and a hybrid query with score normalization in a search pipeline. Exact features and defaults change between versions, so check current documentation.

Lucene stores data in immutable segments, and each segment has its own HNSW graph. A vector query searches each segment’s graph and merges the results, and segment merges rebuild graphs. This design fits Lucene’s write model well, but it means heavy indexing and many small segments can affect vector query cost. Lucene-based engines tune merging and refresh settings to manage this.

What do vector databases add beyond search engines?

Vector databases add features designed around embeddings: integrations that create vectors at import and query time, several vector compression methods, multi-vector and named vectors, and filtered vector search built for the vector index. These are the workloads they were built for.

Weaviate is a representative example. Its vectorizer integrations call embedding models during import and search, so applications can send text and get semantic results without managing vectors. It offers product, binary, scalar and rotational quantization, ColBERT-style multi-vector embeddings, and several named vectors per object. Its filtered search uses an allow list from the inverted index and the ACORN strategy for hard filters, described in filter selectivity.

Vector databases also tend to treat multi-tenancy, generative search for RAG and model-provider integrations as core features. Weaviate’s hybrid search fuses BM25 and vector results with selectable fusion methods and an alpha weight, covered in score fusion methods. The trade-off is that keyword analysis, aggregations and log analytics are usually less deep than in a mature search engine.

How much memory does vector search need in either system?

Vector search needs roughly the vector count times dimensions times bytes per dimension in memory, plus graph links, in any engine that keeps HNSW vectors in RAM. The engine changes the overheads and compression options, not the basic arithmetic.

Ten million vectors of 768 float32 dimensions take 30.72 GB. Stored at 8 bits per dimension they take 7.68 GB, and at 1 bit they take 0.96 GB. The HNSW graph adds links per vector on top. Both search engines and vector databases offer quantization to shrink this. Recall effects differ by method and data, as covered in embedding quantization.

Compare candidate systems on the same vectors, the same compression level and the same recall target. A memory or latency figure quoted without recall, dimensions and compression settings cannot be compared fairly. The method for running that comparison is in search latency.

When should you use a search engine for semantic search?

Use a search engine for semantic search when you already run one in production, when keyword relevance and text analysis matter most, or when the same cluster also serves logs, analytics or aggregations. Adding vectors to a working cluster avoids a second system.

Teams with years of tuned analyzers, synonyms and ranking rules lose a lot by moving. Adding a vector field and a hybrid query keeps that work and adds semantic matching on top. Search engines are also natural fits when faceted navigation and heavy aggregations sit next to search, as in many shop catalogues and log tools.

The cost is that vector features may arrive later, need plugins or paid tiers, or require more manual work, such as running embedding models outside the engine. Watch how vector indexing interacts with heavy write loads. If vectors become most of the workload, revisit the choice.

When should you use a vector database for semantic search?

Use a vector database for semantic search when vectors are the main workload or when you need vector-first features such as built-in vectorization, compression or multi-tenancy. It also suits RAG and agent applications built from scratch. A purpose-built system reduces glue code.

New projects without an existing search stack often reach a working semantic or hybrid search faster on a vector database, because model integrations, hybrid search and filters come configured together. Weaviate, for example, can vectorize at import, run hybrid queries with filters and pass results to a generative model in one request, as shown in semantic search with Weaviate.

Vector databases also suit products that serve many customers from one system, through native multi-tenancy, and collections with many vectors per object or multimodal data. If the main need is log search, complex aggregations or language-specific text analysis, a search engine may still be the better primary store.

Can you use a search engine and a vector database together?

You can use a search engine and a vector database together, running keyword search in one, vector search in the other and fusing the results. You then pay to operate and synchronise two systems. Most teams prefer one system when it covers their needs.

A combined setup typically sends the query to both, retrieves a candidate list from each, and fuses them with reciprocal rank fusion or score normalization in the application. That keeps each system in its strength, but every document must be indexed twice, kept consistent on updates and secured twice. Deletes and permission changes are the usual source of drift.

Because both families now support hybrid search, the dual setup is mainly a migration step or a special case. Moving from one to the other is covered in migrating to a new vector database. A relational database with a vector extension is a third option, compared in pgvector vs dedicated vector database.

How should you evaluate the two options?

Evaluate the two options on your own data and queries, measuring retrieval quality, latency at your recall target, memory, write behaviour and operational effort. Feature lists alone rarely decide the question.

Build a test set of real queries with relevance judgments, run keyword, vector and hybrid search on each candidate, and compare quality with the same embedding model. Then load production-scale data and measure latency, memory and indexing speed under realistic filters. Include updates and deletes, not only reads.

Finally weigh operations: managed offerings, backups, scaling, security and the skills of your team. The terms around this choice are often blurred. Related comparisons cover semantic search vs similarity search, semantic search vs RAG, natural language search, semantic search vs knowledge graph search and semantic search vs the semantic web.

Vector databases such as Weaviate start from a vector index and add keyword search alongside; search engines such as Elasticsearch and OpenSearch start from an inverted index and add vectors. Both now run keyword, vector and hybrid queries. Choose a search engine when an existing cluster, text analysis, logs or aggregations dominate. Choose a vector database when vectors are the main workload and built-in vectorization, compression, multi-vector or multi-tenancy matter. Memory follows the same arithmetic in both: 30.72 GB for ten million 768-dimension float32 vectors before compression. Test both on your own queries before deciding.