Best Vector Databases in 2026: 12 Tools Priced at Real Workload Scale

Pick Pinecone if you want zero infrastructure to manage and you're willing to pay for that. Pick pgvector if your team already runs Postgres and the dataset is under a few million vectors. Pick Qdrant or Milvus if you want to self-host on Apache 2.0 terms and keep the bill close to your own infrastructure cost. Everyone else in this guide sits somewhere between those three answers, and the gap between them is bigger than most comparison pages let on, because headline pricing for vector databases almost never resembles what you pay once a real workload is running.

This guide evaluates 12 platforms on three things most roundups skip: the license each one actually ships under today (several changed in the last two years), what one concrete workload costs across every vendor's own metering model, and the honest total cost of running it yourself versus paying someone else to.

Key Facts

• Organizational AI adoption reached 88% in 2025, per Stanford HAI's 2026 AI Index Report, which is the demand pulling retrieval infrastructure into mainstream budgets rather than R&D sandboxes.
• Redis added AGPLv3, an OSI-approved open source license, as a third option in Redis 8 in 2025, alongside the source-available RSALv2 and SSPLv1 it adopted in 2024 rather than replacing them, per Redis's own license page and The New Stack's coverage.
• Elastic added AGPLv3 as a licensing option for Elasticsearch and Kibana in August 2024, restoring an OSI-approved path after three years under the Elastic License and SSPL, per Elastic's own announcement.
• Milvus shipped version 3.0 in July 2026 under the Linux Foundation's AI & Data umbrella, moving to a lake-native architecture, per the LF AI & Data Foundation's announcement.

Quick Comparison Table

Licensing in 2026: Read This Before You Call Anything "Open Source"

Vector database licensing moved more in the last 24 months than in the category's entire history before that, and getting it wrong in an internal proposal is the kind of mistake a security or legal review catches late. Three products in this guide changed license terms since 2024, and two of them changed direction twice.

Two stories worth knowing before you repeat an old assumption: Redis spent most of 2024 under the Server Side Public License and the Redis Source Available License after dropping its original BSD terms, then added AGPLv3 as a third licensing choice in Redis 8 in 2025, once the Linux Foundation's Valkey fork had already forked the last BSD version. Note that AGPLv3 was added, not substituted: RSALv2 and SSPLv1 are still on offer, so Redis is open source only under the option you pick. Elastic moved the other direction: it left open source for the Elastic License and SSPL in 2021, then added AGPLv3 as a third licensing choice in August 2024, so Elasticsearch and Kibana are open source again if you pick that option, while Elastic's own hosted and serverless products still default to Elastic License 2.0. If a vendor deck or internal wiki still calls Redis "source available only" or Elasticsearch "proprietary," that stopped being the whole picture in 2025 and 2024 respectively, since both now include an OSI-approved option you can choose.

MongoDB never reversed course. The Community Server has run under SSPL since October 2018, a license the Open Source Initiative does not recognize as open source because it imposes service-provider obligations the OSI considers incompatible with its definition. Atlas Vector Search is a separate story again: it's an Atlas-only capability, so even a team self-hosting MongoDB Community Server under SSPL can't get the same vector search feature without moving to Atlas.

Three products never claim open source at all and shouldn't be compared as if they did: Pinecone, Zilliz Cloud (the managed version of Milvus), and Turbopuffer are proprietary, closed-source, managed-only products. There's no license story to get wrong here, just a buying decision, which is honestly the simpler position to be in.

For the deeper mechanics of how retrieval actually feeds a model's context window, see what retrieval-augmented generation is and how embeddings turn content into vectors.

What 1 Million Vectors Actually Costs: One Workload, 12 Bills

Here's the workload we priced identically across every vendor: 1 million vectors at 1,536 dimensions (the size OpenAI's text-embedding-3-large and several competing embedding models produce), which comes to roughly 6 GB of raw float32 vector data and 10 to 12 GB once you add typical HNSW index overhead and metadata. On top of that: 500,000 read queries a month and 100,000 write operations a month, which is a realistic mid-size RAG application serving a few hundred concurrent users, not a toy demo and not a hyperscale deployment.

Where a vendor doesn't publish a rate, the table says so rather than guessing.

The flip worth remembering: at this modest a workload, the "expensive-looking" self-hosted options (Milvus, pgvector) are the cheapest line items, while MongoDB Atlas Vector Search and Redis Cloud, the two platforms most teams assume are cheap because they're add-ons to a database they already run, carry the highest minimums in the table because of tier floors and separate metering, not because the workload itself is large. Budget for that floor before assuming vector search is "basically free since we already pay for the database."

Self-Hosted Versus Managed: The Real Decision

The license table above answers "can I self-host this." It doesn't answer the harder question of whether you should. Nine of the twelve tools here (Weaviate, Qdrant, Chroma, Milvus, pgvector, Redis, Elasticsearch, Vespa, LanceDB) are genuinely self-hostable under permissive licenses, leaving Pinecone, MongoDB Atlas Vector Search, and Turbopuffer as managed-only. Most teams that could self-host still shouldn't, at least not on day one.

The honest total cost of "free" self-hosted Qdrant or Milvus includes the hours someone on your team spends patching, resizing, and debugging index corruption at 2 a.m., and that person's fully loaded cost almost always outweighs what a managed tier would have charged for a workload this size. Self-hosting makes sense once you have a platform team already carrying that load for other services (so vector search is marginal, not additive) or once your scale has grown past the point where a managed vendor's margin stops looking reasonable, typically well north of the 1 million vector workload priced above. For a technical founder evaluating this for the first time, start managed, measure the real bill for three months, and only migrate to self-hosted once the math clearly favors it. The same logic that governs any build versus buy versus integrate decision applies here: the cheapest line item on a pricing page is rarely the cheapest total cost once you count the team's time.

If you do self-host, budget for the role, not just the server: a data engineer or platform engineer who already owns your data infrastructure is the right owner, not a feature team bolting it on as a side project.

The 12 Tools

1. Pinecone, the zero-ops default

Pinecone popularized the fully managed, serverless vector database category, and it remains the fastest path from an API key to a production index. There's no self-hosted version at any tier, the open-source "Pinecone Local" container is explicitly a local development and testing tool, not a production deployment path. The free Starter tier covers 2 GB of storage, which is enough for early prototyping but not much past that. If the bill or the missing self-hosted option is what's pushing you away, the Pinecone alternatives guide prices 12 replacements against one workload and covers what migrating takes.

2. Weaviate, hybrid search done natively

Weaviate combines vector similarity with keyword (BM25) search and structured filtering in one query, which matters for any RAG application where pure semantic similarity misses exact-match terms like product SKUs or legal citations. The core database is BSD-3-Clause, genuinely open source, while a handful of enterprise-only modules sit under a separate commercial license. Pinecone vs Weaviate compares it directly with Pinecone, and the Weaviate alternatives guide covers what you'd lose by leaving it.

3. Qdrant, the Rust engine for self-hosters

Qdrant is written in Rust, ships under Apache 2.0, and its free Cloud tier (0.5 vCPU, 1 GB RAM, 4 GB disk) is one of the more generous entry points in this category for a managed option. The gap is transparency: Qdrant Cloud's Standard and Premium tiers are genuinely usage-based, but no per-unit rate appears on a public page anywhere, you need the calculator or a sales call to get a real number. Pinecone vs Weaviate vs Qdrant prices the three at two workload sizes, and the Qdrant alternatives guide covers 11 other options.

4. Chroma, the fastest laptop-to-cloud path

Chroma is the vector database most developers meet first, usually inside a LangChain or LlamaIndex tutorial, because pip install chromadb gets you a working local instance in seconds. Chroma Cloud extends that same API to a managed service with transparent per-operation pricing (writes, storage, queries, egress all billed separately), though the jump from the free Starter plan to the $250/mo Team plan is steep for a team that just needs SOC 2 and real support. The Chroma alternatives guide lists the signs that you've outgrown it.

5. Milvus and Zilliz Cloud, open source at real scale

Milvus is the most production-tested open-source vector engine in this guide, an Apache 2.0 project under the Linux Foundation's AI & Data umbrella (not controlled by a single vendor, which matters for vendor-lock-in-averse buyers), with version 3.0 shipping a lake-native architecture in July 2026. Zilliz Cloud is the proprietary managed version run by Milvus's primary corporate contributor, pricing by compute unit (CU) rather than a flat rate, with a free tier covering 5 GB storage and 2.5M vCUs a month. Chroma vs Qdrant vs Milvus compares the three open-source engines at prototype, production, and large scale.

6. pgvector, when Postgres is already the answer

