[FEAT] Support for newer ChromaDB version

There are ongoing issues with compatibility between VectorCode and recent versions of ChromaDB. You can see a little discussion about it in PR #241, and i would like it not to get lost.

As we discussed, VectorCode is currently recommended for use with ChromaDB version 0.6.3. Support for newer versions has not yet been released. This creates a problem that I have encountered. Older versions of the chroma image have problems that prevent them from being used with vectorcode via Docker.

Right now working approach to use standalone chromadb server is there:
Install chroma via uv uv tool install chromadb==0.6.3. And run it like this uv tool run --from chromadb chroma run

Also you can start a systemd service like this:

[Unit]
Description=ChromaDB Server
After=network.target

[Service]
Type=simple
ExecStart=/home/youruser/.local/bin/uv tool run --from chromadb chroma run
Restart=on-failure
WorkingDirectory=/home/youruser/

[Install]
WantedBy=multi-user.target

Thanks! So this is why I couldn't seem to be able make VectorCode use my ChromaDB (v0.6.3) server which was started by a systemd service that instead used docker compose up -d, I guess?

This was my docker-compose.yaml file:

---
services:
  chromadb:
    image: chromadb/chroma:0.6.3
    volumes:
      - chroma-data:/data
    environment:
      - CHROMA_OPEN_TELEMETRY__ENDPOINT=${CHROMA_OPEN_TELEMETRY__ENDPOINT}
      - CHROMA_OPEN_TELEMETRY__SERVICE_NAME=${CHROMA_OPEN_TELEMETRY__SERVICE_NAME}
      - OTEL_EXPORTER_OTLP_HEADERS=${OTEL_EXPORTER_OTLP_HEADERS}
    restart: unless-stopped
    ports:
      - 8000:8000
    healthcheck:
      test: [ "CMD", "curl", "-f", "http://localhost:8000/api/v2/heartbeat" ]
      interval: 30s
      timeout: 10s
      retries: 3
    networks:
      - net

networks:
  net:
    driver: bridge

volumes:
  chroma-data:
    driver: local

And I setup a systemd user service with this unit file:

[Unit]
Description = Chroma Service

After = network.target
Requires = 

[Service]
Type = oneshot
WorkingDirectory = /home/lukeemhigh/git-repos/personal/docker-compose/chromadb
ExecStart = /usr/bin/docker compose up -d
ExecStop = /usr/bin/docker compose down
RemainAfterExit = true

[Install]
WantedBy = default.target

So this approach is not feasible at the moment?

The documentation for Chroma is for the latest version. I had to dig through the history to find the correct configuration for 0.6.3 in Docker. It used to have a different data directory.

chroma:
  image: chromadb/chroma:0.6.3
  environment:
    - IS_PERSISTENT=TRUE
  ports:
    - "0.0.0.0:8000:8000"
  volumes:
    - ./chroma-data:/chroma/chroma

The documentation for Chroma is for the latest version. I had to dig through the history to find the correct configuration for 0.6.3 in Docker. It used to have a different data directory.
chroma:
  image: chromadb/chroma:0.6.3
  environment:
    - IS_PERSISTENT=TRUE
  ports:
    - "0.0.0.0:8000:8000"
  volumes:
    - ./chroma-data:/chroma/chroma

I've tried to initialize/vectorise a project with this chromadb configuration and for some reason VectorCode still defaults to use its own bundled chroma instance:

WARNING: vectorcode.common : Using local database at /home/lukeemhigh/.local/share/vectorcode/chromadb/.
WARNING: vectorcode.common : Starting bundled ChromaDB server at http://127.0.0.1:45531.
/home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages/fastapi/openapi/utils.py:246: UserWarning: Duplicate Operation ID root for function root at /home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages/chromadb/
server/fastapi/__init__.py
  warnings.warn(message, stacklevel=1)
/home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages/fastapi/openapi/utils.py:246: UserWarning: Duplicate Operation ID reset for function reset at /home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages/chromad
b/telemetry/opentelemetry/__init__.py
  warnings.warn(message, stacklevel=1)
/home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages/fastapi/openapi/utils.py:246: UserWarning: Duplicate Operation ID version for function version at /home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages/chr
omadb/server/fastapi/__init__.py
  warnings.warn(message, stacklevel=1)
/home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages/fastapi/openapi/utils.py:246: UserWarning: Duplicate Operation ID heartbeat for function heartbeat at /home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages
/chromadb/server/fastapi/__init__.py
  warnings.warn(message, stacklevel=1)
