Best Vector Database in 2026: pgvector vs Qdrant vs Pinecone vs Weaviate (Compared)

pgvector is the best vector database for most product teams already on Postgres; Qdrant wins when filtered vector retrieval is the hard part; Pinecone wins when zero-ops matters most; and Elasticsearch wins when keyword search is still the core product. Published paid entry points verified on July 30, 2026 run from $5 per month for Redis Essentials to $99 per month for Elastic Cloud Hosted Standard, but the wrong data model costs more than the subscription.

The best vector databases at a glance

The safest default is to keep vectors beside the application data until that arrangement fails a measured retrieval requirement. A dedicated vector database can improve filtered search, scale, or operating simplicity, but it also creates a second durable data system that needs synchronization, backups, permissions, and incident ownership.

All prices below were verified on the vendors' live pricing pages on July 30, 2026. "Starting price" is the lowest published entry point, not a promise that the tier can carry every production workload.

The shortest decision rule is architectural:

• If the source of truth is Postgres, start with pgvector.
• If a dedicated open-source engine is justified, choose Qdrant.
• If eliminating database operations is worth more than minimizing the bill, choose Pinecone.
• If the workload is large and uneven, price turbopuffer against Pinecone.
• If hybrid relevance needs a configurable product layer, choose Weaviate.
• If multi-vector scale is the hard problem, choose Zilliz Cloud or operate Milvus with a team that owns distributed systems.
• If the application already lives in MongoDB, Elasticsearch, or Redis, use that system's vector search before adding a second database.
• If the job is a local prototype, choose Chroma, then make a separate production decision.

The choice flips on one requirement. pgvector loses when filtered approximate search cannot return enough candidates within the latency budget. Qdrant loses when nobody wants to operate another service and Cloud pricing cannot be forecast without sizing. Pinecone loses when usage units or control requirements outweigh its operational savings. Elasticsearch loses when the organization is buying an entire search platform for a narrow similarity feature.

How these vector databases were picked

A vector database stores embeddings, which are numeric representations of text, images, audio, or other data, and retrieves nearby items by similarity. That definition is easy. The production decision is not.

Ten products made the list because each wins a distinct workload. The roster stops where another product would repeat a decision already covered. Each product was evaluated on seven constraints that are expensive to reverse:

• Data gravity: where the canonical document, user, permission, and business records already live.
• Filtered recall: whether the engine can return enough relevant results after tenant, permission, geography, status, or time filters are applied.
• Hybrid retrieval: how it combines dense semantic similarity with sparse or keyword matching.
• Write behavior: how quickly an update becomes searchable and what happens during indexing, cache warming, or failover.
• Operating burden: whether the team owns replicas, upgrades, backups, capacity, index memory, and incident response.
• Pricing unit: storage, read and write units, logical bytes, cluster resources, support commitment, or a base subscription.
• Exit cost: whether leaving means changing one extension, migrating an index, or rebuilding a synchronization path between two databases.

The products were priced and analyzed, not represented as hands-on load-tested. Vendor benchmarks are not interchangeable because dimensions, recall targets, filters, hardware, index settings, and data distributions change the result. A benchmark without those controls is an advertisement with a stopwatch.

The original finding from this comparison is simple: there is no responsible universal vector-count threshold for migration. Move when the current system fails a measured service level in filtered recall, latency, write visibility, index memory, or operating burden. A team with demanding permission filters can outgrow an architecture before a team with a much larger unfiltered corpus.

1. pgvector: best overall for teams already on Postgres

pgvector is the best vector database for most application teams because it adds similarity search to the Postgres system they already secure, back up, query, and understand. It keeps embeddings beside customers, documents, permissions, and transactional records, which removes an entire synchronization boundary.

The concrete fit is a B2B SaaS product that stores documents, account membership, entitlements, and audit records in Postgres. Retrieval can join or filter against the same relational data instead of copying authorization metadata into another service and hoping every update arrives before the next query. That architectural simplicity often matters more than winning a synthetic nearest-neighbor benchmark.

pgvector supports exact and approximate nearest-neighbor search, works with Postgres 13 and later, and keeps the normal Postgres advantages: ACID transactions, point-in-time recovery, JOINs, replicas, and familiar monitoring. It offers two approximate index families:

• HNSW, a multilayer graph index, gives a better speed-recall tradeoff but builds more slowly and uses more memory.
• IVFFlat, an inverted-file index, builds faster and uses less memory but gives up query performance at a comparable recall target.

HNSW is the reasonable first production index when retrieval latency matters. IVFFlat earns consideration when build time, memory, or bulk-load workflow dominates. Neither choice removes the need to measure recall against the application's own filters.

