bug(server): switching embedding provider silently drops writes due to vector dimension mismatch

[g-kartik]

Description

When the embedding provider is switched (e.g. from OpenAI to Gemini) via the dashboard or POST /configure, the pgvector collection retains the original provider's vector dimension. Subsequent memory writes silently fail — the API returns a success response with a memory ID, but nothing is persisted to the database.

Steps to Reproduce

1. Start the server with make bootstrap (defaults to OpenAI embedder — creates memories table with vector(1536))
2. Switch the embedder to Gemini (gemini-embedding-001) via the dashboard Configuration page
3. POST /memories with a message
4. Observe the success response:

{
    "results": [
        {
            "id": "f88e7d7d-b882-4975-b9cf-7f945e244eb3",
            "memory": "My name is John and I am a software engineer",
            "event": "ADD"
        }
    ]
}

5. GET /memories?user_id=... → {"results": []}
6. Query postgres directly:

SELECT COUNT(*) FROM memories;
-- Returns: 0

Root Cause

There are three layers to this bug:

Layer 1 — embedding_model_dims defaults to 1536 and is never inferred from the embedder

The pgvector config hardcodes embedding_model_dims = 1536 as its default:

# mem0/configs/vector_stores/pgvector.py
embedding_model_dims: Optional[int] = Field(1536, description="Dimensions of the embedding model")

This default is OpenAI-specific and silently wrong for every other provider. Critically, Memory.__init__ instantiates self.embedding_model before self.vector_store and already has the correct dimension available (self.embedding_model.config.embedding_dims = 768 for Gemini), but never uses it to set vector_store.config.embedding_model_dims. The information is present but ignored.

Layer 2 — Table created with wrong dimensions on every restart

Even after manually dropping the memories table and restarting, it is immediately recreated with vector(1536) because the pgvector config default (Layer 1) kicks in before any override can correct it.

Layer 3 — Dimension mismatch fails silently

Inserting a 768-dim vector into a vector(1536) column raises no exception to the caller. The API returns 200 with a memory ID as if the write succeeded, but nothing is persisted.

Expected Behaviour

• Memory.__init__ should auto-set vector_store.config.embedding_model_dims from self.embedding_model.config.embedding_dims when not explicitly provided
• Or at minimum, validate that the two match and raise a clear error if they don't
• The dimension mismatch on insert should propagate as an error, not be swallowed silently

Actual Behaviour

• memories table is created with vector(1536) regardless of the configured embedder
• POST /memories returns 200 with a valid-looking memory ID
• The memory is never actually stored in postgres
• GET /memories returns empty results
• No error or warning anywhere in the logs

Impact

This is a silent data loss bug. Users believe their memories are being stored (success response + memory ID), but they are not. The only way to diagnose it is to directly query the postgres table and inspect vector dimensions — not at all obvious.

This affects every non-OpenAI embedding provider (Gemini, Cohere, etc.) that uses a dimension other than 1536.

Workaround

Explicitly pass embedding_model_dims in the vector store config (not the embedder config) via POST /configure:

{
  "embedder": {"provider": "gemini", "config": {"model": "models/gemini-embedding-001"}},
  "vector_store": {"provider": "pgvector", "config": {"embedding_model_dims": 768}}
}

Then drop and recreate the memories table:

DROP TABLE IF EXISTS memories;
DROP TABLE IF EXISTS mem0migrations;

Then restart the container.

Environment

• Self-hosted server via docker compose
• OpenAI embedder → Gemini gemini-embedding-001 (1536 → 768 dims)
• Reproduced on: 2026-04-27

Related Issues

• bug(server): dashboard saves wrong API key on provider change; .env cannot override database config #4984 — Dashboard saves wrong API key on provider change; .env cannot override database config

[PHclaw]

This is a dangerous silent failure - users think their data is being saved when it's not. A few ways to fix this:\n\n1. Validate on switch: Before changing the embedder config, check if existing collections have incompatible dimensions. If so, reject the switch and show a warning with the option to migrate or wipe.\n\n2. Dimension mismatch detection: On the first write after a provider switch, attempt a test insert with the new dimension. If it fails (dimension mismatch), return an explicit error instead of a fake success.\n\n3. Admin API flag: Add orce=true parameter to POST /configure for when users intentionally want to switch providers (and accept data loss). The default behavior should be safe, not silent.

