[FEAT]: Ability to assign a separate Vector DB per workspace #2669

New issue

Open

opened 2026-02-28 06:15:14 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-28 06:15:14 -05:00

Owner

Originally created by @xardbaiz on GitHub (Jul 16, 2025).

What would you like to see?

Add the ability to assign and configure a separate Vector Database for each workspace. Currently, all workspaces share the same vector DB setup, which limits isolation and flexibility. This feature would allow each workspace to have its own Vector DB settings and integration with external or custom vector stores.

Why it would be useful

Enables strict data isolation between different projects, or between personal and work data.
Supports custom balancing/isolation for high-priority or resource-heavy workspaces
Facilitates compliance or security requirements that mandate data separation

How it could work

In the workspace configuration, add the option to specify which Vector DB to use (provider type, connection string, API key, etc.)
If not set, the workspace will use the default/global Vector DB specified in the app settings
Ensure backward compatibility for existing workspaces

Requested by: xardbaiz via GitHub Copilot

Originally created by @xardbaiz on GitHub (Jul 16, 2025). # What would you like to see? Add the ability to assign and configure a separate Vector Database for each workspace. Currently, all workspaces share the same vector DB setup, which limits isolation and flexibility. This feature would allow each workspace to have its own Vector DB settings and integration with external or custom vector stores. # Why it would be useful - Enables strict data isolation between different projects, or between personal and work data. - Supports custom balancing/isolation for high-priority or resource-heavy workspaces - Facilitates compliance or security requirements that mandate data separation # How it could work - In the workspace configuration, add the option to specify which Vector DB to use (provider type, connection string, API key, etc.) - If not set, the workspace will use the default/global Vector DB specified in the app settings - Ensure backward compatibility for existing workspaces Requested by: xardbaiz via GitHub Copilot

deekerman added the

core-team-only

label

2026-02-28 06:15:14 -05:00

deekerman commented

2026-02-28 06:15:18 -05:00

Author

Owner

@timothycarambat commented on GitHub (Jul 16, 2025):

Somewhere in this repo is a very old issue or comment that was done ages ago when the project first started. In general, it was the reason we dont have this feature and also do not plan to support it. In general, here were the high points:

We want AnythingLLM to be simple. According to statistics, which is a fractional subset of all 3M+ installs 97% of people use the built-in vector db. Considering the questions and the general lack of understanding of RAG in general, most people would never have a preference for a vector DB
So with respect to point 1, we do enable connections to other vector dbs for your primary vector store because indeed some users very much do have a vector db preference for any number of totally valid reasons. The argument per workspace, however, is just a ton of additional work (and possible configuration confusion) that is likely just bad practice. Data stores can be fragmented, but the additional complexity to support this frankly is not needle-moving for the project or even users en masse. This functionality can be done in a fork if it is that critical.
Feature convergence. 99% of the use case for your average vector DB is now at total feature parity, which is also why many people may not choose to change the default. It runs, it works, and they don't manage anything. There are differenent value props for each vector db provider - but within the context of AnythingLLM, if you want to use one specific one, you already can - how that differentiation matters on the workspace level is unclear and nebulous currently.

Ill leave the issue open so people can vote on it, but right now and for a long time standing we have decided to not add an additional per workspace setting. We already split every workspace into its own collection on every provider, so the data is logically separate. This would only change the physical space the data is sent.

@timothycarambat commented on GitHub (Jul 16, 2025): Somewhere in this repo is a very old issue or comment that was done ages ago when the project first started. In general, it was the reason we dont have this feature and also do not plan to support it. In general, here were the high points: 1. We want AnythingLLM to be simple. According to statistics, which is a fractional subset of all 3M+ installs 97% of people use the built-in vector db. Considering the questions and the general lack of understanding of RAG in general, most people would never have a preference for a vector DB 2. So with respect to point 1, we **do enable connections to other vector dbs for your primary vector store** because indeed some users very much do have a vector db preference for any number of totally valid reasons. The argument _per workspace_, however, is just a ton of additional work (and possible configuration confusion) that is likely just bad practice. Data stores can be fragmented, but the additional complexity to support this frankly is not needle-moving for the project or even users en masse. This functionality can be done in a fork if it is that critical. 3. Feature convergence. 99% of the use case for your average vector DB is now at total feature parity, which is also why many people may not choose to change the default. It runs, it works, and they don't manage anything. There **are** differenent value props for each vector db provider - but within the context of AnythingLLM, if you want to use one specific one, you already can - how that differentiation matters on the workspace level is unclear and nebulous currently. Ill leave the issue open so people can vote on it, but right now and for a long time standing we have decided to not add an additional per workspace setting. We already split every workspace into its own collection on every provider, so the data is logically separate. This would only change the physical space the data is sent.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/anything-llm#2669

No description provided.

Rows
Columns