The wall appears in filtered approximate search. pgvector applies filters after scanning an approximate index. Its documentation gives a sharp example: if a condition matches 10% of rows and HNSW uses its default hnsw.ef_search value of 40, only four rows match on average. A request for the top 10 can therefore return fewer than 10 results even though relevant rows exist.

Version 0.8.0 added iterative index scans, which continue scanning until enough filtered results are found or a scan cap is reached. That is a meaningful fix, not a free lunch. More scanning consumes more latency and work. Partial indexes help when filters have a few stable values. Partitioning helps when many tenants or categories justify physical separation. A dedicated engine becomes compelling when those controls still cannot satisfy the service level.

Dimension limits are also explicit. HNSW and IVFFlat index vector values up to 2,000 dimensions, halfvec up to 4,000, and bit up to 64,000. The unindexed vector type can store up to 16,000 dimensions. Most text embedding models fit comfortably, but a high-dimensional or multi-vector design should check the index representation before committing.

Hybrid retrieval is capable but assembled rather than packaged. pgvector combines with Postgres full-text search, so a team can run semantic and lexical retrieval in the same database and fuse the rankings. The advantage is control and one data model. The cost is that relevance tuning, rank fusion, and evaluation remain application work.

Best for: SaaS products, internal tools, and RAG systems whose canonical data already lives in Postgres
Standout: One transactional data model for vectors, permissions, relational filters, and application records
Pricing: pgvector is open-source software with no vendor subscription tier. The bill is the Postgres infrastructure, storage, replicas, backups, and engineering time already attached to the application database.
Free trial: Not applicable; the extension is open source

A safe pgvector production sequence

The top pick only stays the top pick if retrieval cannot starve the application database. Build the measurement loop before turning similarity search into a critical path.

1. 1

   Install the extension on the production Postgres version

   Confirm the deployment runs Postgres 13 or later, install pgvector through the provider or package system, and enable it with CREATE EXTENSION vector. Treat the extension version as part of the database release, not an application dependency that drifts independently.

2. 2

   Store the source record and embedding together

   Keep the embedding on the row whose permissions and lifecycle govern it, or on a child row with a foreign key to that source. Store the embedding model identifier so a future model migration can distinguish old vectors from new ones.

3. 3

   Start exact, then add HNSW

   Use exact search on a representative sample to create a recall baseline. Add HNSW only after that baseline exists, then tune the candidate list against a fixed evaluation set instead of chasing latency alone.

4. 4

   Test the hardest permission filter

   Run the least-selective and most-selective tenant or permission filters, not only the unfiltered query. If approximate search returns too few rows, enable iterative scans and measure the extra latency before reaching for a new database.

5. 5

   Separate the workload only when a service level fails

   Move to Qdrant, Pinecone, or another dedicated engine when filtered recall, index memory, write load, or query latency misses a defined target after indexing and partitioning work. Preserve Postgres as the source of truth and design the synchronization contract explicitly.

If the backend itself is still undecided, settle that first. The Supabase versus Firebase comparison explains why the application data model can decide this vector choice before retrieval traffic exists.

2. Qdrant: best dedicated open-source vector database

Qdrant is the best dedicated vector database for teams that need complex metadata filters, open-source control, and a cleaner operational shape than a large self-hosted Milvus deployment. It is the first system to evaluate when pgvector's filtered recall is the measured failure.

The concrete use case is a multi-tenant knowledge product where every query must combine semantic similarity with nested conditions such as account, geography, document type, status, and access group. Qdrant payloads are arbitrary JSON, and its filter model supports must, should, must_not, ranges, matches, and nested keys. That makes the authorization-shaped retrieval query part of the engine rather than a post-processing step.

Qdrant also supports dense and sparse hybrid retrieval. Its multi-stage query system, available from version 1.10.0, can fuse result sets with reciprocal rank fusion, or RRF, and distribution-based score fusion, or DBSF. RRF combines result order rather than raw scores, which avoids pretending that lexical and dense-vector scores share a common scale.

The product comes in two honest forms. Qdrant OSS gives full software control and moves the infrastructure burden onto the team. Qdrant Cloud removes most of that work but keeps resource-based cluster sizing. On Qdrant's live pricing page, the Free Tier is a single node with 0.5 vCPU, 1 GB RAM, and 4 GB disk. Standard uses usage-based pricing for dedicated resources and adds vertical and horizontal scaling, highly available setups, backup and disaster recovery, and a 99.5% uptime SLA.

Premium requires a minimum spend that Qdrant does not publish. It adds SSO, private VPC links, extra support, and a 99.9% uptime SLA. Hybrid Cloud runs Qdrant's management plane over the customer's infrastructure, while Private Cloud targets isolated or air-gapped environments; both require a sales conversation.

