A user-facing search system is not just retrieval. It is filtering, ranking, freshness, analytics, explainability, and operational discipline. When search becomes a product feature, the architecture usually needs a search serving layer, not only embeddings inside the source database.

Situation

Consumer marketplaces, travel booking sites, retail catalogs, local commerce systems, support portals, and enterprise knowledge platforms all face the same shift. Users no longer search only with keywords. They describe intent:

“Quiet hotel near the beach with breakfast.”

“Durable carry-on under 200 for international trips.”

“Dinner for four near me under 60 with vegetarian options.”

“Policy for escalation after account lockout.”

These queries are natural language, but the system still has to honor structured facts: price, location, availability, inventory, category, entitlement, policy version, delivery zone, and freshness.

This is where a search platform becomes architecturally natural.

The Problem

Postgres plus pgvector can support many internal RAG systems. It is less natural as the primary serving layer for product-grade search when the workload requires:

  • Facets and aggregations.
  • Typo tolerance and analyzers.
  • Synonyms and stemming.
  • Field boosts.
  • Geo filtering and distance ranking.
  • High query volume.
  • Near-real-time indexing.
  • Search analytics.
  • Relevance experiments.
  • Multiple ranking pipelines.
  • Operational search explainability.

Embeddings solve semantic similarity. They do not automatically solve search product requirements.

For marketplace, travel, retail, local commerce, and support search, the better architecture is usually source-of-truth database plus derived search index.

The Search Serving Architecture

flowchart TD
    DB[Source database] --> CDC[Change stream]
    DB --> EP[Embedding pipeline]
    CDC --> IDX[Search index]
    EP --> IDX
    Q[User query] --> PARSE[Query parser]
    PARSE --> KW[Keyword query]
    PARSE --> SEM[Semantic query]
    PARSE --> FIL[Hard filters]
    KW --> IDX
    SEM --> IDX
    FIL --> IDX
    IDX --> CAN[Hybrid candidates]
    CAN --> RANK[Ranking pipeline]
    RANK --> OUT[Results or explanation]

The source database remains authoritative for transactions, ownership, and final truth. The search index is a derived serving system optimized for retrieval and ranking.

That separation is important. The search index can be rebuilt. The source database cannot be treated as a cache. Prices, availability, order state, booking inventory, and policy truth should be verified against authoritative systems when the user takes action.

OpenSearch and Elasticsearch fit this pattern because they start from search primitives: inverted indexes, BM25, analyzers, mappings, filters, aggregations, geo capabilities, relevance tooling, and now vector and hybrid retrieval.

In Practice

The documented OpenSearch hybrid model combines keyword and semantic search through a pipeline that normalizes and combines scores. That is useful for search products because it keeps lexical and semantic evidence inside the search serving architecture.

Elastic documents hybrid search as combining semantic retrieval and lexical retrieval so the ranked output can benefit from both meaning and text similarity. That reflects the same production reality: exact terms and semantic intent both matter.

The documented pattern for search-heavy systems is therefore:

  • Keep the relational or transactional database as the source of truth.
  • Stream source changes into the search index.
  • Add embeddings as derived features.
  • Search over lexical fields, vector fields, and structured filters.
  • Use ranking and reranking as controlled release surfaces.
  • Verify transactional truth before checkout, booking, ordering, or compliance-sensitive action.

For a travel system, the search index may know hotel descriptions, amenities, location, reviews, and semantic embeddings. The pricing and availability service remains authoritative for dates, rooms, taxes, fees, and final price.

For a retail system, the search index may serve catalog discovery and semantic matching. Inventory, payment, and order state remain authoritative elsewhere.

For a local commerce system, the index may retrieve vendors, menu items, delivery zones, and attributes. The order system still verifies availability, substitutions, fees, and delivery promise.

Where It Breaks

RiskProduction impactControl
Source and index driftSearch shows stale or unavailable itemsTrack ingestion lag and verify final truth
Search index becomes source of truthRecovery and compliance become unclearKeep rebuild path from authoritative records
Hybrid score tuning is opaqueRelevance changes cannot be explainedLog candidate stages and ranking features
Embeddings update silentlyResults shift without reviewVersion embedding models and index aliases
Facets ignore semantic candidatesResult counts and results disagreeDesign filters and aggregations together
Search cluster is undersizedLatency spikes under vector workloadCapacity plan for lexical and vector paths
LLM writes final decisionsPrice, availability, or policy truth is wrongUse LLM for explanation, not authority

What to Do Next

  • Problem: Decide whether search is now a product surface rather than a database convenience.
  • Solution: Use a dedicated search serving layer when users need facets, geo, analyzers, typo tolerance, hybrid ranking, analytics, and high-volume relevance tuning.
  • Proof: Compare source-of-truth freshness, zero-result rate, no-click rate, lexical recall, semantic recall, filter correctness, and ranking quality across real query classes.
  • Action: Build the index as a derived system with CDC, replay, aliases, relevance test sets, rollback, and transactional verification before user actions.

The reason to use OpenSearch or Elasticsearch is not that vector search is impossible elsewhere. It is that product search has a broader contract than nearest-neighbor retrieval.

When search becomes a product, the serving layer needs search-native operations.

Sources