A municipal permitting chatbot team is choosing between Amazon RDS for PostgreSQL with the pgvector extension and Amazon OpenSearch Service as the vector store behind the chatbot's retrieval step. The team expects tens of millions of document embeddings and heavy concurrent similarity-search traffic during business hours. Which choice best fits this workload?

OpenSearch Service distributes vector indexes (typically HNSW or IVF-based approximate nearest-neighbor structures) across shards and nodes, so both index build time and concurrent query throughput scale roughly with the cluster size rather than a single instance's CPU and memory. That distributed design is exactly what tens of millions of embeddings under heavy concurrent traffic demands. Choosing pgvector for its SQL familiarity conflates a data-modeling preference with a scaling requirement — relational joins matter for many workloads, but they don't offset a single-instance engine hitting memory and query-concurrency limits as embedding volume grows. Treating DynamoDB's key-value lookups as equivalent to vector search misunderstands the operation itself: DynamoDB retrieves an item by exact key, and it has no mechanism for approximate similarity ranking across a vector space. Claiming pgvector removes the need to think about index type ignores that pgvector still requires explicit index choices (for example, IVFFlat or HNSW) and tuning as data grows; it doesn't automate that decision away. Scope note: at smaller scale (low millions of vectors, modest concurrency) pgvector remains a reasonable, lower-operational-overhead choice. Operational check: load-test the candidate store with production-like concurrent query volume before committing, rather than sizing on document count alone.