The best vector database for an AI agent is the one that retrieves the right client’s current information, under the permissions your application actually enforces. A fast similarity search is useful, but it is only one part of that job.

I looked through the current documentation for pgvector, Pinecone, Qdrant, Weaviate, and Milvus. My recommendation is to start with your existing data and operating constraints, then compare two candidates on a small retrieval workload before signing up for another database.

This is a documentation-based buying guide, not a benchmark report. Product details and public prices were checked on October 23, 2026; the evaluation plan below is a proposed pilot you can adapt.

Best vector database: quick picks by situation

A vector database stores numerical representations of content and searches for similar representations. In retrieval-augmented generation, or RAG, the retrieved passages become evidence for a model’s answer.

The storage layer does not decide whether a passage is true, whether a user may read it, or whether an answer cites it correctly. Those remain design and evaluation responsibilities.

These are starting recommendations, not exclusive capabilities. The linked documentation in each section explains the mechanisms behind them; several products can serve the same workload.

If you need the surrounding ingestion, prompts, tools, and delivery layers, read our AI agent technology stack guide. Buying a vector store does not supply that whole stack.

When PostgreSQL full-text search is enough

I would first ask whether semantic retrieval solves a real failure in your existing search. If customers ask for an order number, product code, or exact document title, a database query may already be the clearest answer.

PostgreSQL full-text search supports document preprocessing, query matching, and relevance ranking. That gives an existing Postgres application a useful baseline before introducing embeddings.

Try a small set of real questions against that baseline. Include paraphrases, abbreviations, identifiers, and questions whose answer is absent; a retrieval upgrade should address observed misses rather than a diagram in a sales presentation.

For an agent answering from a modest, well-organized knowledge collection, a managed knowledge feature may also be enough. Pickaxe’s Knowledge Base documentation explains source ingestion, chunking, and choosing which knowledge an agent can access.

That is a different purchase from running your own retrieval infrastructure. I would use it when the product goal is a useful client-facing assistant and there is no demonstrated requirement to own the vector index.

Our guide to adding an agent knowledge base helps make that earlier decision. Keep a record of the questions your initial approach fails, because they become the acceptance set for a custom retrieval system.

1. pgvector: my first candidate for an existing Postgres app

I would shortlist pgvector when the application already depends on PostgreSQL and the team wants to keep retrieval near its operational data. The attraction is fewer moving parts to evaluate, not a promise that vectors cost nothing.

The project documentation covers exact nearest-neighbor search and approximate indexes including HNSW and IVFFlat. It also explains a particularly relevant limitation: approximate searches with filters can return fewer results than requested.

Iterative index scans can search further, within configured bounds, to address that behavior. I would test this with the smallest tenant and most restrictive access filter in the proposed application, rather than measuring only an unfiltered shared corpus.

For a client policy assistant, keep the authoritative document identity and revision alongside each chunk. That makes it easier to explain which version supplied an answer and to remove all chunks belonging to a replaced document.

The tradeoff: retrieval now shares an operational environment with other database work. Budget for memory, index maintenance, backups, and the effect of imports on your normal application queries.

The software is available under the PostgreSQL License; that is not a hosted-service quote. Ask your provider which extension version is supported and price the actual instance, storage, backup, and recovery requirements.

My exit condition would be concrete: if a tuned pilot cannot meet filtered retrieval quality and application latency together, evaluate a separate engine. I would not move simply because an unsourced article names a universal maximum number of vectors.

2. Pinecone: managed retrieval with a clear namespace model

I would shortlist Pinecone when I want a managed retrieval service and am comfortable making its API, tenancy model, and billing units part of the application design. The public documentation makes namespace routing an especially useful evaluation point.

Pinecone’s multitenancy guide recommends a namespace per tenant for serverless applications. Reads and writes target the namespace, and offboarding can delete that tenant’s namespace.

That is useful structure, but your trusted backend must still select the correct namespace. Do not accept an arbitrary customer identifier from a prompt and forward it as an authorized search target.

Check the current API before designing hybrid retrieval. Pinecone’s hybrid search overview distinguishes Documents API text workloads from Vectors API patterns, including dense and sparse approaches and client-side fusion.

I would map the intended query to that documentation before copying a tutorial. A keyword filter that narrows candidates is not the same ranking behavior as merging keyword and semantic result lists.

On the checked date, Pinecone’s public pricing lists a free Starter plan, a $20 per month flat Builder plan, and Standard with a $50 monthly minimum usage charge, followed by pay-as-you-go usage above that minimum. These are different plans, not interchangeable estimates for the same workload.

I would compare the selected plan’s allowances and region availability with the actual corpus, writes, reads, and optional inference services. A managed database reduces infrastructure work, but you still own imports, permission routing, retrieval evaluation, and application behavior when a request fails.

3. Qdrant: a dedicated engine to evaluate around filters

I would shortlist Qdrant when a dedicated vector engine makes sense and I want to examine tenant payloads, filter indexes, and the choice between operating it myself and buying a managed cluster. That is an engineering preference, not a claim that it wins every latency comparison.

