pgvector vs Elasticsearch for AI agents: Which Should You Use?

pgvector is a vector extension for Postgres. Elasticsearch is a search engine that also does vector search, hybrid retrieval, and filtering at scale.

For AI agents, start with pgvector unless you already run Elasticsearch for search or need high-scale hybrid retrieval on day one.

Quick Comparison

Area	pgvector	Elasticsearch
Learning curve	Low if you already know Postgres. You use normal SQL plus vector, ivfflat, or hnsw indexes.	Higher. You need to learn index mappings, analyzers, queries, and vector search syntax like knn / script_score.
Performance	Strong for small to medium corpora and transactional apps. Great when vectors live next to app data.	Strong at large-scale retrieval and mixed text + vector search. Built for distributed search workloads.
Ecosystem	Best when your app already uses Postgres, Prisma, SQLAlchemy, Django, or Rails.	Best when you already have Elastic for logs, text search, or enterprise search.
Pricing	Cheap to run if you already have Postgres. One database instead of another service.	Usually more expensive operationally. More nodes, more tuning, more moving parts.
Best use cases	RAG over internal docs, agent memory, semantic lookup tied to relational data, fast MVPs.	Large-scale semantic search, hybrid ranking, multi-tenant search platforms, enterprise retrieval.
Documentation	Clear if you know Postgres patterns. The surface area is small: CREATE EXTENSION vector;, ORDER BY embedding <-> query.	Broad and mature, but heavier. Plenty of examples, but more concepts to absorb before you ship well.

When pgvector Wins

1) Your agent needs vectors next to relational data

If your agent retrieves customer records, tickets, policies, or case notes from Postgres anyway, keep embeddings in the same database.

That means one transaction boundary, one backup strategy, one auth model, and simpler joins like:

SELECT id, title
FROM documents
ORDER BY embedding <-> $1
LIMIT 5;

You can combine semantic similarity with real filters without building a second system.

2) You want the fastest path to production

pgvector is the right move when you need something working this week.

Typical setup:

• •CREATE EXTENSION vector;
• •Add a vector(1536) column
• •Build an hnsw index for approximate nearest neighbor search
• •Use SQL filters for tenant IDs, status flags, or timestamps

That is enough for most AI agents doing retrieval-augmented generation over company knowledge bases.

3) Your workload is mostly RAG over a bounded corpus

If your corpus is thousands to low millions of chunks and not a global search product, pgvector is usually enough.

Examples:

• •Internal policy assistant
• •Support copilot over ticket history
• •Sales agent over account notes
• •Claims assistant over structured + unstructured records

You do not need Elasticsearch complexity just to find the top 10 similar chunks.

4) You care about operational simplicity

Every extra service becomes another failure mode.

With pgvector:

• •No separate cluster to size for search traffic
• •No duplicate indexing pipeline unless you want one
• •No cross-system consistency headaches between OLTP data and retrieval data

For teams shipping agents inside existing Postgres-backed apps, this wins hard.

When Elasticsearch Wins

1) You need hybrid retrieval as a first-class feature

Elasticsearch is built for combining lexical search with vector similarity.

That matters when exact terms matter:

• •Policy numbers
• •Product SKUs
• •Legal clauses
• •Medical codes
• •Names that must match precisely

You can mix BM25-style full-text ranking with vector queries using knn or script_score, then tune relevance with boosts and filters.

2) Your dataset is large and search-heavy

If your agent is sitting on top of millions of documents and users expect fast semantic + keyword retrieval under load, Elasticsearch is the stronger engine.

It handles:

• •Distributed indexing
• •Sharding and replication
• •Search-specific query optimization
• •High concurrent read traffic

pgvector can scale further than people think, but Elasticsearch was built for this problem from day one.

3) You already run Elastic in production

If your org already uses Elasticsearch for logs or enterprise search, adding AI retrieval there is pragmatic.

You get:

• •Existing ops knowledge
• •Existing monitoring
• •Existing security controls
• •Existing ingestion pipelines

In that case, introducing pgvector means adding another datastore just for embeddings. That is usually the wrong trade unless Postgres is already the system of record and Elastic would be redundant.

4) You need advanced text processing around retrieval

Elasticsearch gives you analyzers, tokenizers, stemming, synonyms, ngrams, fuzzy matching, highlighting, and field-level boosting.

That matters when agents need:

• •Query expansion
• •Synonym-aware recall
• •Language-specific analysis
• •Search result explanations with highlights

pgvector does not try to be a full-text engine. If text relevance matters as much as vector similarity, Elastic has the better toolkit.

For AI agents Specifically

Use pgvector first unless your agent’s core job is search at scale. Most AI agents need reliable retrieval from business data more than they need a distributed search platform with every ranking trick available.

My rule: if the agent lives inside a Postgres-backed product team building RAG or memory features, pick pgvector; if the agent depends on high-volume hybrid search across large document sets and Elastic already exists in your stack, pick Elasticsearch.

---

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.