Vespa

Last reviewed Sep 13, 2026 · 766 words

Vespa is the wrong tool for a personal search box and the right tool for maybe one reader in a hundred here: the one building an application where text search, vector retrieval and a machine-learned ranking model have to run together, on the server, at low latency, over tens of millions of documents. It began inside Yahoo, was open-sourced in 2017, spun out as its own company in 2023, and carries a 4 GB minimum that is the smallest honest number for anything it does. If you want Meilisearch with more knobs, stop here; if you are weighing it against Elasticsearch for a product, keep reading.

What Vespa actually is

It is not a search index with a vector plugin. It is a serving engine where every document can hold text fields, tensors and structured data, and where a query runs through a ranking expression you write that can combine BM25, nearest-neighbour distance over embeddings, and an ONNX model applied to each candidate, all in one pass on the content nodes. Indexing is real-time, so a document is searchable milliseconds after a feed operation rather than after a refresh interval. The same cluster does grouping, aggregation and streaming search. Recommendation systems at consumer scale run on it, which tells you the design target and explains most of the decisions that feel heavy at small scale.

The 4 GB is a floor, not a suggestion

The single-container quickstart pulls vespaengine/vespa, and inside it the config server, the container cluster (the Java layer that handles queries and feeding) and the content node (C++, holding the index) all start together, which is why the container is unusable below 4 GB. Give it 8 GB and 4 cores for anything you will develop against. Ports to know: 8080 for queries and feeding, 19071 for deploying application packages. A production layout separates those roles across machines, which is where multi-node Kubernetes deployments and the vendor's hosted Vespa Cloud come in; a single node is fine for development and for small serving workloads that fit in memory.

The application package is the learning curve

Nothing is configured through a UI or a settings API. You write an application package: services.xml describing clusters and nodes, and one .sd schema file per document type declaring fields, indexing modes and rank profiles. Deploy it with vespa deploy from the CLI and the cluster reconfigures itself. It is a strong model once it clicks, because the whole search behaviour is in version control, and a steep one before that, because a schema mistake surfaces as a deployment error in a domain-specific language rather than as a wrong result. Expect a week before you are productive if you know Elasticsearch, longer if you do not, and read the ranking documentation before writing a single query.

Where it beats Elasticsearch and the vector databases

Against Elasticsearch and OpenSearch, Vespa wins when the ranking model is the product: multi-phase ranking where a cheap function narrows 10 million candidates to 1,000 and an ONNX model rescores those, on the content node, without shipping candidates to an application server. Against Qdrant and the other vector stores, it wins when vectors are one signal among several rather than the whole query, and when the corpus changes constantly. It loses to both on ecosystem size, on the number of engineers who already know it, and on how quickly a small team gets something running. The choosing a vector database piece lays out the hybrid-search decision that usually settles this.

The smaller picks for everyone else

For a site or app search box under a few million documents, Meilisearch or Typesense in a few hundred megabytes of RAM with typo tolerance out of the box; the Elasticsearch vs Meilisearch comparison covers that trade. For semantic search over your own documents, Qdrant plus an embedding model. For log search, OpenSearch. Vespa is bigger than all of these in every dimension, including the ones you do not want.

What I'd do

Prototype on the single-node Docker image with 8 GB, write one schema with a BM25 field and an embedding field, and build one rank profile that combines them. If after two weeks the ranking flexibility is solving a problem the smaller tools could not, plan a 3-node deployment or price Vespa Cloud. If you cannot name that problem in one sentence, you did not need Vespa, and Meilisearch would have had you in production a week earlier.