Open WebUI Memory Broke After Switching Embedding Models: The Chroma Dimension Fix

If you self-host Open WebUI and you've ever swapped the embedding model in the settings, this one's for you. There's a footgun hiding in the vector store, and it doesn't show up until you try to use memory again. Then it's a 500 error with a log line that takes a minute to decode.

The error looks like this:

chromadb.errors.InvalidArgumentError: Collection expecting embedding with dimension of 640, got 1024

Swap the numbers around depending on your models. The value on the left is the dimension your old model used. The one on the right is what your new model outputs.

Why this happens

Chroma, the vector DB Open WebUI uses by default, fixes a collection's embedding dimension the first time you add data to it. That dimension gets baked into the collection's config at creation, and Chroma won't let you change it later. There's no 'alter collection, new dimension' operation. This is documented behavior, not a bug.

Open WebUI stores your memories in per-user collections named user-memory-{user.id}, and your knowledge-base files in file-{file.id} collections. So all your old collections were created at 640 dims, your new model embeds at 1024, and every insert gets rejected because the collection is still expecting 640.

The sneaky part: deleting memories in the UI does not remove the collections. And the 'Reset Vector Storage Database' button in the settings clears the knowledge index, but stale memory and file collections can survive all of it. There's a reset button for this exact situation. It doesn't do what you hope.

The fix

This is the manual cleanup that works. Verified against Open WebUI v0.11.0 running in Docker.

1. Back up first. The vector store lives inside your Open WebUI volume. Find the mount point:

docker volume inspect openwebui_openwebui

Look at the Mountpoint field in the output. Substitute your real volume name here, whatever your compose file calls it.

2. Stop the container. docker compose down for the open-webui service, or stop the container. Chroma holds its SQLite file open, and you don't want a live process writing while you're in there.

3. See what's actually stored. The collection metadata is a SQLite DB under {volume}/_data/vector_db/. Query it:

SELECT id, name, dimension FROM collections;

Every row with dimension = 640 is a stale collection. In a typical report you get a pile of file-... entries plus one or more user-memory-... entries.

4. Delete the stale collections with the Chroma Python client, pointed at that same directory:

import chromadb

client = chromadb.PersistentClient(
    path="/var/lib/docker/volumes/openwebui_openwebui/_data/vector_db"
)  # <- your actual Mountpoint from step 1

# From the SQLite query in step 3, list every collection with dimension = 640
stale = [
    'file-3fc2655d-5c01-462b-a6d2-1ba54cd8063a',
    'user-memory-0c77e0d9-9ff9-406b-ae19-85910773e103',
    # ...all the other 640-dim ones
]

for name in stale:
    try:
        client.delete_collection(name)
        print(f'deleted {name}')
    except ValueError:
        print(f'already gone: {name}')

5. Start Open WebUI again. The next memory add or file upload re-creates the collection at the new dimension, and everything works.

If you'd rather not be surgical, you can delete the whole vector_db directory instead. It works, but it's the blunt option: every collection goes, including your current knowledge-base indexes, and you re-embed everything from scratch. The per-collection delete above keeps the collections that are already at the right dimension.

The actual lesson

Switching embedding models is a schema change for your vector store, not a config tweak. The collection dimension gets locked in at first insert and never moves. So either keep your embedding model stable once you have real data in there, or budget time to wipe and re-embed when you switch.

There's an open issue on the Open WebUI tracker about this, with a few related reports of the same class, and a fix is being discussed upstream. As of writing nothing is merged, so the manual cleanup is the reliable path. If you hit this error, don't fight the reset buttons. Find the stale collections and delete them.