Vector Store Selection — pgvector, OpenSearch, or Dedicated

Tier: Core · Hands-on time: ~30 minutes

The employer evidence behind this track is unusually literal here: live postings name "OpenSearch Serverless, Aurora pgvector" verbatim, and Google's architecture documentation explicitly contrasts dedicated vector search against embedding-alongside-operational-data patterns in AlloyDB. The options are all legitimate; the failure mode is choosing by fashion — or by an AI summary of benchmarks that were run on someone else's workload.

When to use

• A RAG or semantic-search design needs its storage decision and stakeholders are already lobbying for a favorite.
• An existing pgvector setup is hitting limits and the question is "scale it or move to dedicated?"
• A platform team wants one blessed vector store for many product teams with different workloads.
• Skip AI when the corpus is small, filtering is trivial, and you already run Postgres — pgvector next to your data is the boring default; write a two-line ADR and move on.

Prerequisites

• Workload numbers: vector count now and at 3x growth, dimensions, query rate, filter complexity, update churn.
• Your operational-data topologywhere the source-of-truth records live, because co-location is a first-class criterion.
• A chat assistant to scaffold the matrix and generate the verification checklist.
• Vendor docs and pricing calculators for each candidate.

The workflow

1. 1.

   Write down the five deciding criteria with your workload's answer for each. Co-location (do retrieved chunks join against operational tables?), filtering (simple tenant tag or rich boolean metadata?), scale (millions or billions of vectors?), cost floor (is there budget for an always-on cluster, or must idle cost approach zero?), residency (which regions may hold embeddings?).

2. 2.

   Scaffold the comparison with the criteria locked. Anita is choosing storage for orbit-docs-copilot, whose chunks must join against Orbit's existing Aurora tenant tables:

   Copy

   Build a comparison table for vector storage for a multi-tenant SaaS RAG
   copilot. Candidates: Aurora Postgres + pgvector (we already run Aurora),
   OpenSearch Serverless, and one dedicated store (Qdrant self-hosted).
   
   Criteria rows: co-location with operational data, metadata filtering
   depth, scale ceiling for our profile (~8M vectors, 1024-dim, moderate
   churn), cost floor at low utilization, India + EU residency options.
   
   For every factual cell add a VERIFY line naming the vendor doc I must
   check. Mark anything you are not certain of as UNKNOWN. Do not
   recommend a winner — surface trade-offs only.
   

3. 3.

   Verify the load-bearing cells against vendor docs. Dimension limits, index types, filtering syntax, serverless minimum billing units, regional availability. AI-recalled limits are the trap this whole track trains against; the store you pick will be sized against numbers someone checked.

4. 4.

   Price the cost floor honestly. Run each candidate through its pricing calculator at your realistic low-utilization scenario — dedicated clusters and serverless minimums behave very differently at 4 a.m. than in benchmark marketing. Record the monthly floor next to the scale ceiling.

5. 5.

   Pressure-test co-location. If retrieval results must join user permissions, tenant state, or product data, ask the assistant to sketch the query path for each candidate: in-database join versus application-side stitching versus duplicated metadata. The extra moving parts of a dedicated store are a real ops and consistency cost — make them visible.

6. 6.

   Score, decide, and record. You score the matrix, pick, and write a short ADR: decision, the two criteria that actually decided it, the losing options' best arguments, and a revisit trigger (vector count, filter complexity, or a residency rule change).

7. 7.

   Red-team the decision once. "Argue this choice collapses at 10x scale" — keep whatever survives as ADR consequences.

Verify before you trust it

• Limits come from docs dated now. Confirm dimension caps, index options, and quota ceilings on the vendor's current documentation page — vector-store capabilities have been changing fast enough that even recent AI training data misleads.
• The cost floor is a calculator number. Each candidate's idle-month cost is computed in the provider's calculator or from the published price sheet, with the assumptions written next to it.
• Filtering is proven, not described. For your two hardest real filter predicates, find the documented syntax for each candidate — or write a ten-line script against a free tier — before believing the matrix cell.
• Residency is checked per region and per service tier. Serverless and dedicated tiers of the same product can differ in regional availability.
• The recommendation is yours. If the final ADR's decision sentence could have been pasted from the assistant, rewrite it until it names your workload's specific facts.

Restricted-environment variant

For client engagements, check the MSA before describing the client's data topology to any external assistant — schema names and data-category descriptions can themselves be confidential. Abstract the workload ("regulated-industry document search, ~10M vectors, tenant-filtered") and keep real table names and volumes local. Where contracts require client tenancy, note that the pgvector path runs inside the client's existing database subscription with no new vendor relationship — often the deciding argument in restricted environments. A local Ollama model can scaffold the matrix offline; the verification is public-doc reading either way.