Multi-Index Strategy for Mastra semanticRecall?
I’ve been reviewing Mastra’s
semanticRecall implementation and from the createEmbeddingIndex logic it appears that, per embedding dimension, a single shared vector index is used.
In a multi-tenant SaaS scenario or as data volume grows, the following needs typically emerge:
- Separating indexes by tenant or even by thread
- Promoting only large tenants to dedicated indexes while smaller ones remain in shared pools
- Improving search performance and isolation (ensuring no accidental cross-tenant leakage)
Given those considerations, what is the recommended approach in Mastra for adopting a multi-index strategy (e.g., shared → dedicated promotion, sharding, use of namespaces)? Are there established patterns in production deployments or a roadmap for more native multi-tenant index management?
Would appreciate any guidance or best practices. Thanks!2 Replies
📝 Created GitHub issue: https://github.com/mastra-ai/mastra/issues/9008
GitHub
[DISCORD:1429401972141723709] Multi-Index Strategy for Mastra seman...
This issue was created from Discord post: https://discord.com/channels/1309558646228779139/1429401972141723709 I’ve been reviewing Mastra’s semanticRecall implementation and from the createEmbeddin...
Hi @vvatanabe ! That's not something that you can do currently, but we're discussing adding this feature. Righ now, you could have separate storage adapters that you select based on the user. That's not perfect, but it would work (you could use the runtimeContext to mount the proper storage adapter)