EverOS 1.0's direction around local-first, Markdown-native, user-owned memory makes a lot of sense. I also understand why the 1.0 cleanup retired the old external infrastructure stack and standardized on Markdown + SQLite + LanceDB.
I wanted to ask whether an optional Milvus-backed derived index would fit the roadmap for larger or more deployment-oriented EverOS setups.
The proposal is not to replace LanceDB as the default, and not to make Milvus a required core dependency. The shape I have in mind is narrower:
- Markdown remains the source of truth.
- SQLite remains responsible for local metadata, state, queues, and lightweight coordination.
- The vector/search index remains rebuildable derived data.
- LanceDB stays the default local backend.
- Milvus is only an opt-in derived index backend for users who choose that deployment profile.
I think this could still align with the EverOS principles:
- Local-first users could use Milvus Lite without running an external service.
- Privacy-sensitive users could self-host Milvus on their own machine or private network.
- Team or heavier-memory deployments could use Milvus standalone, a private Milvus cluster, or a managed Milvus-compatible service when they explicitly want that tradeoff.
- Since the index would be derived from Markdown/SQLite state, users would not lose data ownership or portability if the index is deleted or rebuilt.
This might be useful for cases where users have a larger memory corpus, multiple agents sharing memory, cross-device workflows, or workloads that eventually benefit from a dedicated vector/search backend while still preserving EverOS's local-first source-of-truth model.
Would this kind of opt-in derived-index backend be compatible with the EverOS 1.0 architecture direction?
EverOS 1.0's direction around local-first, Markdown-native, user-owned memory makes a lot of sense. I also understand why the 1.0 cleanup retired the old external infrastructure stack and standardized on Markdown + SQLite + LanceDB.
I wanted to ask whether an optional Milvus-backed derived index would fit the roadmap for larger or more deployment-oriented EverOS setups.
The proposal is not to replace LanceDB as the default, and not to make Milvus a required core dependency. The shape I have in mind is narrower:
I think this could still align with the EverOS principles:
This might be useful for cases where users have a larger memory corpus, multiple agents sharing memory, cross-device workflows, or workloads that eventually benefit from a dedicated vector/search backend while still preserving EverOS's local-first source-of-truth model.
Would this kind of opt-in derived-index backend be compatible with the EverOS 1.0 architecture direction?