The embedding lock-in: why vector-index format is the new switching cost in buy-side research

The story buy-side technology leads have been telling themselves since 2023 is that transcript access is the moat. Whoever has the deepest library of expert-call transcripts, earnings-call transcripts, and broker research feeds their agents the best context, and the firm with the best context wins. That framing is already outdated. The moat has moved one layer down the stack, and most funds have not noticed yet.

Our read: the durable switching cost in buy-side primary research is no longer the transcript corpus. It is the embedding model and vector-index format the corpus has been encoded into. A five-to-ten-year library of expert calls and earnings transcripts, once vectorised under a specific model at a specific dimension into a specific index, is not portable in any operationally meaningful sense. Moving it is a project, not a migration, and the bill for that project is what a growing number of mid-size funds will be quietly negotiating in 2027 and 2028.

The layer of the stack that quietly became load-bearing

Between 2023 and 2026, most buy-side firms of any technological ambition wired their primary-research corpus into a vector database sitting behind an LLM agent. The database choices are familiar: Pinecone, Weaviate, Qdrant, Turbopuffer, pgvector on Postgres, LanceDB for the teams who want columnar storage close to their existing Parquet workflows. The retrieval surfaces sitting on top are also familiar: AlphaSense, Hebbia, Rogo, Bridgetown, plus an increasing number of in-house agents built on top of a fund's own transcript library.

What gets discussed in the vendor selection process is the retrieval quality, the citation surface, the latency, the data coverage, and the compliance posture. What does not get discussed, and what almost no fund writes into the ingestion contract, is which embedding model produced the vectors sitting in the index. That omission is what turns an ordinary vendor relationship into a lock-in that only becomes visible when the fund tries to leave.

An embedding is a numerical fingerprint of a chunk of text produced by a specific model at a specific point in time. A vector produced by OpenAI's text-embedding-3-large at 3,072 dimensions is not comparable to a vector produced by Voyage-3 at 1,024 dimensions, or by Cohere Embed v3 at 1,024, or by a fine-tuned in-house model at some other dimension. They live in different geometric spaces. A query embedded with one model cannot retrieve, in any meaningful sense, documents indexed with another. The two vectors are numbers of the same shape; they are not measurements of the same thing.

That means the choice of embedding model at ingestion is not a preference. It is a commitment. Every downstream artefact, the index, the retrieval evals, the agent regression tests, the reranking thresholds, the citation-quality benchmarks, is calibrated against that specific model's geometry. Changing the model changes all of them.

What re-embedding actually costs a mid-size fund

The raw compute of re-embedding is the small part of the bill. A mid-size fund with a decade of expert-call transcripts, earnings-call transcripts across the coverage universe, internal research notes, and analyst annotations is looking at somewhere in the region of tens of millions of chunks after sensible chunking. At current commercial embedding prices, the pure API spend to re-encode that corpus lands in the low six figures. That is the number vendors quote when they say re-embedding is not a big deal.

It is not the number that matters. The number that matters is what surrounds the re-embed:

• Every retrieval eval the fund has built to certify agent quality has to be re-run against the new geometry, because recall at k and reranking behaviour will shift in ways that are not predictable from the old numbers.
• Every agent prompt that was tuned against the old retrieval quality has to be re-validated, and in many cases retuned, because the agent's behaviour is coupled to the specific mix of chunks that used to come back.
• Every citation and answer that was cached, and every human-in-the-loop review that certified past answers, becomes provisional, because the model that produced them is no longer the one in production.
• The vector index itself has to be rebuilt, which in a production Pinecone or Weaviate deployment is not a background operation. It is a cutover, and for many funds a dual-write window while the old and new indexes run in parallel until the new geometry has been signed off.
• If the fund uses Matryoshka representation learning or quantised embeddings to compress storage, the dimension choice and quantisation scheme baked into the old index do not carry across to the new model, and the storage plan has to be redesigned.

On a mid-size fund's corpus, industry chatter puts the fully loaded cost of a forced re-embed, meaning API spend plus engineering time plus eval rebuild plus the cost of running dual stacks during cutover, well into the six figures and occasionally into the low seven. That is the bill that the 2024 ada-002 deprecation quietly imposed on every firm that had standardised on it, and it is the template for what happens the next time a dominant embedding provider changes its lineup.

The 2024 signals nobody priced correctly

Two events in early 2024 were the first industrial-scale demonstrations of embedding lock-in, and both were treated at the time as ordinary product news.

The first was OpenAI's release of text-embedding-3 and the deprecation of text-embedding-ada-002. Anyone who had built a production retrieval stack on ada-002, and by early 2024 that was a large fraction of the buy-side vector infrastructure standing up around GPT-4 agents, had to migrate. The new models offered better performance and lower prices per token, and they introduced native support for shorter dimensions via Matryoshka-style truncation. The migration was not optional on any long horizon, and the corpus-wide re-embed was the cost of staying on the vendor.

The second was MongoDB's acquisition of Voyage AI in February 2024. Voyage had been building embedding models tuned for finance and legal retrieval, and had become one of the credible independent alternatives to OpenAI and Cohere for firms who wanted domain-specific embeddings without training their own. Its acquisition tied that embedding family to a specific database vendor's roadmap. Nothing about the models changed on day one, but the strategic character of the layer did. An independent embedding provider became a component of a database company's stack. Firms that had chosen Voyage precisely because it was database-agnostic now needed to think about what that meant on a five-year horizon.

