Sub-system
An embedding turns a piece of text into a list of numbers positioned so that similar meanings sit close together. Searching that space is what lets a model be handed the three relevant paragraphs out of a million, and it is the infrastructure underneath most retrieval systems.
In one sentence
An embedding is a fixed-length numeric vector representing the meaning of a piece of text or other content; vector search finds the stored vectors nearest to a query vector, retrieving by similarity rather than by exact terms.
Keyword search fails when the question and the answer use different words for the same idea. Embeddings solve that by mapping meaning into geometry: a model trained for the purpose places semantically similar passages near each other, so proximity in the vector space stands in for relevance.
At scale, comparing a query against every stored vector is too slow, so systems use approximate nearest-neighbour indexes that trade a small amount of recall for very large speed gains. That trade — and the fact that it is a trade — is the single most important thing to understand about vector search.
The common structures are navigable small-world graphs, which link each vector to its neighbours so search walks toward the query, and clustering schemes that partition the space and search only nearby partitions. Both are approximate: they find most of the true nearest neighbours most of the time, and the tuning knob is how much recall you will give up for latency.
Documents must be split before embedding, and the split is consequential. Chunks too small lose the context that makes a passage meaningful; too large and the vector averages several topics into something that matches nothing well. Most disappointing retrieval systems have a chunking problem, not a model problem.
Pure vector search is weak on exact identifiers — part numbers, names, error codes — because those carry little semantic signal. Production systems combine keyword and vector scoring and often re-rank the combined candidates with a more expensive model, which reliably outperforms either method alone.
Technology dependencies are solved by engineering; supply dependencies are solved by building something, which takes years.
Retrieval quality is bounded by the model producing the vectors; changing it invalidates every stored vector and forces a full re-index.
TransformersGraph indexes are held largely in memory, so a large vector store is a memory purchase before it is anything else.
Server memoryEvery document has to be run through the embedding model once, and again whenever the model changes. Re-embedding a large corpus is a scheduled compute project, not a background task.
Serving enginesBeyond a certain corpus size the index no longer fits in memory and part of it is served from solid-state storage. The drive's random-read latency then sets the tail latency of retrieval.
NAND and SSDsOther pages in this map that name Embeddings and vector search as something they cannot do without.
What each company supplies at this step, and — where a public figure exists — its share of this specific market — with what that share measures, the period it covers and who published it. Some rows also show the company’s own reported revenue for the segment covering this step, which is a different thing: it says how much this business matters to that company, not how much of the market it holds. Not a ranking and not a recommendation.
Provides vector search inside its general-purpose database platform.
Provides hybrid keyword and vector retrieval in its search platform.
Operates managed vector and retrieval services within its cloud platform.
Provides embedding and retrieval features over data already held in its platform.
Sells both the embedding models and the managed vector index they are queried through.
Runs the managed search and vector services most of its cloud's retrieval traffic goes through.
Sells a vector database as a service, which is the shape most teams adopt before they own the infrastructure.
Added vector search to the in-memory store already sitting in front of most application databases.
Supplies the embedding models a large share of production indexes are built with.
Supplies the open-source vector database self-hosting teams most often standardise on.
Supplies the embedded vector store most prototypes start in, before anything has been decided.
Sells embedding and reranking models to enterprises that will not send their text to a consumer-facing lab.
Provides vector indexes over data already governed inside the customer's own platform.
Added vector search to the database so retrieval does not require moving the records out of it.
Whether vector search stays a separate product category or is absorbed into general-purpose databases.
Whether very long context windows reduce the need for retrieval, or simply raise the cost of not retrieving.
Whether re-indexing cost becomes a practical brake on adopting better embedding models.
Each page explains one technology in plain language, states what it depends on, and names companies by what they supply at that step. Company roles are described qualitatively and deliberately carry no market shares, revenue figures or rankings — those change faster than an explainer can, and a stale number is worse than none. Ticker links point at company pages on this site and are provided for reference only.
Nothing here is investment advice, a recommendation, or a forecast. A company named on a page about a technology is not thereby a good investment, and the chokepoints described are structural facts about supply chains rather than predictions about prices. Technology moves; where a page describes something as unresolved or in development, that was true when it was written.
Plutux is not an investment adviser. Market data and AI-generated analysis are for information and education only, not investment advice. Disclaimer