The price wall is forecasting. Standard billing depends on vCPU, memory, cluster storage, backup storage, and paid inference tokens, billed hourly. That model is understandable after a sizing exercise, but it prevents a responsible one-number monthly quote. A procurement team should use the calculator with the production vector dimensions, replicas, storage, and write rate, then test a smaller and larger cluster to expose the step-up.

The architecture wall is the same as every dedicated engine: Qdrant becomes a derived data store. The source record still lives elsewhere. Deletion, permission changes, re-embedding, disaster recovery, and replay all need a contract. Qdrant wins only when its retrieval behavior repays that extra system.

Best for: Dedicated vector retrieval with nested metadata, tenant, or permission filters
Standout: Expressive payload filtering plus open-source and managed deployment choices
Pricing: OSS is open source. Cloud Free is free forever with 0.5 vCPU, 1 GB RAM, and 4 GB disk. Standard is usage-based and billed hourly by resources. Premium requires a minimum spend and is priced on request. Hybrid Cloud and Private Cloud are quote-based.
Free trial: Free Cloud Tier

3. Pinecone: best zero-ops managed vector database

Pinecone is the best vector database when a small engineering team values a fully managed retrieval service more than open-source control or the lowest possible infrastructure cost. It turns capacity, replicas, backups, and index availability into a vendor responsibility, which can be the rational purchase for a product whose differentiator is not database operations.

The concrete fit is a funded product team shipping semantic search or RAG without a database specialist. Pinecone provides dense, sparse, and full-text index options, on-demand serverless infrastructure, backup and restore on production plans, and enterprise deployment controls. The value proposition is not that storage disappears. It is that the team buys a retrieval service with a clear API and fewer operational surfaces.

The live Pinecone pricing structure has four tiers. Starter is free and includes up to 2 GB of database storage, 2 million write units per month, 1 million read units per month, and 1 GB of egress. Builder is a flat $20 per month with up to 10 GB storage, 5 million write units, 2 million read units, and 10 GB egress.

Standard carries a $50 monthly minimum applied to usage and offers a three-week trial with $300 in credits. Database storage is $0.33 per GB per month. Write units cost $4 to $4.50 per million and read units cost $16 to $18 per million, depending on cloud and region. Egress is $0.10 per GB after 100 GB included each month. Import costs $0.25 per GB, backup storage $0.10 per GB per month, and restore $0.15 per GB.

Enterprise raises the monthly minimum to $500. Storage remains $0.33 per GB per month, while writes rise to $6 to $6.75 per million and reads to $24 to $27 per million. The tier adds a 99.95% uptime SLA, BYOC, private endpoints, customer-managed encryption keys, audit logs, SCIM, HIPAA compliance, and Pro support.

Hybrid search is capable but has a technical catch worth naming. Pinecone documents three patterns: one index containing dense and sparse vectors, separate dense and sparse indexes, or a document schema combining vector and full-text fields. Pinecone recommends the single-index vector pattern for most vector-API use cases because it makes one request and keeps the vectors linked.

The single-index pattern does not normalize sparse and dense score ranges automatically. Dense dot-product values are roughly bounded from -1 to 1 for normalized embeddings, while BM25-style sparse scores are unbounded and can dominate. The application must apply explicit alpha weighting. That same pattern cannot run sparse-only queries or use integrated embedding and reranking. Separate indexes restore those options but add two queries, explicit linkage, merge, deduplication, and reranking.

The wall is cost observability. Pinecone publishes the unit prices, which is better than hiding them, but a team still needs representative reads, writes, storage, backup, and egress. An attractive $50 minimum can become a different bill under sustained query traffic or frequent re-embedding. Instrument units per customer and per workflow before a launch makes aggregate usage impossible to attribute.

Best for: Small teams that want managed production retrieval without operating a vector cluster
Standout: The cleanest path from API integration to a vendor-operated production service
Pricing: Starter is free. Builder is $20 per month flat. Standard has a $50 monthly minimum with usage rates on top. Enterprise has a $500 monthly minimum and higher read/write rates. Database storage is $0.33 per GB per month on Standard and Enterprise.
Free trial: Starter is free; Standard includes a three-week trial with $300 credits

4. turbopuffer: best for large, uneven serverless workloads

turbopuffer is the best specialist option for a large retrieval corpus whose query activity is uneven enough to make always-on memory unattractive. Its commercial model is tied to logical storage, writes, and bytes queried, while every plan includes the database features.

