pgvector vs Elasticsearch for multi-agent systems: Which Should You Use?

pgvector and Elasticsearch solve different problems, even though both can store embeddings and do vector search. pgvector is the right choice when your agent system already lives in Postgres and you want simple, transactional vector retrieval. Elasticsearch wins when retrieval is only one part of a larger search stack and you need hybrid ranking, filtering, and operational search features at scale.

Quick Comparison

When pgvector Wins

Use pgvector when your multi-agent system needs memory that behaves like application data, not a separate search platform.

• •

  You already use Postgres as the system of record

  • •Store agent memories in the same database as users, tasks, tickets, or policies.
  • •A query like this is clean and maintainable:

    SELECT id, content
    FROM agent_memory
    WHERE tenant_id = $1
      AND agent_id = $2
    ORDER BY embedding <-> $3
    LIMIT 10;
    

  • •You get ACID semantics without syncing another datastore.
• •

  Your retrieval depends on strict metadata filters

  • •Multi-agent systems often need per-tenant isolation, workflow state filters, or access control.
  • •pgvector works well when you combine vector distance with normal SQL predicates:

    SELECT *
    FROM messages
    WHERE org_id = $1
      AND visibility = 'internal'
      AND created_at > now() - interval '7 days'
    ORDER BY embedding <=> $2
    LIMIT 5;
    

  • •That is hard to beat for correctness.
• •

  You want lower operational complexity

  • •One database means fewer failure modes.
  • •No separate sync job from Postgres to a search cluster.
  • •No dual-write consistency bugs between your transactional store and your retrieval store.
• •

  Your scale is sensible

  • •If you are building an internal agent platform or a focused production assistant with millions of rows rather than billions of documents, pgvector is enough.
  • •With hnsw indexing in pgvector, latency is good enough for most agent loops where the bottleneck is LLM inference anyway.

When Elasticsearch Wins

Use Elasticsearch when retrieval itself is a first-class product requirement.

• •

  You need hybrid search

  • •Agents often need both semantic similarity and keyword precision.
  • •Elasticsearch handles this well with bool queries combining text clauses and vector scoring via script_score.
  • •Example pattern:

    {
      "query": {
        "script_score": {
          "query": {
            "bool": {
              "must": [
                { "match": { "body": "claims denial appeal" } }
              ],
              "filter": [
                { "term": { "tenant_id": "acme" } }
              ]
            }
          },
          "script": {
            "source": "cosineSimilarity(params.query_vector, 'embedding') + 1.0",
            "params": {
              "query_vector": [0.12, 0.44]
            }
          }
        }
      }
    }
    

  • •That kind of ranking control matters when agents retrieve policy docs or case notes.
• •

  You have a large document corpus

  • •Elasticsearch is built for distributed indexing across many shards and nodes.
  • •If your agents query millions of documents across departments, regions, or knowledge domains, it scales better than trying to stretch Postgres into a search engine.
• •

  You need rich text features alongside vectors

  • •Tokenization rules, stemming, synonyms, phrase matching, fuzzy queries, aggregations — Elasticsearch does these natively.
  • •For multi-agent systems that act on enterprise content libraries or support archives, those capabilities matter more than simple nearest-neighbor lookup.
• •

  You need mature search operations

  • •Reindexing strategies.
  • •Index lifecycle management.
  • •Query profiling.
  • •Search relevance tuning.

  If your team already runs observability-heavy infrastructure and knows how to operate clusters properly, Elasticsearch gives you more control than pgvector ever will.

For multi-agent systems Specifically

My recommendation: start with pgvector unless retrieval is the product itself. Multi-agent systems usually need tight coupling between memory, task state, permissions, and transaction boundaries — that maps cleanly onto Postgres plus pgvector.

Move to Elasticsearch only if agents are searching across a large external knowledge base where hybrid ranking and full-text relevance are core requirements. For most production agent platforms, pgvector gives you the simplest path to correct behavior with fewer moving parts.

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.