/home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.13/site-packages/fastapi/openapi/utils.py:246: UserWarning: Duplicate Operation ID pre_flight_checks for function pre_flight_checks at /home/lukeemhigh/.local/share/uv/tools/vectorcode/lib/python3.
13/site-packages/chromadb/server/fastapi/__init__.py
  warnings.warn(message, stacklevel=1)
Vectorising files...: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 1/1 [00:00<00:00,  3.94it/s]
  Add    Update    Removed    Skipped    Failed
-----  --------  ---------  ---------  --------
    1         0          0          0         0

This is my ~/.config/vectorcode/config.json5 for reference:

{
  "db_url": "http://127.0.0.1:8000",
}

Using localhost obviously didn't change the result.

Did you check the docker compose logs and make sure your server is starting properly?

I actually have mine running via podman on a local home server. It's been working great, though I was bitten by the recent openapi title check that was just reverted.

I've tried to initialize/vectorise a project with this chromadb configuration and for some reason VectorCode still defaults to use its own bundled chroma instance:

WARNING: vectorcode.common : Using local database at /home/lukeemhigh/.local/share/vectorcode/chromadb/.
WARNING: vectorcode.common : Starting bundled ChromaDB server at http://127.0.0.1:45531.

Also, check which version of vectorcode you are using. Looks like you need to upgrade to 0.7.9 as it has fixed a recent bug that caused incompatibility with the recommended chroma version.

@rieger-jared

For people who were affected by the openapi title check (#241), it was because I expected the Docker version of chromadb to behave the same as the PyPI package (which is what I use on my development machine). The latest VectorCode release (0.7.9) reverted the PR that caused the issues.

Regarding the upgrade to Chromadb 1.0.x, I've mentioned under various issues/PRs that it was caused by the newer chromadb releases being unable to smoothly migrate the old database files to the newer format. I tried opening an issue in the upstream repo, but they haven't been able to help.

Also, @rieger-jared opened #165 (and #221) about supporting various (more than ChromaDB) database backends, but it'll be even more complicated than switching to Chroma 1.0.x. @rieger-jared, could you briefly tell us about your progress here? If it's going to take a lot more time, I'll just take baby steps and focus on making VectorCode work with Chromadb 0.6.3 and 1.0.x. The latter should be simpler than #221 because we have fewer DB backends to worry about.

@jbigler

@jbigler @outp1 Upgrading vectorcode to 0.7.9 did the trick. Thanks both for the support!

@Davidyz

For people who were affected by the openapi title check (#241), it was because I expected the Docker version of chromadb to behave the same as the PyPI package (which is what I use on my development machine). The latest VectorCode release (0.7.9) reverted the PR that caused the issues.

Regarding the upgrade to Chromadb 1.0.x, I've mentioned under various issues/PRs that it was caused by the newer chromadb releases being unable to smoothly migrate the old database files to the newer format. I tried opening an issue in the upstream repo, but they haven't been able to help.

Also, @rieger-jared opened #165 (and #221) about supporting various (more than ChromaDB) database backends, but it'll be even more complicated than switching to Chroma 1.0.x. @rieger-jared, could you briefly tell us about your progress here? If it's going to take a lot more time, I'll just take baby steps and focus on making VectorCode work with Chromadb 0.6.3 and 1.0.x. The latter should be simpler than #221 because we have fewer DB backends to worry about.

Hey @Davidyz, sorry for the slow response. As always, this is turning out to be a bigger than I thought. I'm currently working on how to have the existing code work with Langchains document model.

I'm currently working on how to have the existing code work with Langchains document model.

In this case, I'll gradually start to make a compatibility layer that supports chromadb 0.6 and 1.0.x first. It probably wouldn't be something that other DBs can plug into right away, but it should keep the database stuff at one place, and give us a better view of the crud part of the codebase.

I added a suggestion in the discussion, can you pls look into it?

Navigation Menu

Repository navigation

[FEAT] Support for newer ChromaDB version #247

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[FEAT] Support for newer ChromaDB version #247

Description

Activity

outp1 commented on Jul 16, 2025

lukeemhigh commented on Jul 16, 2025

jbigler commented on Jul 17, 2025

lukeemhigh commented on Jul 17, 2025

jbigler commented on Jul 17, 2025

outp1 commented on Jul 17, 2025

Davidyz commented on Jul 17, 2025

lukeemhigh commented on Jul 17, 2025

rieger-jared commented on Jul 22, 2025

Davidyz commented on Jul 22, 2025

afidegnum commented on Jul 27, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions