pgvector vs Elasticsearch for real-time apps: Which Should You Use?

pgvector and Elasticsearch solve different problems, even though both can power retrieval in real-time apps. pgvector is a PostgreSQL extension for storing and searching embeddings with SQL; Elasticsearch is a distributed search engine built for text search, filtering, and operational search workloads.

For real-time apps, use pgvector first if your retrieval needs fit inside Postgres. Use Elasticsearch when search relevance, text-heavy queries, and scale-out indexing are the core problem.

Quick Comparison

When pgvector Wins

• •

  You need transactional consistency with your vectors

  If your app writes customer records and embeddings in the same request path, pgvector is the right move. You get ACID semantics from Postgres instead of coordinating writes between a primary database and a separate search cluster.

• •

  You need vector search plus relational filters

  Real-time apps usually need more than nearest neighbors. With pgvector you can do things like:

  SELECT id
  FROM tickets
  WHERE tenant_id = $1
    AND status = 'open'
  ORDER BY embedding <-> $2
  LIMIT 10;
  

  That combination of metadata filters and similarity ranking is where Postgres shines.

• •

  Your team already operates Postgres well

  If your engineers know replication slots, connection pooling, backups, migrations, and query plans in Postgres but have never run an Elasticsearch cluster in production, pgvector wins by default. Fewer systems means fewer failure modes.

• •

  Your scale is real-time but not massive-search-engine scale

  If you’re handling tens of thousands to low millions of vectors per tenant or dataset segment, pgvector with hnsw or ivfflat is usually enough. You do not need a distributed search engine just to find similar support tickets or user profiles.

When Elasticsearch Wins

• •

  You need serious full-text search

  Elasticsearch is built for lexical relevance: tokenization, stemming, phrase queries, fuzziness, synonyms, field boosting. If users expect Google-like behavior across titles, descriptions, tags, and free text fields, Elasticsearch is the correct tool.

• •

  You need hybrid retrieval at scale

  Elasticsearch handles combined keyword + vector workflows better than most teams expect once configured properly with dense_vector fields and kNN queries alongside BM25-style scoring. That matters when exact terms still matter more than pure semantic similarity.

• •

  You have high ingest volume and many read patterns

  Real-time apps that index events continuously—tickets, orders, messages, logs—benefit from Elasticsearch’s distributed indexing model. It is designed to absorb write-heavy streams while serving many concurrent query shapes.

• •

  Your product depends on advanced search features

  Faceting، highlighting، autocomplete، synonym expansion، nested documents، geo queries—Elasticsearch has all of this out of the box or close to it. Rebuilding those features around pgvector is a waste of engineering time.

For real-time apps Specifically

My recommendation: start with pgvector unless your primary user-facing feature is search. Real-time apps usually need low-latency reads on fresh data plus strong transactional guarantees; keeping vectors inside Postgres gives you simpler architecture and faster delivery.

Choose Elasticsearch only when the app’s core interaction is document search or hybrid relevance at scale. If users type queries into a box all day long and expect sophisticated ranking behavior across huge datasets, Elasticsearch earns its complexity immediately.

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.