Databases that support vectors

Nearly every database now supports vectors. That’s the honest headline, and it changes the question you should be asking.

It used to be “which vector database should we adopt?” It is now usually “does the database we already run do this?” — and the answer is very often yes.

This page is a directory. It’s grouped by what each thing actually is, because that’s what determines whether it fits your stack.

On completeness and freshness

This covers everything notable as of writing. It will not stay complete: vector support is being added to mainstream databases at a pace that makes any such list a snapshot.

Version numbers and capabilities are deliberately light. Follow the links for current specifics, and check the docs before you commit to anything here.

Start here: you may not need any of them

Under roughly 10,000 vectors, a plain array in memory is genuinely fine — that’s what every language guide on this site does, and it answers in milliseconds. Between 10,000 and about a million, the database you already run is almost certainly enough.

Adding a new datastore is a real, permanent cost: another thing to back up, monitor, secure, upgrade and explain to whoever joins next. Make it earn that. More on the crossover points in chunking and vector databases.

PostgreSQL

The most common answer, and usually the right one.

• pgvector — the standard extension. Adds a vector column type with HNSW and IVFFlat indexes, and cosine, L2 and inner-product operators. Available on essentially every managed Postgres.
• pgvectorscale — TimescaleDB’s extension on top of pgvector, adding a DiskANN-style index for larger collections.
• VectorChord — successor to pgvecto.rs, aimed at higher throughput and larger-than-memory indexes.

Managed Postgres with vector support includes Supabase, Neon, Amazon RDS and Aurora, Google Cloud SQL and AlloyDB (AlloyDB adds a ScaNN-based index), and Azure Database for PostgreSQL.

Why Postgres keeps winning this argument

Your vector can live in the same row as your data. A plain SQL join gets you the chunk text, its document, its author and its permissions in one query. No syncing two systems, no eventual consistency, no orphaned vectors pointing at deleted rows, and DELETE already does the right thing — which matters more than you’d think when a right-to-erasure request arrives.

Other relational databases

Vector support has landed almost everywhere.

Database	Support
MariaDB	Native VECTOR(N) type and VECTOR INDEX using modified HNSW, up to 16,383 dimensions. GA in 11.8 LTS, no extension needed
SQL Server 2025	Native vector type and vector search alongside relational data
Azure SQL Database	Vector functions and storage in the managed service
Oracle Database 23ai	AI Vector Search — VECTOR type, similarity operators, integrated with SQL
MySQL HeatWave	Vector store and in-database similarity search
SingleStore	Vector type with ANN indexing, built for hybrid transactional/analytical work
CockroachDB	Vector indexes on a distributed, Postgres-compatible engine
TiDB	Vector search in a distributed MySQL-compatible database
YugabyteDB	pgvector support on distributed Postgres
ClickHouse	Vector similarity indexes in a columnar analytics database

Embedded and local

• SQLite + sqlite-vec — vector search in a single file, no server. Excellent for desktop apps, mobile and edge. Supersedes the older sqlite-vss.
• DuckDB VSS — an HNSW index extension for DuckDB’s analytical engine.
• LanceDB — embedded, built on the Lance columnar format. Sits between a library and a database, and is strong for multimodal data.
• Chroma — pip install and go. The easiest possible start; also runs as a server.

Document, key-value and wide-column stores

Database	Support
MongoDB Atlas	Atlas Vector Search, with filtering on any document field
Redis	Vector similarity in the Query Engine, plus vector sets. Very low latency, memory-resident
Couchbase	Vector search in the Search service
Apache Cassandra	Vector type and SAI vector index from 5.0
DataStax Astra DB	Managed Cassandra with vector search
Aerospike	Vector Search for very high throughput workloads
Azure Cosmos DB	Vector search including a DiskANN-based index
Firestore	K-nearest-neighbour queries on vector fields
RavenDB	Built-in vector search with automatic embedding generation
ArangoDB	Vector search alongside its graph and document models
SurrealDB	Vector functions and HNSW indexing in a multi-model database

Search engines

If you already run one of these for keyword search, you can do hybrid retrieval in a single system — which is a strong argument for staying put.

• Elasticsearch — kNN search plus mature BM25, and built-in RRF for merging them.
• OpenSearch — the Apache-licensed fork, with k-NN via FAISS, nmslib or Lucene engines.
• Apache Solr — dense vector search on the long-standing Lucene-based engine.
• Vespa — arguably the most capable engine here for large-scale hybrid ranking, and the steepest learning curve.
• Typesense — vector search in a deliberately simple, fast, typo-tolerant engine.
• Meilisearch — AI-powered search on top of its keyword engine.
• Manticore Search — a Sphinx successor with kNN support.
• Algolia — NeuralSearch, combining vector and keyword retrieval as a managed product.

Dedicated vector databases

Built for this from the start. You’re paying for filtered ANN at scale, and the operational cost of another system.