The concrete fit is a product with many isolated customer namespaces, a long tail of cold data, and bursts of retrieval against a smaller active set. The query API supports approximate and exact nearest-neighbor search, BM25 full-text search, sparse vectors, filters, ordering, lookups, aggregations, and multi-query retrieval. Hybrid search can run vector and BM25 branches together and fuse them with RRF.

turbopuffer pricing begins with Launch at a $16 monthly minimum. Scale raises the minimum to $256 and adds a HIPAA-ready BAA, SSO, audit logs, IP allowlisting, a private Slack channel, and 8-to-5 support. Enterprise requires at least $4,096 per month and adds a 35% usage premium. It brings single tenancy, BYOC, private networking, per-namespace customer-managed encryption keys, 24/7 support, and a 99.95% uptime SLA.

The unit model deserves careful reading. After a February 2026 change, the base queried-data rate is $1 per PB and the minimum billable data per query is 1.28 GB. Filterable attributes are billed once per vector column for writes and storage, while non-filterable attributes are stored once regardless of vector-column count. Two schemas with the same document count can therefore cost differently when one marks many attributes as filterable or adds another vector column.

The named limitation is write visibility during significant updates. turbopuffer says more than 99.8% of queries return consistent data. Rare scaling or failover can produce about 100 ms of staleness. Once a namespace has more than 128 MiB of outstanding writes, further writes may remain invisible until they are indexed and loaded into cache. The documented delay can be tens of seconds for a small namespace and tens of minutes for a large one, with up to about one hour of staleness after significant writes.

That behavior is acceptable for a knowledge corpus updated in batches and unacceptable for a workflow where revoking access or publishing an urgent change must affect the next query. The product needs an explicit freshness service level, not a generic "eventually consistent" label.

Aggregations have another boundary: turbopuffer does not recommend them for latency-sensitive workloads on namespaces above 1 million documents. Use it as a retrieval engine. Do not quietly turn it into the analytical database because the API can count and group.

Best for: Large multi-tenant corpora with uneven access and a team comfortable with byte-based billing
Standout: Broad vector, BM25, sparse, and hybrid retrieval with low entry commitment
Pricing: Launch has a $16 monthly minimum. Scale has a $256 monthly minimum. Enterprise requires at least $4,096 per month plus a 35% usage premium. Storage, writes, and queried bytes determine usage above the commitment.
Free trial: No public trial is listed on the pricing page

5. Weaviate: best managed hybrid-search toolkit

Weaviate is the best vector database for teams that want hybrid retrieval, configurable relevance, multi-tenancy, and managed deployment in one product rather than assembling every search stage in application code. It behaves more like a retrieval platform than a thin nearest-neighbor service.

The concrete use case is a multi-tenant support or commerce search product where exact phrases, semantic similarity, recency, and tenant isolation all influence rank. Weaviate hybrid search fuses vector results with BM25F keyword results. The application can change the keyword/vector balance through alpha, choose a fusion method, inspect score explanations, apply filters, and boost the fused pool by property or decay.

The managed Weaviate Free plan costs $0 forever and includes 100,000 objects, 1 GB memory, 10 GB disk, one collection, and up to three tenants. It is enough to evaluate data modeling and relevance, but it has no replication and only best-effort availability.

Flex starts at $45 per month on a shared cluster. It is pay-as-you-go with no commitment and includes replication, RBAC, 7-day backup retention, a 99.5% uptime target, and next-business-day Severity 1 support. Premium starts at $400 per month under a prepaid commitment and offers shared or dedicated deployment, 30-day shared or 45-day dedicated backup retention, SSO/SAML, up to 99.95% uptime, and support as fast as one hour for Severity 1.

Hybrid search and multi-tenancy are present across all three plans. That matters because a team can validate the retrieval model on Free without discovering that the core query shape sits behind an enterprise tier. The paid decision is about capacity, reliability, backups, security, regions, and support.

The wall is configuration surface. A relevance platform offers more knobs because somebody must own them. An alpha value, fusion method, tokenizer, filter, and boost rule can improve results, but they can also create a ranking system no one can explain six months later. Store every relevance change with an evaluation result and rollback path.

The second wall is the floor jump. Flex at $540 per year is approachable. Premium begins at $4,800 per year, nearly nine times the minimum, before workload variation. The higher tier makes sense for SSO, stronger support, longer backups, regions, or dedicated deployment. It should not be purchased simply because "production" sounds like Premium.

Best for: Multi-tenant products that need tunable lexical and semantic relevance
Standout: Configurable BM25F and vector fusion inside a managed retrieval platform
Pricing: Free is $0 forever. Flex starts at $45 per month. Premium starts at $400 per month for shared or dedicated deployment. Usage-based embedding and Query Agent services are separate.
Free trial: Free forever managed tier

