How to Fix 'embedding dimension mismatch during development' in LangGraph (TypeScript)

If you’re seeing embedding dimension mismatch during development, it means the vector you’re sending into your store does not match the embedding size the index was created for. In LangGraph TypeScript projects, this usually shows up when you swap embedding models, reuse an old vector index, or wire the wrong embedding function into a node.

The error often appears during local development because your code changes faster than your persisted data. You rebuild the app, but your vector store still contains embeddings from a different model dimension.

The Most Common Cause

The #1 cause is simple: you changed embedding models, but kept the same collection/index.

For example, text-embedding-3-small returns 1536 dimensions, while another model may return a different size. If your MemoryVectorStore, Pinecone index, or pgvector table was created with one dimension and you insert vectors from another, LangChain/LangGraph will fail when adding or querying documents.

Broken vs fixed pattern

// BROKEN: old index created for a different embedding dimension
import { OpenAIEmbeddings } from "@langchain/openai";
import { MemoryVectorStore } from "langchain/vectorstores/memory";

const embeddings = new OpenAIEmbeddings({
  model: "text-embedding-3-large", // changed from previous model
});

const vectorStore = await MemoryVectorStore.fromExistingIndex(embeddings, {
  // existing data was built with a different dimension
  collectionName: "customer-notes",
});

// Later in a LangGraph node
await vectorStore.addDocuments([
  { pageContent: "Customer requested card replacement", metadata: {} },
]);

// FIXED: use a matching index or rebuild the store
import { OpenAIEmbeddings } from "@langchain/openai";
import { MemoryVectorStore } from "langchain/vectorstores/memory";

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

// Create a fresh store for this embedding dimension
const vectorStore = new MemoryVectorStore(embeddings);

await vectorStore.addDocuments([
  { pageContent: "Customer requested card replacement", metadata: {} },
]);

If you are using a persistent backend like Pinecone or pgvector, the fix is the same:

• •confirm the embedding dimension for the current model
• •recreate the index/table if it was built with a different size
• •do not mix vectors from multiple models in one collection

Other Possible Causes

1. Mixing models across nodes

One LangGraph node embeds text with one model, another node queries with a different one. That creates inconsistent dimensions even if each node looks correct in isolation.

// BAD: two different embedding configs in one graph
const writeEmbeddings = new OpenAIEmbeddings({ model: "text-embedding-3-small" });
const readEmbeddings = new OpenAIEmbeddings({ model: "text-embedding-3-large" });

Fix:

// GOOD: one embedding config shared across graph nodes
const embeddings = new OpenAIEmbeddings({ model: "text-embedding-3-small" });

const writeEmbeddings = embeddings;
const readEmbeddings = embeddings;

2. Persisted test/dev data from an older schema

You changed your embedding provider or model during development, but your local DB still has old vectors.

-- pgvector example: old table remains populated with incompatible vectors
SELECT id, vector_dims(embedding) FROM documents LIMIT 5;

Fix:

-- Rebuild the table or clear stale rows before retesting
TRUNCATE TABLE documents;

3. Wrong field mapped into the vector store

Sometimes the bug is not the embedding model. It’s passing raw text where a vector is expected, or using a custom mapper that returns malformed output.

// BAD: custom mapping returns invalid shape for embeddings pipeline
const docs = [
  { pageContent: "Policy renewal due next month", metadata: { id: 1 } },
];

// Somewhere later you accidentally pass non-embedded content into an API expecting vectors

Fix:

// GOOD: let the embedding class generate vectors end-to-end
await vectorStore.addDocuments(docs);

4. Index dimension hardcoded in config

Some teams hardcode index settings and forget to update them when changing models.

// BAD: hardcoded dimension no longer matches current model
const INDEX_DIMENSION = 1536;

Fix:

// GOOD: keep dimension tied to one known embedding source,
// or derive it once and use it consistently everywhere.
const EMBEDDING_MODEL = "text-embedding-3-small";

How to Debug It

1. •

   Print the active embedding model

   • •Confirm every LangGraph node uses the same Embeddings instance or same model string.
   • •Look for accidental overrides in helper functions.
2. •

   Check the stored index dimension

   • •For pgvector:

     SELECT column_name, udt_name FROM information_schema.columns WHERE table_name = 'documents';
     

   • •For Pinecone/Qdrant/other stores, inspect collection metadata and compare against current embeddings.
3. •

   Log vector length before insert

   • •If your app generates vectors manually, verify their length matches expectations.

   const v = await embeddings.embedQuery("test");
   console.log(v.length);
   

4. •

   Clear local state and retry

   • •Delete local collections, truncate tables, or recreate indexes.
   • •If the error disappears after wiping data, you found a stale-dimension issue.

Prevention

• •Use one shared embeddings module per project and import it everywhere.
• •Treat changing embedding models as a schema migration:
  • •create a new collection/table name, or
  • •rebuild existing vectors before deploying.
• •Add startup checks that validate expected vector dimensions against your store before running LangGraph nodes.

If you want this class of bug to stop showing up in dev builds, make embedding dimensions part of your infrastructure contract. In practice that means stable models, explicit migrations, and no mixed-vector collections.

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.