The Vector Database Landscape

Every tool below solves the same core problem — given a query vector, find the nearest stored vectors quickly — but each one bolted that capability onto a different starting point, and that starting point still shapes what it is good at.

The table below compares deployment model, index types, filtering, hybrid search, quantization, licence and framework support across every engine named above. It is a feature inventory, not a verdict — performance, pricing and cloud availability are compared on Comparing Vector Databases, which also carries the per-engine strengths and weaknesses. Framework support was checked against each framework’s own integration list: LangChain’s vector store integrations page, Spring AI’s vector store documentation, and LangChain4j’s embedding stores page.

Licences follow the same pattern as everywhere else in this section: FAISS, sqlite-vec, Qdrant, Milvus, Chroma, LanceDB, OpenSearch, Solr, Lucene and Cassandra are permissively licensed (MIT or Apache 2.0); Weaviate is BSD-3-Clause; pgvector uses the PostgreSQL licence; Pinecone and Oracle AI Vector Search are proprietary; Elasticsearch, Redis and MongoDB use source-available or dual/triple licences (ELv2/SSPL/AGPLv3, AGPLv3/RSALv2/ SSPLv1, and SSPL respectively); and Neo4j’s Community edition is GPLv3 with a commercial Enterprise tier. The full per-engine breakdown, with dates and links, is on Comparing Vector Databases.

Every row in the table above speaks a different query language for what is conceptually the same operation: find the k vectors nearest a query vector, optionally filtered, optionally blended with a lexical score. A SIMILARITY SEARCH written for one engine has to be rewritten by hand for another — there is no SQL-92-style standard that a vector query compiles against the way relational SQL does.

This gap has been a recurring topic of community and industry discussion for several years, under names such as "Vector Query Language" or "VQL" — a proposed, illustrative idea for what a portable vector query surface could look like, not a ratified standard with a single official specification. No engine implements the sketch below as written; it exists to make the portability problem concrete, not to describe a product.

A conceptual VQL-style data model treats a collection as a named set of records, each with a vector plus arbitrary scalar attributes — deliberately close to what every purpose-built engine and SQL extension above already exposes, just without a shared syntax for expressing it. A similarity search reads, in illustrative pseudo-syntax:

Filtered and thresholded search compose the same clause with an ordinary predicate and a distance cutoff, mirroring what pgvector expresses in a WHERE clause and Qdrant expresses as a payload filter:

A HYBRID SEARCH clause would fold lexical and vector scoring into one statement with explicit weights. Today that fusion is spelled differently everywhere: some engines build it in, each with its own syntax (Qdrant’s RRF fusion query, Elasticsearch’s rrf retriever, Redis’s FT.HYBRID, MongoDB’s $rankFusion), while the rest — pgvector, sqlite-vec, Lucene and Neo4j among them — leave the two queries and their fusion to the application:

RANGE SEARCH would return every vector within a radius rather than a fixed count — the same shape as FAISS’s range_search, pgvector’s <→ used in a WHERE clause, and Redis’s VECTOR_RANGE:

Batch search (many query vectors in one call, as FAISS’s search already does for a whole matrix at once) and vector-valued functions and aggregations round out the sketch: an AVG over a group of vectors would return their centroid, and a GEOMETRIC_MEDIAN aggregate would return the vector minimizing total distance to the group — a robustness improvement over the centroid when a group contains outliers — illustrative of the kind of vector-native aggregation a query language could offer, analogous to AVG/MEDIAN over scalar columns today.