[ENHANCEMENT] alternative embedding database

[yggdrasil75]

Problem (one or two sentences)

Codebase indexing frequently fails when using a docker version of qdrant, making it require using the paid online (not self hosted) version. updating to use something less broken such as a more common chromadb would be significantly better. (ticket exists to try and fix it here, but hasnt been updated in months)

Context (who is affected and when)

docker qdrant users

Desired behavior (conceptual, not technical)

switch to chromadb or other alternative

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote-v0]

I have been looking into this issue and wanted to share some observations and questions before proposing a plan.

Current Architecture:
The codebase already has a well-defined IVectorStore interface (src/services/code-index/interfaces/vector-store.ts) that abstracts vector DB operations. The Qdrant implementation lives in src/services/code-index/vector-store/qdrant-client.ts and is instantiated via a factory pattern in src/services/code-index/service-factory.ts. This means adding an alternative backend is architecturally feasible without a full rewrite -- the main work would be creating a new implementation of IVectorStore and wiring it up as a selectable option.

However, Qdrant is referenced in many places: config management, UI settings components, i18n strings across 15+ languages, type definitions, and tests. A full replacement (removing Qdrant entirely) would be a very large change.

Questions before I propose a plan:

1. Replace vs. Add Alternative? Should Qdrant be fully replaced with ChromaDB (or another DB), or would it be better to add ChromaDB as an additional vector store option that users can select? Adding it as an option would be less disruptive and would let users who have Qdrant working keep using it.

2. Which alternative? The issue mentions ChromaDB. Are there other alternatives worth considering? For example:

   • ChromaDB -- popular, Python-native (has a JS client too), runs as a server or embedded
   • LanceDB -- embedded (no server needed), Rust-based with JS bindings, zero-config
   • Built-in/embedded option -- something like a simple local file-based store that requires no external services at all

   An embedded option like LanceDB would eliminate the Docker dependency entirely, which seems to be the core pain point.

3. Specific Docker Qdrant issues? The issue mentions Qdrant "frequently fails" with Docker. Could you share more details about the specific failures? It is possible that fixing the Docker connectivity issues (e.g., better error handling, reconnection logic, or configuration defaults) could be a simpler path to resolving the core problem.

Please mention @roomote in a comment with your answers, and I will propose a concrete implementation plan.