6. Zilliz Cloud and Milvus: best for very large or multimodal collections

Zilliz Cloud is the best managed vector database when collection scale, multiple vector fields, or multimodal retrieval is the central engineering problem; Milvus is the open-source engine underneath that choice. The managed product earns its premium by removing a substantial distributed-systems burden.

The concrete fit is a product catalog with semantic text vectors, sparse keyword vectors, and image vectors on the same items. Zilliz Cloud can run several ANN searches across those fields, then rerank the combined results. Its documented hybrid example uses dense text, built-in BM25 sparse text, and dense image vectors in one collection.

The Zilliz Cloud Free plan costs $0 and includes 5 GB storage, 2.5 million vCUs per month, and up to five collections. Standard starts at $0 per month for Serverless. The pricing page displays the Dedicated starting label as "From $126/GB/month." Standard and Enterprise both offer a 30-day trial.

Enterprise starts at $197 per month for Dedicated and adds a 99.95% uptime SLA, audit logs, SSO, granular RBAC, multi-replica scaling, private endpoints or VPC peering, and enterprise support. Business Critical is quote-based and targets regulated or mission-critical deployments with stronger resilience and security.

The dedicated cluster choices expose why this product belongs at the scale end of the list. A performance-optimized compute unit is described around 2 million 768-dimensional vectors, capacity-optimized around 8 million, and tiered-storage around 40 million. The published starting indicators are $63, $16, and $5 per million vectors per month respectively. Those are shape estimates, not a substitute for a proof of concept.

The wall is operational complexity when self-hosting Milvus. Large collections, multiple indexes, replicas, compaction, storage, upgrades, and recovery create a real platform. Running Milvus because the software is open source can cost more than Zilliz Cloud when no team already owns that platform work.

The second wall is procurement clarity. Zilliz publishes useful starting points, but a production estimate still depends on cluster type, compute units, replicas, storage, workload, and plan. The calculator's shape must travel with any quoted latency or cost.

Best for: Very large collections, multimodal data, and several dense or sparse vector fields
Standout: Managed Milvus with multi-vector hybrid search and scale-specific cluster shapes
Pricing: Free is $0. Standard Serverless starts at $0 per month, while the page displays Standard Dedicated from $126/GB/month. Enterprise Dedicated starts at $197 per month. Business Critical is custom.
Free trial: Free plan; Standard and Enterprise offer a 30-day trial

7. MongoDB Atlas Vector Search: best when application data already lives in MongoDB

MongoDB Atlas Vector Search is the best vector option for a MongoDB application because it indexes embeddings beside the documents that already own their fields and lifecycle. It follows the same data-gravity logic that makes pgvector the default for Postgres.

The concrete fit is a catalog, content platform, or agent system whose source objects already live as MongoDB documents. The $vectorSearch aggregation stage can prefilter those documents before semantic search, so category, account, locale, availability, or other fields remain part of one query surface.

Atlas Free costs $0 and provides 512 MB with shared compute. Flex costs $0.011 per hour, is capped at $30 per month, and provides up to 5 GB with shared compute. Dedicated starts at $0.08 per hour or $56.94 per month for 10 GB storage, 2 GB RAM, and two vCPUs.

The vector capability has exact boundaries. $vectorSearch accepts vectors up to 8,192 dimensions and runs on Atlas 6.0.11 or later. It cannot appear inside $facet or $lookup. Starting with MongoDB 8.0, it can run inside $unionWith. Those aggregation constraints matter when a team assumes every ordinary pipeline shape can wrap vector retrieval.

Search can also move onto dedicated Search Nodes to isolate it from database compute. Atlas supports two to 32 Search Nodes and bills each node hourly by tier. Network transfer between the Search Nodes and database nodes appears at the cluster level. That separation solves a noisy-neighbor problem by introducing another capacity and cost surface.

The wall is paying for MongoDB when the application does not otherwise need MongoDB. Atlas Vector Search is an excellent reason to stay, not a strong reason to migrate a relational application. Choosing it for vectors alone imports document-model, cluster, and search-node decisions that pgvector or a dedicated engine may handle more cleanly.

Best for: Existing MongoDB Atlas applications that want semantic search without another data store
Standout: Vector prefiltering over fields in the same application documents
Pricing: Free is $0. Flex is $0.011 per hour up to $30 per month. Dedicated starts at $0.08 per hour or $56.94 per month. Dedicated Search Nodes add separate hourly node charges.
Free trial: Free forever Atlas tier

8. Elasticsearch: best when lexical search remains the product

Elasticsearch is the best vector database when full-text relevance, filters, aggregations, and operational search are already the product, with semantic retrieval added as another signal. It is not the economical default for a narrow RAG index.

