How to Fix 'embedding dimension mismatch when scaling' in LangGraph (TypeScript)

When you see embedding dimension mismatch when scaling, LangGraph is usually not the real problem. The error comes from the vector store or embedding layer underneath it, and it means you tried to insert or query vectors with a different length than the index was built for.

This typically shows up in TypeScript projects when you swap embedding models, reuse an old index, or mix documents embedded with one model and queries embedded with another.

The Most Common Cause

The #1 cause is changing embedding models without rebuilding the vector index.

If your store was created with text-embedding-3-small and later you query with text-embedding-3-large, or you switch from one provider to another, the vector dimensions no longer match. In LangGraph, this often surfaces while using a retriever node, a tool that writes to a vector store, or a graph step that calls store.put() / retriever.getRelevantDocuments().

Broken vs fixed pattern

// BROKEN: index was built with 1536-dim embeddings,
// but this query uses a different model/dimension.

import { OpenAIEmbeddings } from "@langchain/openai";
import { MemoryVectorStore } from "langchain/vectorstores/memory";

const ingestEmbeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-small", // 1536 dims
});

const queryEmbeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-large", // 3072 dims
});

const store = await MemoryVectorStore.fromTexts(
  ["customer policy", "claims workflow"],
  [{ id: "1" }, { id: "2" }],
  ingestEmbeddings
);

// Later in your LangGraph node:
const retriever = store.asRetriever({ k: 4 });

// This can fail downstream because the store/query dimensions don't match.
const docs = await retriever.invoke("find policy details");

// FIXED: use the same embedding model for ingestion and retrieval.
// If you change models, rebuild the vector store/index.

import { OpenAIEmbeddings } from "@langchain/openai";
import { MemoryVectorStore } from "langchain/vectorstores/memory";

const embeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-small",
});

const store = await MemoryVectorStore.fromTexts(
  ["customer policy", "claims workflow"],
  [{ id: "1" }, { id: "2" }],
  embeddings
);

const retriever = store.asRetriever({ k: 4 });
const docs = await retriever.invoke("find policy details");

If you are using a persistent backend like Pinecone, Qdrant, Weaviate, pgvector, or Chroma, this is even more common because old vectors stay on disk after you change models. The fix is not “retry”; it is “recreate the collection/index with the correct dimension.”

Other Possible Causes

1) You are mixing providers in different graph nodes

One node embeds documents with OpenAI, another embeds queries with Cohere or Voyage. Same app, different dimensions.

// BAD: ingestion and retrieval use different providers.
const docEmbeddings = new OpenAIEmbeddings({ model: "text-embedding-3-small" });
const queryEmbeddings = new CohereEmbeddings({ model: "embed-english-v3.0" });

Keep one embedding contract per index.

2) Your persistent collection was created with the wrong dimension

This happens when infra is provisioned once and never rebuilt.

// Example: pgvector table created for 1536 dims
CREATE TABLE documents (
  id text PRIMARY KEY,
  content text,
  embedding vector(1536)
);

If you later switch to a 3072-dim model, inserts will fail. Recreate the table or create a new one:

DROP TABLE documents;
CREATE TABLE documents (
  id text PRIMARY KEY,
  content text,
  embedding vector(3072)
);

3) You are loading stale data from a previous run

A local dev loop can hide this. Your code changed, but your .chroma/, .qdrant/, or database still contains old vectors.

// Bad assumption: restarting app resets embeddings.
// It does not if the store persists.
await vectorStore.addDocuments(newDocs);

Delete and rebuild the collection when changing models.

4) Your reranker or custom transform changes vector shape

If you added custom preprocessing around embeddings, check that you are not truncating or padding vectors incorrectly before storage.

function badNormalize(vec: number[]) {
  return vec.slice(0, 768); // breaks if original dim is not 768
}

Do not reshape embeddings unless your backend explicitly requires it.

How to Debug It

1. •

   Print the embedding dimension at runtime

   • •Log one sample vector length during ingestion and query.
   • •Example:

     const v = await embeddings.embedQuery("test");
     console.log("embedding dim:", v.length);
     

   • •If ingest and query lengths differ, you found the issue.
2. •

   Check how your index was created

   • •Look at the collection/table/index config.
   • •For pgvector:

     \d documents
     

   • •For Pinecone/Qdrant/Weaviate, inspect the namespace/collection schema.
3. •

   Search for multiple embedding clients

   • •Grep your codebase for new OpenAIEmbeddings, new CohereEmbeddings, new VoyageAIEmbeddings.
   • •If more than one client touches the same store, that is suspicious.
4. •

   Delete and recreate one clean test index

   • •Build a fresh collection from scratch.
   • •If the error disappears, your production/dev store had stale vectors or wrong schema.

Prevention

• •Use one embedding factory per index and make it explicit in code.
• •Version your vector collections by embedding model name:
  • •customer_docs_text-embedding-3-small
  • •customer_docs_text-embedding-3-large
• •Add a startup check that compares:
  • •expected dimension from your embedder
  • •actual dimension of an existing collection/table

If you want this class of bug to stop showing up in LangGraph TypeScript projects, treat embeddings like schema. When the schema changes, rebuild storage.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.