• Pinecone — fully managed, no servers to run. The “just make it work” option.
• Qdrant — open source, Rust, strong and predictable metadata filtering. My usual pick when Postgres isn’t enough.
• Weaviate — open source, with built-in vectorisation modules and a GraphQL-ish API.
• Milvus — open source, built for very large scale, with Zilliz Cloud as the managed version.
• Vald — distributed vector search on Kubernetes, CNCF-adjacent.
• Marqo — generates the embeddings for you, including images.
• Deep Lake — from Activeloop, aimed at multimodal AI datasets.
• turbopuffer — object-storage-backed, optimising hard for cost per vector.

Graph databases

When relationships matter as much as similarity — see the GraphRAG discussion.

• Neo4j — vector indexes queryable from Cypher alongside graph traversals.
• Amazon Neptune Analytics — vector similarity in a managed graph engine.
• TigerGraph — vector search combined with graph analytics.

Warehouses and lakehouses

When the vectors belong next to analytical data you already have.

• BigQuery — VECTOR_SEARCH with indexes, and embedding generation via SQL.
• Snowflake — a VECTOR type and similarity functions, integrated with Cortex.
• Databricks Vector Search — indexes that sync automatically from Delta tables.
• StarRocks — vector indexes in a real-time analytics engine.

Managed cloud services

• Azure AI Search — vector, keyword and hybrid retrieval with strong RAG integration.
• Vertex AI Vector Search — Google’s managed service, formerly Matching Engine.
• Amazon S3 Vectors — vectors stored natively in object storage, up to 2 billion per index, integrating with Bedrock Knowledge Bases and OpenSearch. Optimises for cost over latency: infrequent queries return in under a second rather than milliseconds.
• Amazon OpenSearch Serverless — managed vector collections.
• Amazon MemoryDB — Redis-compatible, in-memory, for very low latency.

Libraries, which are not databases

An important distinction that trips people up. These do nearest-neighbour search and nothing else: no persistence, no filtering, no concurrency, no network API. You supply all of that.

• FAISS — Meta’s library, the reference implementation many databases build on.
• hnswlib — a compact, fast HNSW implementation.
• ScaNN — Google’s, strong on the accuracy/speed frontier.
• Annoy — Spotify’s, memory-mapped and simple.
• Voyager — Spotify’s newer HNSW library for Python and Java.
• USearch — compact, many language bindings.
• NMSLIB — the research library HNSW originated in.

Reach for a library when you want maximum control and are content to own persistence, updates and access control yourself. That last one is the usual reason teams migrate off them: permission filtering is where a bare library stops being viable.

Choosing

If…	Then
Under ~10k vectors	An array in memory. Seriously
You run Postgres	pgvector. Stop reading
You run MySQL, SQL Server, Oracle or MariaDB	Use the native vector support you already have
You run Elasticsearch or OpenSearch	Use its kNN, and get hybrid search free
You run MongoDB or Redis	Atlas Vector Search or the Redis Query Engine
Desktop, mobile or edge	sqlite-vec or LanceDB
Prototyping, want it working today	Chroma
Outgrown Postgres, want open source	Qdrant, Weaviate or Milvus
Don’t want to operate anything	Pinecone, Azure AI Search or Vertex AI
Billions of vectors, cost over latency	Amazon S3 Vectors or turbopuffer
Relationships matter as much as similarity	Neo4j or Neptune Analytics
Vectors belong next to analytics	BigQuery, Snowflake or Databricks

The choice matters less than the fundamentals

Every option here implements the same handful of ANN algorithms, mostly HNSW. At the scale most teams operate, they will all be fast enough, and swapping between them is rarely the thing that fixes disappointing search.

What actually moves the needle: good chunks, hybrid retrieval, reranking, and measuring any of it. Pick the one that fits your stack and spend your attention there.

Next

Chunking and vector databasesWhat these systems do, and when you cross the threshold into needing one.

Choosing an embedding modelThe other half of the decision, and the one that's a migration to change.

Security and privacyFiltering by permission is where the choice actually bites.

Alternatives to vector embeddingsIncluding when you don't need vector storage at all.

References

• Efficient and robust approximate nearest neighbor search using HNSW graphs — Malkov & Yashunin, the algorithm nearly all of these implement
• pgvector — the extension most of the Postgres ecosystem is built on
• ANN Benchmarks — independent recall-versus-speed comparisons across libraries and engines
• DB-Engines ranking — tracks relative popularity of vector DBMSs over time
• MariaDB Vector — a representative example of native support arriving in a mainstream database
• Amazon S3 Vectors — the storage-first approach, and its latency trade-off
• Elasticsearch — kNN search — hybrid retrieval in an engine you may already run
• FAISS — the library much of this ecosystem builds on
• Qdrant — filtering — why filtered ANN is the hard part
• Reciprocal Rank Fusion — merging vector and keyword results, whichever system you pick