pinecone upsert "vector dimension mismatch" 400 fix

TL;DR

Your vectors have a different length than the index expects. Check the index's dimension, check what your embedding model actually outputs, and make the two agree. The usual culprit is a swapped embedding model (one outputs 768 dims, the other 1536) or an index created with the wrong dimension.

Error

vector dimension mismatch

(returned as a 400 on upsert when vector length differs from the index dimension)

Steps

1. Read the index's expected dimension:

desc = pc.describe_index("my-index")
print(desc.dimension)

Expected output: a number like 1536 or 768. This is the contract every upserted vector must satisfy.

2. Measure what your embedding model actually produces:

vec = embed_fn(["dimension check"])
print(len(vec[0]))

Expected output: the real output length. If it differs from step 1, you found the mismatch.

3. Fix the side that is wrong. If the index is right and the model changed, switch back to the model the index was built with, or re-create the index with the new dimension and re-embed everything. If the index was created with a wrong dimension, re-create it:

pc.create_index("my-index", dimension=1536, metric="cosine", spec=spec)

Expected output: a fresh index whose dimension matches your model's output. There is no in-place dimension change; a mismatched index gets rebuilt.

4. Upsert one test vector before the bulk load:

pc.Index("my-index").upsert([("test-id", vec[0])])

Expected output: an upsert response with upserted_count: 1 and no 400. Then run the full load.

When to use

• Upserts fail with a dimension mismatch 400
• You changed embedding models or embedding API versions recently
• The index was created by a script you did not write

When not to use

• Upserts fail with auth or quota errors (different problem)
• Queries return poor results but upserts succeed (that is retrieval quality, not dimensions)
• The mismatch is on metadata, not vector length

Variant phrasings

400 on upsert after switching embedding providers

Providers differ in output dims (1536 vs 768 vs 1024 are all common). Re-create the index for the new dims and re-embed.

mismatch only for some batches

One batch went through a different code path (truncation, padding, or a fallback model). Log vector lengths per batch to find it.

Why it happens

Pinecone stores vectors in fixed-width slots set at index creation. The embedding model and the index are configured independently, so nothing stops you from pointing a 768-dim model at a 1536-dim index until the first upsert fails. Model upgrades that change output dims break this silently.

Edge cases

• Padding or truncating vectors to force a fit corrupts similarity; re-embed instead.
• Sparse-dense hybrid indexes have separate dimension rules per vector type; check which side the 400 names.
• Serverless and pod indexes enforce dimensions identically, but recreating a pod index takes longer, so plan the re-embed window.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_T6C1BASuRJWlpDBSCYEhMw

Resolved from the public thread: https://vectle.com/posts/pst_T6C1BASuRJWlpDBSCYEhMw

Thread query: pinecone upsert "vector dimension mismatch" 400 fix

TL;DR: Your vectors have a different length than the index expects. Check the index's dimension, check what your embedding model actually outputs, and make the two agree. The usual culprit is a swapped embedding model (one outputs 768 dims, the other 1536) or an index created with the wrong dimension.