Qdrant’s multitenancy documentation describes tenant identifiers in payloads and ways to organize tenants. Its hybrid query documentation covers combining prefetched results through methods such as reciprocal rank fusion.

I would build the access boundary before tuning relevance. Every supported read path should receive a tenant scope derived from authenticated application state, including fallback searches and administrative previews.

Then compare exact-name questions with paraphrased questions, using the same permitted documents. A powerful query interface is only helpful if your team can explain and maintain the choices behind it.

The tradeoff: having deployment options means choosing an operating model. For a self-hosted pilot, assign responsibility for backups, upgrades, capacity, monitoring, and recovery instead of leaving those tasks outside the budget.

The checked Qdrant Cloud pricing page lists a free, single-node testing tier with 0.5 vCPU, 1 GB RAM, and 4 GB disk. It explicitly positions that tier for prototypes rather than high-availability production.

Paid cloud sizing is resource-based, so I would use its calculator for a named region and configuration. Do not compare that free prototype allowance with another vendor’s production minimum and call the difference a production saving.

4. Weaviate: a strong shortlist for hybrid document search

I would shortlist Weaviate when the application needs to combine precise terms with semantic matching and the team wants to evaluate that behavior within one search product. Names, model numbers, and paraphrases should all appear in the test set.

The hybrid search documentation explains combining vector and BM25 keyword search, including controls over their contribution. I would check whether changing that balance helps the questions your users actually ask.

Its multitenancy documentation describes each tenant being stored on a separate shard. Treat the tenant lifecycle as part of the product specification, including creation, inactivity, reactivation, and deletion.

The tradeoff: convenient search features can still require application-specific judgment. Someone must decide which fields matter, how to interpret ranking changes, and how the assistant behaves when the evidence is weak.

As checked, Weaviate’s pricing page lists a free cloud tier and Flex starting at $45 per month. The free tier has limits, including one collection and 100,000 objects; an object allowance is not a guarantee that a particular document corpus will fit.

Flex’s minimum includes vector dimensions and storage; backups are charged on top, and embedding or other AI services can add usage charges. Dimension rates depend on configuration and region, so I would price a specified deployment rather than reuse a generic per-vector estimate.

My practical reason to choose it would be a simpler, explainable search design that passes the pilot. Hybrid support alone is not exclusive to Weaviate, so ask what operational or relevance advantage it offers your particular team.

5. Milvus: choose the deployment before comparing the engine

I would shortlist Milvus when the team wants to evaluate dedicated retrieval infrastructure and can make an explicit deployment decision. The name covers more than one operating footprint, so comparisons need to say which version they mean.

The Milvus overview distinguishes Lite, Standalone, and Distributed deployments. Lite offers a lightweight local starting point, while the other modes change what you must deploy and operate.

I would use a local exploration to validate integration, then repeat the workload on the intended production topology. A laptop result cannot settle distributed capacity, failure recovery, or a managed-service bill.

Milvus’s multitenancy guide distinguishes database, collection, partition, and partition-key approaches. They carry different isolation and access-control tradeoffs, so “supports multitenancy” is not a complete design.

The tradeoff: deployment flexibility increases the number of decisions to document. Identify who owns configuration, upgrades, storage dependencies, backups, and the recovery exercise before treating self-hosted software as the inexpensive option.

For managed operation, Zilliz Cloud has separate pricing. It should be quoted for its own service configuration rather than presented as the price of every Milvus deployment.

I would not disqualify Milvus because of a distributed architecture diagram, or select it because of a claimed scale ceiling elsewhere. Test the mode you plan to operate and include its maintenance work in the comparison.

Filtering: test the smallest permitted slice

Imagine two clients storing similar policy documents. A query can find an excellent semantic match in the wrong client’s collection, which makes global retrieval quality an inadequate measure for the application.

My proposed test keeps the question constant and changes the allowed tenant, document status, and revision. Record the expected source identifiers before running the search, so reviewers can distinguish a relevant-looking passage from a permitted answer.

Include a case where only a narrow subset qualifies. The pgvector documentation’s explanation of filtering after an approximate index scan is a concrete reason to inspect this behavior rather than infer it from an unfiltered speed test.

Also inspect missing-result behavior. When the permitted corpus contains no answer, the product should be able to say so instead of quietly searching a broader collection.

I would log the applied scope, returned source IDs, and whether the evidence was sufficient, with sensitive text handled under the application’s logging policy. That makes a retrieval regression diagnosable without turning every log entry into a copy of client documents.

Hybrid search: compare answers to different question types

“Find the leave policy” and “Find policy HR-042” are different retrieval problems. A sensible evaluation includes both meaning-oriented questions and exact identifiers.

I would compare a keyword baseline, semantic retrieval, and a hybrid configuration while keeping the corpus and permissions fixed. Where a provider combines dense and sparse vectors rather than a built-in keyword index, document that setup clearly.

Do not add the raw scores from unrelated retrieval systems and assume the result has meaning. Choose an explicit fusion or reranking approach, then evaluate the resulting passage order against known evidence.