The concrete fit is commerce, media, observability, or enterprise search where exact terms, phrases, facets, structured filters, and semantic similarity must share one engine. Elasticsearch stores dense embeddings in dense_vector, sparse embeddings in sparse_vector, and combines them with lexical retrieval, filters, and aggregations.

Hybrid retrieval can run keyword, kNN, sparse-vector, and semantic branches in one workflow. Elastic supports reciprocal rank fusion and linear fusion, then optional reranking. That breadth is valuable when relevance engineering is a product capability rather than a helper function behind an LLM.

Elastic Cloud Hosted has four published floors. Standard starts at $99 per month. Gold starts at $114, Platinum at $131, and Enterprise at $184. All four offer a free trial. The annual floors are $1,188, $1,368, $1,572, and $2,208 respectively before workload-driven resources.

Vector storage is not static plumbing. New float or bfloat16 vector indices with at least 384 dimensions default to BBQ HNSW, a binary-quantized HNSW configuration intended to reduce memory and cost. That kind of evolving default makes version-aware retrieval evaluation important. A relevance result tied to one index configuration should not be treated as permanent.

The wall is platform size. Elasticsearch offers a wide surface because it solves a wide problem. Clusters, mappings, analyzers, shards, index lifecycles, relevance pipelines, vector configuration, and upgrades require ownership. If the only query is "find five semantically similar chunks," Pinecone, Qdrant, pgvector, or Chroma Cloud is easier to reason about.

Best for: Search products where lexical relevance, filters, facets, and vectors belong together
Standout: One engine for keyword, dense, sparse, filtered, aggregated, and reranked retrieval
Pricing: Cloud Hosted Standard starts at $99 per month, Gold at $114, Platinum at $131, and Enterprise at $184. Resource usage determines the deployed cost above those floors.
Free trial: Available on every hosted tier

9. Redis: best when retrieval must sit beside real-time state

Redis is the best vector option when embeddings must live beside fast-changing session state, semantic cache entries, recommendations, or agent memory already served from Redis. Its advantage is proximity to the real-time data path, not cheap bulk vector storage.

The concrete fit is an AI application that stores recent conversation state, cache entries, user features, or recommendation candidates in Redis and needs semantic lookup over the same objects. Redis can index vectors in hashes or JSON documents and filter by text, tags, numbers, geospatial fields, and vector conditions.

Three vector index choices cover different shapes. Redis recommends FLAT below 1 million vectors or when exact accuracy matters more than latency. HNSW is the larger-dataset choice when speed and scalability matter more than perfect accuracy. Redis 8.2 added SVS-VAMANA, which adds a graph-based compressed option and another tuning surface.

Redis Cloud pricing begins with Free at $0 for one shared database up to 30 MB. Essentials starts at $0.007 per hour or $5 per month and spans 250 MB to 100 GB across RAM and SSD, with SAML SSO, RBAC, encryption, and up to 99.99% uptime. Pro starts at $0.014 per hour, carries a $200 monthly minimum, and includes the first $200 free. It adds dedicated deployment, unlimited RAM, multiple databases, active-active multi-region, private connectivity, and up to 99.999% uptime.

Multi-cloud, hybrid-cloud, and on-premises deployment is available under an annual quote-based plan. That path belongs in enterprise procurement, not a quick vector pilot.

The wall is memory economics. Redis is designed around fast data access, and vector indexes consume memory even when compression or SSD-backed configurations reduce the pressure. A corpus that is large, mostly cold, and queried occasionally is a poor reason to buy an in-memory-shaped system. turbopuffer, Pinecone, or a storage-oriented Zilliz cluster shape deserves the cost model.

Best for: Semantic cache, agent memory, recommendations, and retrieval over real-time Redis data
Standout: Vector search beside low-latency state, JSON, hashes, and metadata filters
Pricing: Free is $0 up to 30 MB. Essentials starts at $0.007 per hour or $5 per month. Pro starts at $0.014 per hour with a $200 monthly minimum and the first $200 free. Enterprise deployment is quote-based under an annual plan.
Free trial: Free tier; Pro includes the first $200

10. Chroma: best for local prototypes and simple cloud retrieval

Chroma is the best vector database for a local prototype and a credible cloud option for a simple retrieval product, but its local and cloud capability surfaces are not identical. Treat moving from a notebook to Chroma Cloud as a production architecture decision, not a deploy button.

The concrete fit is an engineer proving chunking, embedding, filtering, and retrieval behavior before the surrounding product is stable. Chroma's open-source ergonomics make that loop accessible. Chroma Cloud adds serverless vector, full-text, and metadata search with explicit usage prices.

