S3 Vectors vs OpenSearch: Cost and Freshness Tradeoffs for Code RAG

OpenSearch (or OpenSearch Serverless) has been the default brain for code RAG on AWS: hybrid BM25 + kNN, rich filters, aggregations. S3-centric vector stores and newer S3 vector features promise cheaper storage and simpler ops — but freshness, filter expressiveness, and hybrid lexical recall are where seniors get burned. Pick the store for the access pattern you actually have, not the launch blog.

⚡ TL;DR: Keep OpenSearch when you need hybrid BM25+kNN, low-latency filtered search, and frequent partial updates. Consider S3-backed vectors for cold/archival corpora, batch enrichment, or cost floors on huge rarely-updated indexes. Measure p95 query, reindex lag, and $/M queries before migrating. See Hybrid search for code and OpenSearch neural pipelines.

Compare on the axes that matter for code

# cost/model.py — back-of-envelope, replace with your quotes
def monthly_cost(chunks: int, qps: float, bytes_per: int = 2_000):
    storage_gb = chunks * bytes_per / 1e9
    # illustrative coefficients — plug FinOps numbers
    os_cost = 400 + storage_gb * 0.15 + qps * 80
    s3_cost = storage_gb * 0.023 + qps * 20 + 50  # + vector query premium
    return {"opensearch": os_cost, "s3_vectors": s3_cost, "storage_gb": storage_gb}

Freshness: merge-to-searchable lag

Code RAG dies when deleted files still answer. OpenSearch near-real-time refresh plus tombstone deletes is well understood. S3 object stores often mean rewrite-or-compact pipelines — fine for nightly wiki embeds, dangerous for monorepo main that merges every 4 minutes.

# freshness/slo.py
MAX_MERGE_TO_SEARCH_SEC = 120  # ✅ IDE assistants

def lag_ok(merged_at: float, searchable_at: float) -> bool:
    return (searchable_at - merged_at) <= MAX_MERGE_TO_SEARCH_SEC

# ❌ Accepting “eventual” without an SLO when engineers chat against HEAD

Wire git webhooks as in Knowledge Base sync regardless of backend.

Filtering and hybrid recall

Symbol questions (“where is createIdempotencyKey?”) need lexical exactness. If your S3 vector path is pure ANN, you will miss renames and rare identifiers unless you keep a sidecar BM25 or symbol index.

// retrieve/hybrid-router.ts
export async function retrieve(q: string, filters: { repo: string; lang?: string }) {
  const lexical = await bm25OrSymbols(q, filters); // OpenSearch or ctags index
  const dense = await vectorSearch(q, filters);    // OS kNN or S3 vectors
  // ✅ Always fuse — never ship pure ANN for code identifiers
  return rrfFuse(lexical, dense, { k: 60, top: 12 });
}

Migration decision tree

1. Need sub-2s filtered hybrid for IDE chat → stay on OpenSearch (or pgvector + BM25), optimize shards/OCUs.
2. Huge cold corpus (years of tickets, archived wikis) → S3 vectors / cheap store + promote hot subset to OpenSearch.
3. Bedrock Knowledge Bases managed path → accept its vector store choice; invest in chunking and metadata, not DIY ANN.
4. Dual-write during eval → shadow traffic both stores; promote only when faithfulness and cost curves win for 2 weeks.

Closing checklist

✅ Dos
– ✅ Price p95 latency and freshness SLO before cost slides
– ✅ Keep hybrid lexical+dense for code identifiers
– ✅ Dual-write and A/B faithfulness before cutover
– ✅ Tombstone deletes with measurable merge-to-search lag
– ✅ Separate hot IDE indexes from cold archival corpora

❌ Don’ts
– ❌ Don’t migrate for storage savings alone
– ❌ Don’t assume S3 vectors give OpenSearch-class filters
– ❌ Don’t let deleted files linger past your freshness SLO
– ❌ Don’t skip BM25/symbol paths for “vectors only”
– ❌ Don’t rewrite the stack mid-incident

Related reading

• Hybrid Search for Code: BM25, Vectors, and Symbol Indexes Together
• OpenSearch Neural Pipelines: Embed API Docs on Write, Hybrid Rank
• Aurora pgvector HNSW Tuning: Keep Code Symbol Search Under SLOs
• Cost-Aware RAG Caches: Reuse Answers for Identical Code Questions

Last updated on September 11, 2026