Choose an embedding model and vector database with an actual decision framework

You are choosing an embedding model and vector database for a production RAG system, and your job is to make the decision against this workload's actual characteristics — not to recommend whichever combination is most popular in blog posts this quarter.

WORKLOAD PROFILE
2M internal documents, mixed English and German, growing by ~5,000 documents/day via real-time upserts from a CMS webhook, multi-tenant with per-customer access filtering required at query time

CANDIDATES TO EVALUATE
Embedding models: OpenAI text-embedding-3-large, Cohere embed-v4-multilingual, Voyage-3-large
Vector stores: Pinecone (managed), Qdrant (self-hosted), pgvector on existing Postgres

EVALUATION CRITERIA
For the embedding model:
- Domain fit: does the workload contain vocabulary the candidate was actually trained on enough of to embed well, or is this a general-purpose model being asked to do domain-specific work it wasn't evaluated for?
- Dimensionality and its real cost: a higher-dimensional embedding is not free — it's more storage, more compute per similarity comparison at scale, and a larger index. State the dimensionality of each candidate and whether the workload's scale actually needs the extra dimensions, or whether a smaller model would perform close enough for meaningfully less cost.
- Update and versioning risk: if the embedding model changes or gets deprecated, every existing vector must be re-embedded. State each candidate's track record and stated commitment on model stability, since this is a migration cost, not a one-time decision.

For the vector store:
- Filtering support: can it filter by metadata such as tenant ID or access level at query time without a full post-filter scan, which matters directly for every query must be scoped to one customer's documents only, enforced at the query layer, not just in application code after retrieval.
- Update pattern fit: does the workload's update frequency match what the candidate is actually built for — some stores handle high-frequency upserts far better than others.
- Operational fit: small platform team, no dedicated database SRE, strong preference for managed services unless self-hosting saves a specific, quantified amount — self-hosted versus managed, and what that means for who's on call when it goes down.

DECISION RULES
- Reject a candidate combination if it fails any hard requirement in the workload profile outright, before comparing anything else — a model with no support for the required language, or a store with no metadata filtering when multi-tenancy is a hard requirement, doesn't get weighed against benchmark scores, it's disqualified.
- For the remaining candidates, state the actual tradeoff, not "it depends" — if two combinations are close, say what specific additional test would break the tie, rather than picking arbitrarily.

OUTPUT FORMAT
1. Disqualified candidates, with the specific hard requirement each one fails.
2. The remaining comparison, as a short table across the criteria above.
3. The recommendation, with the single strongest reason it wins for this workload specifically.
4. The migration cost if this choice needs to change later, stated honestly.