Hi maintainers,
I was looking at MemoryOS's storage path and wanted to ask whether you would be open to a small storage-provider abstraction plus optional Milvus support.
The README describes pluggable storage engines, and the current code appears to centralize vector storage around a Chroma-based provider. At the same time, memoryos.py looks like it still instantiates that Chroma path directly, so adding another vector backend would likely need a small provider/factory boundary first.
A possible scoped shape:
- Keep Chroma as the default local backend.
- Define a narrow storage provider interface for add/update/delete/search and metadata handling.
- Move the current Chroma path behind that interface.
- Add an optional Milvus provider, with Milvus Lite for local development and Milvus server / Zilliz Cloud for larger deployments.
- Add focused tests for provider selection and retrieval behavior.
Would this fit MemoryOS's roadmap? If yes, would you prefer the Milvus provider in core as an optional extra, or as an external adapter package?
Hi maintainers,
I was looking at MemoryOS's storage path and wanted to ask whether you would be open to a small storage-provider abstraction plus optional Milvus support.
The README describes pluggable storage engines, and the current code appears to centralize vector storage around a Chroma-based provider. At the same time,
memoryos.pylooks like it still instantiates that Chroma path directly, so adding another vector backend would likely need a small provider/factory boundary first.A possible scoped shape:
Would this fit MemoryOS's roadmap? If yes, would you prefer the Milvus provider in core as an optional extra, or as an external adapter package?