[PHclaw]

For the embedding provider switch dropping writes silently:

The silent failure is caused by dimension mismatch between the new provider's embeddings and the existing collection. The fix is to:

1. Detect the dimension change and create a new collection:

def switch_embedding_provider(new_provider: str):
    new_dim = get_embedding_dimension(new_provider)
    existing_dim = get_collection_dimension()
    
    if new_dim != existing_dim:
        # Create new collection with correct dimension
        new_collection = f"memories-{new_dim}"
        create_collection(new_collection, dim=new_dim)
        # Migrate existing memories if needed
    else:
        new_collection = existing_collection
    
    return new_collection

2. Raise an explicit error when dimension mismatch is detected:

if len(embedding) != self.collection.dimension:
    raise ValueError(
        f"Embedding dimension {len(embedding)} does not match "
        f"collection dimension {self.collection.dimension}. "
        f"Switch to a compatible provider or re-index memories."
    )

[PHclaw]

The dimension mismatch silently drops writes because:

1. pgvector collection is created with OPENAI_DIM=1536
2. Switch to Gemini (GEMINI_DIM=768)
3. New embeddings are 768-dim but collection still expects 1536
4. pgvector rejects mismatched dimensions silently OR accepts but search returns wrong results

Fix: Add explicit dimension validation:

def validate_embedding(embedding, expected_dim):
    if len(embedding) != expected_dim:
        raise ValueError(
            f"Embedding dimension mismatch: got {len(embedding)}, "
            f"expected {expected_dim}. Clear existing collection or "
            f"use a provider with {expected_dim}-dim embeddings."
        )

And validate on every write, not just on search.

[PHclaw]

The dimension mismatch fix:

# In the vector store add() method:
def add(self, documents, embeddings, ...):
    actual_dim = len(embeddings[0])
    expected_dim = self.collection.dimension
    
    if actual_dim != expected_dim:
        raise ValueError(
            f"Embedding dimension mismatch: got {actual_dim}, "
            f"expected {expected_dim}. Clear collection or use compatible provider."
        )

This raises an explicit error instead of silently dropping writes or returning wrong search results.

[Adelagric]

Same class of bug we documented in #5245 — silent vector failures inside the SDK's batch ingest path. Specifically for dimension mismatch on provider swap: there's no runtime check that len(returned_vector) == configured_dim anywhere in mem0/embeddings/, so the wrong-dim vector either crashes the vector store on write (PGVector/Qdrant) or pollutes the index (LanceDB).

One workaround that doesn't require touching the mem0 codebase: an out-of-process gRPC validator in front of the vector DB that enforces L2 + NaN/Inf + dim invariants. I open-sourced one yesterday under Apache 2.0: https://github.com/Adelagric/vector-router. Configurable via OPENAI_BASE_URL for OpenAI-compatible setups (no code change in mem0). Posting here in case it's useful while a SDK-side fix is being designed.

[kartik-mem0]

Confirmed silent data loss. Traced three layers on main:

Layer 1 — hardcoded default dimension (mem0/configs/vector_stores/pgvector.py line 9):

embedding_model_dims: Optional[int] = Field(1536, description="Dimensions of the embedding model")

This default is OpenAI-specific. When a non-1536-dim embedder (e.g. Gemini at 768) is configured, the pgvector table is created with vector(1536) regardless, because the embedder's actual dimension is never propagated to the vector store config during Memory.__init__.

Layer 2 — table recreated with wrong dims on restart — The pgvector __init__ runs CREATE TABLE IF NOT EXISTS ... embedding vector(<embedding_model_dims>) every startup. With the Layer 1 default in effect, the table is always created or left with vector(1536), even after manually dropping it.

Layer 3 — dimension mismatch fails silently — A 768-dim insert into a vector(1536) column is rejected by pgvector, but the server returns 200 with a valid-looking memory ID. The exception is swallowed in the v3 batch insert path. GET /memories returns [].

Combined: users see ADD responses with valid IDs, no error in logs, zero rows in postgres. Only way to diagnose is a direct SELECT against the table and dimension inspection.

This affects every non-OpenAI embedder that differs from 1536 dims — Gemini (768), Cohere (1024), etc.

PR #4990 fixes all three layers. Routing to review queue.