OpenSearch as a Vector Database: When Search Infrastructure Beats a Dedicated Vector DB

A product team asks for vector search, but the real requirement is not pure semantic nearest-neighbor lookup. They need exact SKU matching, typo tolerance, category filters, facet counts, boosted brands, availability rules, and semantic fallback. That is not just a vector database problem. It is a search platform problem.

Short Version

OpenSearch is a good vector database when the workload is already search-shaped: BM25 relevance, analyzers, filters, facets, dashboards, logs, product search, and relevance debugging. It is especially strong when vector retrieval is one signal among several.

OpenSearch is the wrong fit when the application needs a small, simple vector service, strict relational consistency, or a retrieval workload with little lexical search value. In those cases, pgvector or a dedicated vector store may be easier to operate.

Situation

Many teams evaluate vector databases as if semantic similarity replaced search. It usually does not.

The Problem

Users still type part numbers, error codes, customer names, version strings, acronyms, and exact phrases. Dense embeddings are often weak at those cases. BM25 and field-aware lexical search remain valuable because they reward exact tokens and term frequency in predictable ways.

OpenSearch becomes attractive when the organization already has:

• Index lifecycle management.
• Search relevance tests.
• Analyzer and mapping expertise.
• Snapshot and restore workflows.
• Query profiling and relevance explanation habits.
• Product or log search infrastructure.

Adding vectors to that existing search model may be simpler than adding a separate vector store and then rebuilding search features around it. Does the retrieval workload actually need lexical search, facets, and relevance debugging, or would a smaller, purpose-built vector store be less operational surface for the same result?

How It Works

OpenSearch can store vector fields alongside text, keyword, numeric, and structured fields. A query can combine lexical matching, vector similarity, filters, and ranking pipelines.

flowchart TD
    Source[source records] --> Ingest[index pipeline]
    Ingest --> Index[OpenSearch index]
    Query[user query] --> Lex[BM25 lexical query]
    Query --> Vec[vector query]
    Lex --> Hybrid[hybrid search pipeline]
    Vec --> Hybrid
    Hybrid --> Filters[metadata filters and boosts]
    Filters --> Results[ranked results]

The production benefit is not only vector search. It is the ability to keep retrieval signals in one search index:

• title and body text fields for BM25.
• tenant_id, category, and availability fields for filters.
• embedding fields for semantic similarity.
• Pipeline settings for normalization and score combination.
• Query profiling and relevance debugging tools.

Architecture and Operating Model

OpenSearch should be selected when the operating model already fits search.

Index design. Define mappings intentionally. Text fields need analyzers. Keyword fields need exact matching. Vector fields need dimension and method choices. Nested objects and denormalized fields should be reviewed because mapping mistakes are expensive to unwind.

Ingestion. Treat OpenSearch as a derived index unless it is intentionally the system of record. Source changes must produce idempotent index updates. Deletes must remove or tombstone vector-bearing documents.

Hybrid retrieval. Combine lexical and vector result sets through documented query and pipeline mechanisms. Do not assume raw BM25 scores and vector scores are directly comparable.

Relevance operations. Keep a query set. Record expected results. Use explain tooling and search quality monitoring where available. Relevance changes should be reviewed like query plan changes in a database.

Recovery. Snapshots restore the search cluster, but platform teams should also maintain a replay path from source systems. A search index that cannot be rebuilt is a hidden source of truth.

In Practice

DBAs coming from relational systems should recognize OpenSearch as a distributed indexing system, not a relational database with a vector column. It has shards, replicas, mappings, refresh behavior, segment merges, heap pressure, disk watermarks, and query fanout.

That complexity is justified when the workload benefits from it. It is wasteful when the application only needs “top ten similar chunks for tenant X.”

Platform teams should ask: do we already have OpenSearch operational maturity? If yes, vector search may fit naturally. If no, adopting OpenSearch solely for vectors means accepting a search platform just to avoid operating a vector service.

Where It Breaks

Scenario	Why OpenSearch struggles	Alternative
Strong relational consistency	Search refresh and derived-index semantics complicate read-after-write	pgvector
Simple internal RAG	Search cluster overhead dominates value	pgvector or Qdrant
Heavy OLTP joins	Denormalization becomes brittle	PostgreSQL plus pgvector
Pure vector service	BM25, analyzers, and shards add unused complexity	Qdrant
Weak search operations	Team cannot debug mappings, shards, and relevance	Start simpler

Security, Cost, Observability, and Failure Notes

Security depends on filter discipline. Tenant and entitlement fields must be present in the index and used in every query. If authorization depends on relational joins outside OpenSearch, the ingestion pipeline must denormalize those permissions safely or query-time enforcement must happen before retrieval.

Cost is driven by indexed data volume, shard count, replicas, storage, heap, ingestion rate, and query fanout. Vector fields can increase memory and storage pressure. Hybrid retrieval can increase query CPU because it runs multiple retrieval paths.

Observability should cover search latency, vector query latency, indexing lag, refresh behavior, rejected requests, heap pressure, segment merges, disk watermarks, shard imbalance, snapshot age, and relevance regression metrics.

Failure modes include stale indexes, mapping mistakes, over-sharding, under-sized clusters, expensive wildcard or aggregation queries, and score-combination changes that silently reorder important results.

Decision Checklist

• Is lexical relevance as important as semantic similarity?
• Does the team already operate OpenSearch well?
• Are analyzers, field boosts, facets, and filters part of the requirement?
• Is OpenSearch already the product-search or log-search platform?
• Can source data be replayed into the index?
• Are authorization fields safely denormalized?
• Is there a relevance test set?
• Is search latency budget compatible with hybrid retrieval?
• Does the cost model account for shards, replicas, storage, and vector fields?

What to Do Next

Problem: Teams reach for OpenSearch as a vector database because the vectors need to go somewhere, without checking whether the workload actually needs BM25, facets, and relevance debugging.

Solution: Use OpenSearch when retrieval is search, not just vectors — BM25, filters, facets, relevance tooling, and operational search maturity already matter. Avoid it when the workload only needs a small vector lookup service or when consistency belongs inside Postgres.

Proof: The team can name which production queries rely on lexical matching versus vector similarity, and a relevance query set exists to catch regressions before they ship.

Action: This week, list the query types the retrieval endpoint actually serves (exact SKU lookup, semantic paraphrase, filtered facet browse) and check whether OpenSearch’s operational maturity already exists on the team before committing to it as the vector store.

Operating Guardrails

Do not let OpenSearch become the unreviewed dumping ground for every field that might someday be searched. Each indexed field should have a query purpose, retention policy, mapping owner, and freshness expectation. Vector fields need the same discipline as text fields: model version, dimension, source property, and rebuild plan.

For production rollout, separate hard constraints from ranking signals. Tenant, region, deletion state, compliance status, and entitlement are constraints. They should not be expressed as soft boosts. Relevance tuning can move products up and down; it must not decide whether a user is allowed to see the result.

Also define an ownership rule for mappings. A vector field added by an AI team can change heap, disk, snapshot, and query behavior for the search team. That change deserves the same review as a new high-cardinality aggregation field.

Sources to Verify

• OpenSearch vector search documentation: https://docs.opensearch.org/latest/vector-search/
• OpenSearch hybrid search documentation: https://docs.opensearch.org/latest/vector-search/ai-search/hybrid-search/
• OpenSearch index management documentation: https://docs.opensearch.org/latest/im-plugin/