# Best Vector Databases for AI Data in 2026, Compared

> Pinecone, Weaviate, Milvus, and Chroma compared for AI data in 2026: pricing, indexes, hybrid search, and how they fit a RAG pipeline.

Source: https://www.erathos.com/en/blog/best-vector-databases-for-ai-data-in-2026
Em português: https://www.erathos.com/blog/best-vector-databases-for-ai-data-in-2026
Published: 2026-09-06
Category: Data Science & AI

![The Best Vector Databases for AI Data](https://cms-media.erathos.com/The Best Vector Databases for AI Data.png)

AI chatbots that answer from your documents, semantic search features, and agents with memory all need a place to store embeddings and find the closest ones fast. That place is a vector database. This guide explains what a vector database does, compares Pinecone, Weaviate, Milvus, and Chroma with current pricing from each vendor's own pages, and shows how data gets into one in the first place.

## What is a vector database, in plain English?

A vector database stores embeddings, which are lists of numbers that represent the meaning of text, images, or audio, and finds the stored records whose numbers are closest to a query. Close numbers mean similar meaning, so you can search by what something means instead of the exact words it contains.

A regular database answers questions like "give me the row where id = 42". A vector database answers "give me the ten documents most similar to this question". It [stores the embedding together with the original record and its metadata](https://www.pinecone.io/learn/vector-database/), and adds the things you expect from a database: create, update, and delete operations, metadata filtering, and scaling across machines.

That last part separates a vector database from a bare vector index like FAISS (Facebook AI Similarity Search). An index only holds the vectors and searches them. A database also manages the records behind the vectors, so you can update a document and filter results by fields like customer or date.

## How do embeddings and similarity search work?

An embedding model turns content into a vector, a long list of numbers. The same model turns a search query into a vector too. The database then ranks stored vectors by distance to the query vector and returns the closest ones.

The model places similar meanings near each other in that number space. "How do I reset my password" and "I can't log in" end up close together even though they share almost no words. A keyword search misses that pair. A vector search finds it.

The flow is symmetric on both sides. At load time, [the embedding model creates vectors for the content you want to index](https://www.pinecone.io/learn/vector-database/), and the database stores them. At query time, the same model embeds the question, and the database compares that vector against everything it stored, using a distance measure such as cosine similarity.

The query vector and the stored vectors must come from the same embedding model. If you switch models, you re-embed everything, because two models place the same sentence at different points in space.

## Why do vector databases use ANN indexes such as HNSW and IVF?

Comparing a query against millions of stored vectors one by one is too slow for a live app. So vector databases use approximate nearest neighbor (ANN) indexes, which find vectors that are almost certainly the closest ones in a small fraction of the time.

The word approximate matters. An ANN index can skip a true neighbor now and then. The share of true neighbors it does find is called recall, and every index trades recall against speed: [the more accurate the result, the slower the query](https://www.pinecone.io/learn/vector-database/).

The two index families you will see everywhere:

- HNSW (Hierarchical Navigable Small World) builds a graph with several layers. Search starts in a sparse top layer, takes big jumps toward the target region, then drops into denser layers for the fine search. The layered design gives [search time that grows logarithmically with collection size](https://arxiv.org/abs/1603.09320v4).
- IVF (inverted file) groups vectors into clusters up front. At query time it only scans the few clusters closest to the query instead of the whole collection.

Index parameters are workload choices, tuning knobs for your data and latency budget. A database supporting nine index types is only better than one supporting three if you need one of the other six.

## How does a vector database fit into a RAG pipeline?

In retrieval-augmented generation (RAG), the vector database is the retrieval half: it stores embedded chunks of your documents and, for each user question, returns the most relevant chunks for the LLM (large language model) to read before it answers.

There are two separate paths, and they run on different schedules.

The ingest path runs whenever your data changes. You extract documents, split them into chunks small enough to embed and read, run each chunk through the embedding model, and write the vector plus the chunk text and metadata (source ID, timestamp, access level) to the database.

The query path runs on every request. The app embeds the user's question, asks the database for the closest chunks, optionally filters by metadata and reranks, then pastes the winning chunks into the prompt.

![RAG query path](https://cms-media.erathos.com/RAG query path.png)

The database only retrieves context. If the ingest path loaded stale or wrong documents, the model will confidently answer from stale or wrong documents. Retrieval quality is set by what you load and how you chunk it, which is why the ingest path deserves as much engineering as the query path.

## Pinecone vs. Weaviate vs. Milvus vs. Chroma: which should you choose?

There is no universal winner. Pinecone is the managed-only option, Weaviate and Milvus are open source with managed clouds, and Chroma is the lightest to start with locally. The table below uses each vendor's own current pricing and docs.

Database

License and code

Hosting

Indexes

Hybrid search and filtering

Free tier

Paid entry

Pinecone

Closed source, managed service only

Serverless on AWS, GCP, Azure; BYOC (bring your own cloud) on Enterprise

Dense, sparse, and full-text indexes; Pinecone picks the ANN algorithm internally

Filter-then-rank, client-side fusion, or dense plus sparse server-side

2 GB storage, 2M write units, 1M read units per month

Builder, $20/month flat

Weaviate

Open source, BSD 3-Clause

Docker, Kubernetes, Weaviate Cloud, AWS and GCP marketplaces

HNSW (default), Flat, Dynamic, HFresh

Vector plus BM25 keyword fusion with a tunable weight; filters apply to hybrid queries

100,000 objects, 1 GB memory, 10 GB disk

Flex, from $45/month

Milvus / Zilliz Cloud

Open source, Apache 2.0

Self-hosted standalone or Kubernetes, Milvus Lite, Zilliz Cloud (Serverless, Dedicated, BYOC)

FLAT, IVF and HNSW variants, SCANN, DiskANN, GPU indexes

Multi-vector hybrid across dense and sparse fields, with scalar filters

Zilliz Cloud: 5 GB storage, 2.5M virtual compute units per month, 5 collections

Zilliz Dedicated, from $16 per million vectors/month (768 dimensions)

Chroma

Open source, Apache 2.0

Local single-node, distributed, Chroma Cloud, BYOC on Enterprise

Vector, full-text, metadata, and sparse-vector search in Cloud

Metadata filters with and/or/in operators, plus document-content filters

Cloud Starter, $0/month plus usage, $5 in credits

Usage-based: $2.50/GiB written, $0.33/GiB/month storage

### Pinecone

Pinecone runs the infrastructure for you and bills by usage. The [Starter plan is free](https://www.pinecone.io/pricing/) with 2 GB of storage, Builder is $20/month flat, and Standard starts at a $50/month minimum with $0.33/GB/month storage, $4 to $4.50 per million write units, and $16 to $18 per million read units depending on cloud and region.

![Pinecone pricing](https://cms-media.erathos.com/Pinecone pricing.png)

_Pinecone pricing plans: Starter, Builder, Standard, Enterprise_

Write units and read units are Pinecone's usage meters. An upsert costs [1 write unit per KB of request](https://docs.pinecone.io/guides/manage-cost/understanding-cost), with a 5-unit minimum. A query costs 1 read unit per GB of the namespace it targets, with a 0.25-unit minimum, so query cost grows with the size of the data partition you search. Idle indexes cost nothing.

You do not pick or tune the index algorithm. Pinecone's ANN pipeline [may use PQ, LSH, or HNSW internally](https://www.pinecone.io/learn/vector-database/), and it makes those choices for you. That is a feature if you want zero index operations, and a dealbreaker if you want control over the recall-speed tradeoff.

Pinecone is a good fit when you want a vector database as a utility: no servers, no index tuning, pay for what you use.

### Weaviate

Weaviate is an [open-source vector database under the BSD 3-Clause license](https://github.com/weaviate/weaviate) that you can run yourself with Docker or Kubernetes, or use as Weaviate Cloud. It can embed your objects at import time with integrated model providers, or accept vectors you computed yourself.

Its index menu is explicit: [HNSW is the default](https://docs.weaviate.io/weaviate/concepts/vector-index), Flat does exact search for small collections, and Dynamic starts Flat and switches to HNSW when a collection passes 10,000 objects.

Hybrid search is a first-class query: it runs a vector search and a BM25 keyword search (BM25 is the classic relevance scoring used by search engines) and fuses the two rankings. An alpha weight [slides between pure keyword at 0 and pure vector at 1](https://docs.weaviate.io/weaviate/search/hybrid), and filters apply on top.

The [managed free tier](https://weaviate.io/pricing) holds 100,000 objects with 1 GB of memory and 10 GB of disk. Paid Flex starts at $45/month, priced by total vector dimensions stored (from $0.00465 per million) plus storage from $0.12/GiB, so your embedding model's dimension count directly moves the bill.

![Weaviate Cloud pricing](https://cms-media.erathos.com/Weaviate Cloud pricing.png)

_Weaviate Cloud pricing: Free and Flex tiers_

Weaviate is a good fit when hybrid search matters, and when you want the same open-source database to run locally, in your cluster, or managed.

### Milvus and Zilliz Cloud

Milvus is an [LF AI & Data Foundation project under Apache 2.0](https://github.com/milvus-io/milvus), built for distributed scale: it runs as a single standalone node, as a Kubernetes-native cluster, or as Milvus Lite for prototyping in a Python process. Zilliz Cloud is the managed version, with Serverless, Dedicated, and BYOC options.

Milvus gives you the widest index menu of the four: [FLAT, IVF\_FLAT, IVF\_PQ, IVF\_SQ8, HNSW and its quantized variants, and SCANN](https://milvus.io/docs/index.md) on CPU, plus DiskANN and GPU indexing. That control lets you choose the recall-speed-memory tradeoff per collection.

Hybrid search runs several ANN searches across fields in one request, dense and sparse together, and Milvus [generates BM25 sparse vectors natively](https://milvus.io/docs/multi-vector-search.md) with an inverted index. Grab and Read AI are among the [deployments Milvus lists publicly](https://milvus.io/use-cases).

The software cost and the service cost are separate. Self-hosted Milvus costs whatever your machines cost. [Zilliz Cloud's free tier](https://zilliz.com/pricing) gives 5 GB of storage and 2.5M virtual compute units per month; Dedicated capacity-optimized clusters start at $16 per million vectors per month, and performance-optimized at $63. Those figures are based on 768-dimensional vectors, so different models change the math.

Milvus is a good fit when you expect billions of vectors, want Kubernetes-native scaling, or need a specific index type the others don't offer.

### Chroma

Chroma is an [Apache 2.0 open-source database](https://docs.trychroma.com/docs/overview/oss) with the smallest step one of the four: install the package, create a collection, add documents. It can embed documents for you or accept your own embeddings, and it runs as a local single-node process, a distributed deployment, or Chroma Cloud.

Filtering is expressive: a where argument matches metadata with [and, or, in, and not-in operators](https://docs.trychroma.com/docs/querying-collections/metadata-filtering), arrays support contains checks, and a separate document filter matches the text itself.

Chroma Cloud [bills pure usage](https://www.trychroma.com/pricing): $2.50 per GiB written, $0.33 per GiB stored per month, $0.0075 per TiB queried, and $0.09 per GiB returned, with $5 of starter credits and a Team plan at $250/month plus usage. Cloud collections currently hold up to 5 million records each.

Chroma's own docs mention that the local open-source version can temporarily lack features that distributed Chroma has, while the team works toward parity. I'd test the deployment mode before shipping it.

Chroma is a good fit for prototypes, single-app RAG backends, and teams who want to start local today and move to a managed cloud later.

## Is pgvector in your existing PostgreSQL a credible alternative?

Yes, for many teams. [pgvector](https://github.com/pgvector/pgvector) is an open-source extension that adds vector types and similarity search to Postgres, so embeddings can join, filter, and transact with the relational data you already have, under the same backups and access control.

By default pgvector does exact search, which returns perfect recall and slows as the table grows. For speed you add an approximate index: HNSW gives a better speed-recall tradeoff, while IVFFlat builds faster and uses less memory.

With an approximate index, [filtering happens after the index scan](https://github.com/pgvector/pgvector). If your filter matches 10% of rows and the index returns its default 40 candidates, on average only 4 survive the filter. pgvector's iterative scan modes fix this by scanning further until enough rows match, at extra cost.

If your source of truth is already Postgres, this is the cheapest option to try first: one extension, no new system to operate, and no sync between your relational data and your vectors. Benchmarking it on your own data and filters answers whether you need a dedicated engine.

## How should you read vector database benchmarks?

Benchmark leaderboards work as methodologies to rerun on your own workload. Copying a ranking straight into a purchase decision skips that step. The numbers depend on the dataset, the vector dimensions, the filters, the hardware, and the configuration each system ran with.

Two useful tools:

- [ANN-Benchmarks](https://ann-benchmarks.com/) compares ANN algorithms by plotting recall against queries per second, with extra plots for index size and build time. It teaches that a speed number means little without its recall number. It compares algorithms, though, and tells you nothing about a managed service's pricing, ingestion, or filtering behavior.
- [VectorDBBench](https://github.com/zilliztech/VectorDBBench) tests whole databases, including Pinecone, Weaviate, Milvus, pgvector, and Chroma, across insertion, search, and filtered search on realistic embedding datasets. Zilliz (the Milvus company) sponsors it, servers run default configuration while clients may be tuned, and results shift between runs.

A benchmark that fits your case still beats one that doesn't: if your queries always carry a tenant filter, a filtered-search result matters more to you than any raw speed chart.

## How does data get into a vector database, and where does ELT fit?

A vector database is a downstream store. The pipeline that feeds it looks like classic ELT (extract, load, transform) with two extra steps at the end: chunking and embedding. Getting this path reliable matters more than most index tuning, because retrieval can only be as good as what was loaded.

A production setup splits the work in two stages.

![How data reaches the vector database](https://cms-media.erathos.com/How data reaches the vector database.png)

Stage one moves source data somewhere dependable. [Erathos syncs a source](https://docs.erathos.com/platform/how-we-move-data) such as PostgreSQL or HubSpot by extracting the data, staging it in temporary cloud storage, loading the warehouse with a bulk COPY, then deleting the temporary files. For freshness, [change data capture (CDC) on a Postgres source](https://docs.erathos.com/connectors/databases/postgresql) takes an initial snapshot and then streams every change from the write-ahead log (the database's running record of changes), so new and updated rows arrive without repeated full extracts.

Stage two is a transform job that reads the new and changed rows from the warehouse, chunks the text, calls the embedding model, and upserts vectors into the vector database. You give each chunk a stable ID derived from its source row, so a re-run updates records instead of duplicating them, and deletes can propagate when a source row disappears. All four databases accept this shape: Weaviate and Chroma take precomputed vectors with IDs and metadata, and a Milvus schema stores the raw text, the vector, and a primary key side by side.

Splitting the stages keeps each one simple to rerun. If you change your chunking strategy or embedding model, you re-run stage two against the warehouse without touching a single source system. If you're building this path, our guide on [building and managing data pipelines](https://www.erathos.com/en/blog/how-to-build-and-manage-data-pipeline?utm_source=blog&utm_medium=organic&utm_content=bydefault&utm_campaign=best-vector-databases-for-ai-data-in-2026) covers the sync side, and the [connector catalog](https://www.erathos.com/en/connectors?utm_source=blog&utm_medium=organic&utm_content=bydefault&utm_campaign=best-vector-databases-for-ai-data-in-2026) lists the sources Erathos can keep in sync.

## The short version

- Vector databases store embeddings and search by meaning. ANN indexes like HNSW make that fast by trading a little recall for a lot of speed.
- Pinecone: managed-only, usage-billed, zero index operations.
- Weaviate: open source, strong hybrid search, priced by vector dimensions in the cloud.
- Milvus: open source, the most index and deployment options, built for large scale.
- Chroma: open source, easiest local start, usage-priced cloud.
- pgvector: try it first if your data already runs through Postgres.
- Whatever you pick, retrieval quality is decided upstream: a reliable sync and a re-runnable chunk-embed-upsert job feed the database everything it knows.

Ready to build the sync side of your pipeline? [Try Erathos free for 14 days](https://app.erathos.com/signup?utm_source=blog&utm_medium=organic&utm_content=bydefault&utm_campaign=best-vector-databases-for-ai-data-in-2026).