Our view is that both events were priced by the market as ordinary vendor churn, and both were in fact structural. They established that the embedding layer is not a commodity, that the entity providing the embedding has commercial reasons to change or bundle it, and that the buy-side firm carries the migration cost either way.

Matryoshka and quantisation: a genuine improvement that also deepens the lock-in

A reasonable objection to this thesis is that the embedding layer has been getting cheaper and more flexible, not more locked-in. Matryoshka representation learning, now shipped by OpenAI in text-embedding-3, and adopted in variants by Cohere Embed v3, Nomic, and others, lets a single embedding be truncated to shorter dimensions with graceful quality degradation. Combined with scalar and binary quantisation, storage costs for a large corpus have fallen sharply. That is a real improvement.

It also deepens the lock-in in a subtle way. When a fund commits not just to a model but to a specific dimension (say 1,024 out of the model's native 3,072) and a specific quantisation scheme, it has taken two more configuration decisions that are baked into the index. Moving to another model does not just mean re-embedding at the new geometry; it means re-choosing the dimension and quantisation trade-off, re-running the storage-versus-quality analysis, and often reworking the reranking layer that was tuned against the compressed vectors. Compression buys operating cost savings today at the price of more choices to unwind later.

The honest read is that Matryoshka is a good technology and buy-side firms should be using it. The framing that matters is that the dimension choice and the quantisation scheme belong in the same category as the model choice: they are lock-in-generating decisions that deserve the same scrutiny as any other multi-year commitment.

MCP does not solve this, and in some ways sharpens it

The Model Context Protocol is the closest thing the industry has to a standardised interface between LLM agents and the tools and data sources they call. It is genuinely useful and is the right direction for the retrieval layer to move in. It does not, however, address embedding lock-in.

An MCP endpoint returns chunks. The chunks are selected upstream by the vendor's embedding model, indexed in the vendor's vector store, ranked by the vendor's retrieval pipeline. The client sees the output of that pipeline and never sees the vectors. From the client's perspective the retrieval quality is a black box calibrated on the vendor's choices, and the client's own agents are being tuned against a distribution of chunks that is a function of a model the client does not control.

In some ways MCP makes the lock-in sharper rather than looser. Before MCP, a firm that wanted to build its own retrieval had to choose an embedding model explicitly and take on the operational burden. After MCP, the abstraction is so clean that many firms will consume vendor-provided retrieval endpoints without ever explicitly making an embedding choice, and will inherit the vendor's lock-in without ever having named it. The interface is cleaner and the commitment underneath is more opaque.

What a portability-aware buy-side stack actually looks like

The firms our team sees taking this seriously are doing a small number of concrete things, none of which are exotic and all of which are cheap now and expensive later.

First, they are writing the embedding-model choice, dimension, and quantisation scheme into the vendor contract, not the technical appendix, and requiring notice of any change. If a vendor cannot commit in writing to a specific embedding lineage for a specified period, that is a lock-in signal.

Second, they are storing the raw chunk text alongside the vectors, in their own storage, not the vendor's. Raw text is small compared to vectors, portable across any embedding model, and is the only artefact from which re-embedding is possible without a wholesale re-ingestion of the source transcripts. A vector store is not a backup; the raw chunks are the backup.

Third, they are running a shadow index on a second embedding model for the highest-value slice of their corpus, typically the most-queried tickers and the most recent two years of expert calls and earnings. The shadow index is not a full failover. It is an evaluation harness that gives the fund an ongoing read on how retrieval quality would shift under a model change, and a partial migration path if a forced switch arrives.

Fourth, they are keeping retrieval evals decoupled from the specific model. An eval that measures whether the agent surfaces the right piece of an earnings call in response to a research question is portable across embedding models. An eval that measures recall at k against a specific vector index is not. The former is the durable asset; the latter is a diagnostic.

None of these are heroic engineering efforts. They are the equivalent of keeping your raw data separately from your BI tool, or keeping your feature definitions separately from your model artefact. They are the ordinary hygiene of a data platform that expects to outlive its current vendor lineup.

What we would ask an expert next

The questions worth putting to a Head of Research Technology or a CTO at a buy-side firm building on this stack, in the register of an expert-network call rather than a vendor pitch:

• Which embedding model, at what dimension and quantisation, is currently indexing your production transcript corpus, and when was that choice last reviewed?
• If your primary embedding vendor announced a deprecation or a strategic change tomorrow, what is the fully loaded cost, in engineering time and dual-stack operation, of migrating your corpus?
• Do your vendor contracts for AlphaSense, Hebbia, Rogo, Bridgetown, or any comparable retrieval surface specify the embedding lineage they use to index the corpus you ingest, and do they commit to notice periods on change?
• Are your retrieval evals decoupled from your current index, meaning could you re-run them against a shadow index tomorrow, or are they entangled with the current geometry?
• Where do the raw chunks live, in your storage or the vendor's, and is the raw-chunk store treated as the system of record?

These are not gotcha questions. They are the questions a firm's own risk function should already be asking of its own platform team, and the ones that separate a fund that will be a spectator of the next embedding transition from one that will be an active participant.