Chroma Cloud Starter costs $0 per month plus usage and includes $5 in free credits, 10 databases, and 10 team members. Usage is $2.50 per GiB written, $0.33 per GiB stored per month, $0.0075 per TiB queried, and $0.09 per GiB returned.

Team costs $250 per month plus usage and includes $100 in credits, 100 databases, 30 team members, Slack support, SOC II, and volume discounts. The included $100 does not roll over. Enterprise is custom priced and adds unlimited databases and team members, dedicated support, single-tenant clusters, BYOC, and SLAs.

The Search API is the boundary many teams miss. Chroma's current Cloud Search API supports vector search, metadata and document filtering, custom ranking expressions, RRF hybrid search, grouping, batch operations, field selection, and pagination. Chroma explicitly says that API is available only in Chroma Cloud and that single-node support is planned for a future release.

That means a local proof using the older query surface does not automatically validate the cloud production query plan, and a Cloud Search API design does not automatically run on a self-hosted single node. The product name is shared; the operational and query surfaces must still be checked.

The wall is governance and spend at the Team transition. Starter can host a small workload with usage billing. Team raises the base to $3,000 per year before usage. That jump buys organizational capacity, support, SOC II, and discounts. It should follow a named organizational requirement rather than a vague sense that paid equals production.

Best for: Local RAG prototypes, retrieval experiments, and straightforward Chroma Cloud applications
Standout: Fast local start plus transparent cloud write, storage, query, and network rates
Pricing: Starter is $0 per month plus usage with $5 credits. Team is $250 per month plus usage with $100 credits. Enterprise is custom. Usage is $2.50 per GiB written, $0.33 per GiB stored per month, $0.0075 per TiB queried, and $0.09 per GiB returned.
Free trial: Starter includes $5 in credits

Who should pick what

The right vector database follows the source of truth, the hardest retrieval condition, and the team's operating appetite, in that order.

Pick pgvector when Postgres already owns the records

Choose pgvector when documents, users, permissions, transactions, and vectors can share one data model. Stay until filtered recall, index memory, or query load causes a measured failure. Do not migrate because a generic benchmark says another engine handles more vectors.

The decision flips when iterative scans, partial indexes, partitioning, and capacity isolation still miss the latency or recall target. At that point, Qdrant is the strongest open-source dedicated candidate and Pinecone the strongest low-operations candidate.

Pick Qdrant when filtering is the retrieval problem

Choose Qdrant when nested payload filters and dense+sparse fusion are central. It fits teams willing to run a second store or buy Qdrant Cloud after sizing. The decision flips to Pinecone when database operations are the bigger constraint, or back to pgvector when the filters are relational and the workload still fits Postgres.

Pick Pinecone when operations are more expensive than units

Choose Pinecone when a small team needs a managed service, published usage rates, and enterprise controls without owning cluster operations. The decision flips when usage-unit economics, hybrid orchestration, BYOC policy, or open-source control becomes more important than that convenience.

The managed-versus-owned comparison is the same economic shape as other AI infrastructure decisions: pay a vendor for a narrower operational surface, or own the system and its incidents. The build-versus-rent cost framework shows how to put engineering ownership beside the subscription instead of pretending labor is free.

Pick turbopuffer when the corpus is large and access is uneven

Choose turbopuffer when logical-byte pricing and namespace isolation match the workload. Require an explicit freshness test under write bursts. The decision flips when updates or access revocations must be visible on the next query, or when the organization needs a simpler billing model.

Pick Weaviate when relevance needs a product surface

Choose Weaviate when BM25F, vector weighting, fusion, boosts, multi-tenancy, and managed deployment need to live in one platform. The decision flips when the query is simple enough that those controls become governance overhead.

Pick Zilliz Cloud when multi-vector scale is the problem

Choose Zilliz Cloud for very large, multimodal, or several-vector-field collections. Choose self-hosted Milvus only when the team already owns the distributed-systems work. The decision flips to a smaller engine when "future billion-scale" is a story rather than a measured requirement.

Stay on MongoDB, Elasticsearch, or Redis when data gravity wins

Choose Atlas Vector Search when application documents already live in MongoDB. Choose Elasticsearch when lexical search, filters, and aggregations are a core product. Choose Redis when vector retrieval sits beside real-time state. None is the best reason to migrate into that database solely for vectors.

Use Chroma to learn, then decide again

Choose Chroma locally to validate chunking, embeddings, and retrieval. Choose Chroma Cloud when its usage model and Cloud Search API fit the production workload. Do not assume the local and cloud surfaces are interchangeable.

The ones to avoid, by scenario

Avoiding the wrong product is more valuable than finding a universal winner. Every product here has a credible use case and a credible way to become the wrong purchase.

