Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-21 01:25:28 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #4159] [FEAT]: Ability to assign a separate Vector DB per workspace #2645

New Issue
Open
opened 2026-02-22 18:30:35 -05:00 by yindo · 1 comment
yindo commented 2026-02-22 18:30:35 -05:00
Owner
Copy Link
Copy Source

Originally created by @xardbaiz on GitHub (Jul 16, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4159

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). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4159 # 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
yindo added the core-team-only label 2026-02-22 18:30:35 -05:00
yindo commented 2026-02-22 18:30:36 -05:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
yindo changed title from [FEAT]: Ability to assign a separate Vector DB per workspace to [GH-ISSUE #4159] [FEAT]: Ability to assign a separate Vector DB per workspace 2026-06-05 14:47:44 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label core-team-only
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2645
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?