pgvector vs Elasticsearch for startups: Which Should You Use?

pgvector is a PostgreSQL extension for vector similarity search. Elasticsearch is a distributed search engine that also does vector search, hybrid retrieval, and full-text ranking. For most startups, start with pgvector unless search is already a core product surface or you need serious full-text + hybrid retrieval on day one.

Quick Comparison

When pgvector Wins

• •

  Your app already runs on Postgres

  • •This is the biggest one.
  • •If your startup already stores users, orders, tickets, or documents in Postgres, adding embeddings there avoids a second datastore and the sync problems that come with it.
• •

  You need semantic search without building a search platform

  • •pgvector gives you the basics fast:

    CREATE EXTENSION IF NOT EXISTS vector;
    
    ALTER TABLE documents
    ADD COLUMN embedding vector(1536);
    
    CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
    

  • •Then query with normal SQL:

    SELECT id, title
    FROM documents
    ORDER BY embedding <=> '[...]'
    LIMIT 10;
    

  • •That is enough for many startup RAG systems.
• •

  You care about transactional consistency

  • •If a row changes in Postgres, the embedding can live next to it.
  • •No dual-write pipeline.
  • •No “the document exists in the app but not yet in the search index” bug.
• •

  Your team is small

  • •A startup with 2–5 engineers should not volunteer for Elasticsearch operations unless it’s truly necessary.
  • •pgvector keeps architecture boring in the best possible way.

When Elasticsearch Wins

• •

  Search is the product

  • •If users expect Google-like behavior — typo tolerance, relevance tuning, filters, facets, autocomplete — Elasticsearch is the right tool.
  • •It was built for this problem first.
• •

  You need hybrid retrieval

  • •Elasticsearch handles keyword and vector search in one place.
  • •That matters when you want BM25-style text ranking plus dense_vector similarity plus metadata filters in a single request.
  • •Example shape:

    {
      "query": {
        "bool": {
          "must": [
            { "match": { "content": "credit card dispute" } }
          ],
          "filter": [
            { "term": { "tenant_id": "abc" } }
          ]
        }
      }
    }
    

  • •Then combine that with vector scoring when needed.
• •

  You have lots of documents and heavy read traffic

  • •Elasticsearch scales horizontally in a way pgvector does not try to match.
  • •If you’re indexing millions of searchable documents and serving high QPS with aggressive filtering and ranking logic, Elasticsearch earns its keep.
• •

  You need advanced text features

  • •Synonyms.
  • •Custom analyzers.
  • •Fuzzy matching.
  • •Phrase queries.
  • •Faceted navigation.
  • •Highlighting.

  These are native strengths of Elasticsearch and awkward add-ons elsewhere.

For startups Specifically

Start with pgvector if your main goal is to ship semantic search or RAG inside an existing application. It keeps infra simple, reduces cost, and lets your team move fast without creating a separate search subsystem too early.

Choose Elasticsearch only if search quality is central to the product or you already know you need full-text relevance engineering plus vector retrieval plus filtering at scale. Otherwise you are paying an operational tax before product-market fit even exists.

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.