• Avoid a dedicated vector database before the current store fails. Copying vectors and metadata out of Postgres or MongoDB adds synchronization, deletion, recovery, and access-control work. A benchmark win does not repay that architecture by itself.
• Avoid pgvector when approximate filters still miss the required result count after tuning. Iterative scans can recover rows by doing more work. If that work breaks the latency budget, the system has reached a real migration trigger.
• Avoid self-hosted Milvus when nobody owns distributed storage and search operations. Open-source licensing does not provide upgrades, capacity plans, backup drills, or on-call coverage.
• Avoid Pinecone when no one can model read, write, storage, backup, and egress units. A managed service removes cluster work, not cost accountability.
• Avoid turbopuffer for a next-read consistency promise without a write-burst test. Its documented cache and indexing behavior is a product requirement, not a footnote.
• Avoid Weaviate when the team will not maintain a relevance evaluation set. Configurable fusion and boosts become unreviewed folklore without measured outcomes.
• Avoid Elasticsearch for a vector-only feature. Its search platform is powerful because it is broad. That breadth is waste when exact terms, analyzers, facets, and aggregations are irrelevant.
• Avoid Redis for a large cold archive. Fast real-time state is its advantage. Paying memory-shaped economics for rarely queried embeddings misses the point.
• Avoid Chroma single-node when the design depends on the Cloud Search API. The vendor currently marks that advanced API as Cloud-only.

The recurring mistake is buying for a future scale story. Buy for the hardest requirement visible in the next production stage, then leave a tested migration path. Architecture can evolve. Unmeasured complexity only accumulates.

Frequently asked questions

What is the best vector database for RAG?

pgvector is the best default when the application already uses Postgres. Qdrant is the best dedicated open-source choice for complex filters, Pinecone is the simplest fully managed choice, and Weaviate is strongest when configurable hybrid relevance is the product requirement.

What is the best vector database for RAG free?

pgvector, Qdrant OSS, Milvus, Weaviate OSS, Redis Open Source, and Chroma are open-source options, while Qdrant Cloud, Weaviate Cloud, Zilliz Cloud, MongoDB Atlas, Redis Cloud, Pinecone, and Chroma Cloud have free entry tiers. Infrastructure, backups, and engineering remain costs even when software is free.

What is the best open-source vector database?

Qdrant is the strongest dedicated open-source default because its filtering and hybrid retrieval fit many production RAG systems. pgvector is the better answer when vectors belong with relational application data, while Milvus fits teams that genuinely need its scale and can operate it.

Which vector database is best for hybrid search?

Weaviate is the clearest managed hybrid-search toolkit because it exposes BM25F and vector weighting, fusion, filters, and boosts. Qdrant, Pinecone, turbopuffer, Zilliz, pgvector, Elasticsearch, Redis, and Chroma Cloud also support hybrid patterns, but their control surfaces and operational tradeoffs differ.

What is the best local vector database?

Chroma is the easiest local starting point for many RAG prototypes. pgvector is better when the local application already runs Postgres. A local prototype does not settle the production decision because permissions, recovery, concurrency, and cloud-only features still need validation.

Is pgvector enough for production RAG?

Yes, when Postgres already owns the data and filtered recall, index memory, write load, and query latency remain inside the service level. Its documented filtered-search behavior is the key test: approximate filtering happens after the index scan, so selective filters can require iterative scans or a dedicated engine.

Pinecone or Qdrant: which should I choose?

Choose Pinecone when a fully managed service and lower operational burden justify usage-based pricing. Choose Qdrant when open-source control, nested filters, or deployment flexibility matter more, and accept either self-hosting work or resource-based Cloud sizing.

When should I move from pgvector to a dedicated vector database?

Move after measurement shows that filtered recall, latency, write load, index memory, or database isolation misses a defined production target despite index and partitioning work. Vector count alone is not a responsible trigger.

Final recommendation

pgvector is the best vector database for the largest group of builders because the least risky architecture is usually one database, not two. Qdrant is the best dedicated open-source step when filtered retrieval forces that split. Pinecone is the best managed step when the team wants to buy away database operations. Elasticsearch, MongoDB, and Redis win when vectors belong inside a data platform already serving the product.

The durable buying rule is data gravity first, filtered recall second, operating burden third, price fourth. Price only the systems that survive those constraints.

Run one representative workload before signing an annual plan: the real vector dimension, hardest permission filter, normal query rate, peak ingestion burst, deletion path, backup restore, and failure mode. The best database is the one that meets that service level with the fewest systems your team must own.

Get the AI Business Workflow Audit Checklist

Map the data, permissions, synchronization, handoffs, and operating risks before adding another database to the stack.