pgvector turns any Postgres database into a vector store under the same permissive PostgreSQL License the database itself ships with. For teams already running Postgres for application data, it means one fewer system to operate, back up, and secure, not a new vendor relationship at all. The honest limitation: recall and query speed trail purpose-built engines once a collection grows past a few million vectors, especially under high-concurrency write loads. pgvector vs Pinecone vs Weaviate prices the same workload at startup and production scale to show where that limit falls.

7. Redis, vector search bolted onto a cache you already run

Redis 8 added native vector search to a database most engineering teams already operate for caching and session storage, and relicensed back to AGPLv3 in the same release. If vector search is genuinely incremental to a Redis deployment you're already paying for, the sub-millisecond read latency is hard to beat. If you're standing up Redis specifically for vector search, the Pro tier's $200/mo minimum (required for production-grade vector workloads past the tiny Essentials tier) makes it one of the pricier options here for a vector-only use case.

8. MongoDB Atlas Vector Search, for Atlas-committed teams

MongoDB's Community Server self-hosts under SSPL, but Atlas Vector Search specifically is an Atlas-only, fully managed capability, you can't replicate it on a self-hosted SSPL deployment. The billing structure is the thing to plan for: a base Atlas cluster and a dedicated Vector Search node bill as two separate line items, so the real minimum for a production workload is the sum of both, not either one alone.

9. Elasticsearch, vector search inside the stack you already run for logs

Elasticsearch added dense vector fields and approximate nearest-neighbor search to a database most platform teams already run for logging, observability, or full-text search. As of August 2024 you can run it under AGPLv3, genuinely open source again, though Elastic's own hosted and serverless offerings default to Elastic License 2.0. On Elastic Cloud Serverless, a vector-search-heavy workload tends to land closer to $150 to $200 a month than to the near-zero cost some teams expect from "just adding a field."

10. Vespa, built for Yahoo-scale ranking

Vespa predates most of this category by a decade. Yahoo (now part of Verizon's media group lineage) open-sourced it under Apache 2.0, and it's built from the ground up for combining vector search with complex ranking functions at massive scale, the kind of workload large ad-tech and search companies run. That power comes with the steepest learning curve in this guide; Vespa's configuration model assumes you're comfortable with distributed systems concepts most teams haven't needed to learn yet.

11. LanceDB, multimodal search on a lakehouse-native format

LanceDB is built on the Lance columnar format, also Apache 2.0, which doubles as a data lake table format, not just a vector index. That makes it a genuine fit for teams doing multimodal search (text, images, video embeddings together) who also want their vector data queryable as a first-class table in a data lake. LanceDB Cloud is still in beta with no public rate card as of this writing, so budgeting for the managed option means a sales conversation, not a pricing page.

12. Turbopuffer, cheap storage for cold, high-volume vectors

Turbopuffer is built directly on object storage (the same class of storage as S3), which is how it keeps storage costs low for large, infrequently-queried collections, the opposite profile from a hot, low-latency cache like Redis. It's proprietary and managed-only, with three tiers starting at a $16/mo minimum, scaling to $256/mo and then a $4,096/mo-plus enterprise floor with a 35% usage premium. The exact per-GB and per-query rates live only in Turbopuffer's JavaScript pricing calculator, not on the static page, so budget from the tier minimums and confirm exact usage costs with their calculator before committing.

How to Choose: Decision Framework

For the broader question of how retrieval fits into an AI agent's working memory rather than just a search backend, see how AI agents use retrieval-augmented generation and how agent memory works. If you're choosing infrastructure to support agent observability once retrieval is in production, the best AI agent observability tools is a useful next read, and teams weighing fully open-source agent stacks should see the best open-source AI agent frameworks.

What to Do Next

Don't pick a vector database from a comparison table alone, including this one. Take your actual embedding dimension, your actual query volume, and your actual write pattern, and run the same back-of-envelope math this guide did against the two or three vendors that fit your license and self-host preferences. Most teams get this decision wrong in one of two directions: over-provisioning a dedicated vector database before pgvector would have been enough, or under-provisioning a managed tier that hits its $200-a-month floor the moment they turn on production traffic. Price the real workload first, then pick the tool, not the other way around. Two neighboring decisions need the same treatment: the model that produces the vectors, covered in the embedding models roundup, and the retrieval layer on top, covered in the RAG tools roundup.

For the vocabulary this guide assumes, including what a vector database actually is and how it relates to semantic search, those glossary entries cover the fundamentals in plain language.