Hold embedding model, chunking, returned passage count, and answer model constant during the first storage comparison. After that, change one retrieval setting at a time and keep the earlier result as a baseline.

For a deeper look at the wider failure modes, use our guide to building agent evaluations. A database test should tell you whether the assistant has better evidence, not just whether an endpoint responded faster.

Tenant isolation needs an application boundary

A namespace, shard, or tenant field is a storage mechanism. Your application must connect it to an authenticated user and enforce that connection on every route.

PostgreSQL offers row-level security policies, but its documentation explains that superusers and roles with BYPASSRLS bypass them, and table owners normally do too. A successful test using an owner credential does not establish the behavior of a restricted application role.

I would test a missing scope, a forged scope, and an attempted cross-client lookup before measuring response speed. Use the same authorization boundary for exports, citations, document previews, and deletion jobs.

Deletion deserves its own acceptance case. Replace a document, remove its old chunks, and confirm that retrieval no longer returns the retired source; separately decide what happens to cached answers and backups.

These are proposed application checks, not claims that any product fails them by default. Our agent security guide provides more context for the surrounding deployment decisions.

What the best vector database actually costs your project

I would request comparable quotes from a written workload, not put five homepage prices in a row. A plan minimum, a resource allocation, and self-hosted software are different units.

Write down corpus size after chunking, embedding dimensions, expected queries, update frequency, region, retention, and availability needs. Add embedding generation, reranking, network transfer, backup, and staff time where they apply.

Illustrative arithmetic: 20,000 chunks with 1,536 dimensions stored as four-byte values contain 122,880,000 bytes of raw vector values, roughly 117 MiB. This calculation excludes metadata, text, indexes, replicas, and every other service cost.

It is a sizing prompt, not a vendor quote or a claim that the workload fits a particular free tier. Ask each provider how its own billing meter translates the same specified corpus and query pattern into a charge.

Then compare a quiet month, a normal month, and an import or traffic spike. Keep any introductory allowance separate from the recurring bill and record the quote date and selected region.

For a client service, also track retrieval cost per useful answer and time spent maintaining the data. Our agent cost guide explains why storage is only part of the operating budget.

A proposed 24-case retrieval pilot

Before selecting a service, I would run the same small acceptance set against the existing baseline and two shortlisted candidates. This is a proposed exercise, not a test we performed for this article.

• Six paraphrase cases: the correct passage uses different wording from the question.
• Six exact-term cases: identifiers, product names, or policy references must survive ranking.
• Six scope cases: include wrong-tenant attempts, restrictive filters, and missing authorization.
• Six lifecycle cases: replaced documents, deleted content, absent answers, and recovery after a failed update.

Use synthetic client data when possible. Give each case its expected source, permitted scope, and pass condition before running it; the same-looking answer can otherwise conceal very different retrieval quality.

Record passage correctness, forbidden results, end-to-end answer latency, update visibility, and measured cost. Keep raw retrieval timing separate from model generation time so the database does not get credit or blame for a different component.

For this pilot I would make any unauthorized result a release blocker, then investigate quality misses before trying to optimize speed. The sample is a useful regression set, not enough evidence to promise a production reliability percentage.

Finally, have the person who will operate the service perform a restore or rebuild exercise. A slightly less convenient query API can be acceptable; an unowned recovery procedure is a much harder service to sell.

Questions I would settle before buying

Is there one best vector database for every RAG project?

No. I would start with the deployment you can operate, then test retrieval under real permissions and update patterns; a database that suits one team can impose unnecessary work on another.

Can a vector database provide all of an agent’s memory?

I would keep authoritative customer state separate from similarity retrieval. An agent may retrieve a useful prior passage, but a similarity match should not decide the current subscription, permission, or order status.

Should a consultant expose the database directly to an agent?

I would expose a narrow retrieval interface with a trusted authorization boundary. Keep tenant selection, query constraints, and failure behavior under application control rather than asking the model to enforce them.

Can I connect a custom retrieval service to Pickaxe?

Pickaxe’s Actions documentation covers connecting external capabilities. A custom retrieval endpoint is an architecture to evaluate through that interface, not evidence of a native integration with every database listed here.

Verify authentication, response format, plan limits, and tenant identity propagation in the actual deployment. The managed Knowledge Base remains the simpler starting point when its supported behavior meets the client’s needs.

My recommendation: buy the smallest retrieval system that passes

For an existing Postgres application, I would evaluate pgvector first. For a separate managed service, Pinecone is a clear shortlist; for a dedicated engine with filter-oriented design, include Qdrant.

I would add Weaviate when hybrid document search and its tenant model simplify the application, and Milvus when its deployment choices fit the infrastructure team. Those are reasons to run the pilot, not a universal ranking.

Choose on permitted evidence, recovery, and total operating work. Keep the evaluation set after launch, rerun it when documents or retrieval settings change, and preserve enough source identity to explain an answer.

If your client primarily needs a branded assistant over their knowledge, start by exploring a Pickaxe agent. Own a custom vector layer when the requirements justify it, with a clear account of what that extra system improves.