How Milvus Implements Multi‑Tenant Architecture: Design, RBAC, and Resource Group Isolation
This article explains Milvus's multi‑tenant architecture, covering its layered data structures, role‑based access control, resource‑group based physical isolation, practical code examples, and future directions for cost‑effective, cloud‑native vector database deployments.
What Is Multi‑Tenant Architecture
Multi‑tenant architecture allows multiple customers (tenants) to share a single application instance and underlying infrastructure while keeping each tenant's data isolated, similar to storing different ingredients in the same refrigerator without cross‑contamination.
Advantages of Multi‑Tenant
Cost efficiency: Shared instances reduce hardware and operational expenses for providers and lower subscription prices for tenants.
Ease of maintenance and upgrades: A single instance can be updated centrally, simplifying operations and accelerating releases.
Data isolation: Architectural designs ensure complete separation of each tenant's data despite a shared database.
Flexibility: Tenants can scale usage up or down on demand, fitting seasonal or rapidly changing business needs.
Milvus Multi‑Tenant Design and Implementation
Milvus achieves multi‑tenant isolation through a combination of layered data structures, role‑based access control (RBAC), and resource groups.
Layered Data Structure
Milvus supports four tenant levels:
Database level: Each tenant receives a dedicated database that can contain multiple collections. Resource groups can fully isolate data, but the default cluster limits to 64 databases.
Collection level: Each tenant is assigned one or more collections. Isolation is achieved via resource groups; the default limit is 65,535 collections.
Partition level: Tenants share collections but are placed in separate partitions that must be created manually. Up to 1,024 partitions per collection allow millions of tenants.
Partition‑Key level: All tenants share a collection and schema, with data automatically routed to 16 physical partitions based on a partition key. This approach supports up to millions of tenants per collection and billions at the cluster level, though data cannot be fully isolated by resource groups.
RBAC Permissions
RBAC (Role‑Based Access Control) in Milvus consists of four main components:
Resources: Instances, databases, and collections.
Privileges and privilege groups: Actions such as creating a collection or inserting data; groups combine multiple privileges.
Roles: Aggregations of privileges on specific resources.
Users: Individuals identified by a unique ID and assigned one or more roles.
Example: creating a user jack, a role jack_role, granting collection‑level and database‑level admin privileges, and assigning the role to the user.
from pymilvus import MilvusClient
client = MilvusClient(uri="http://localhost:19530", token="root:Milvus")
# Create user
client.create_user(user_name="jack", password="jack@Password")
# Create role
client.create_role(role_name="jack_role")
# Grant collection‑level admin privilege
client.grant_privilege_v2(role_name="jack_role", privilege="CollectionAdmin", collection_name='*', db_name='nobody')
# Grant database‑level admin privilege
client.grant_privilege_v2(role_name="jack_role", privilege="DatabaseAdmin", collection_name='*', db_name='nobody')
# Assign role to user
client.grant_role(user_name="jack", role_name="jack_role")Physical Isolation via Resource Groups
A resource group can contain multiple query nodes. Milvus assigns query nodes to resource groups, thereby physically separating tenants.
Management hierarchy: query nodes → resource groups → databases/collections. By mapping logical resources (databases, collections) to physical resources (query nodes) within distinct groups, multi‑tenant isolation is achieved.
Example allocation:
Tenant 1 uses database X (collection A) assigned to resource group 1 with one query node.
Tenant 2 uses databases Y and Z (collections D) assigned to resource group 2 with two query nodes.
Tenant 3 uses database Z (collection E) assigned to resource group 3 with one query node.
Practical Multi‑Tenant Deployment Steps
1. Create a tenant (e.g., user jack) following the RBAC example.
2. Create a resource group that matches the tenant's resource request. Example creates a group with two query nodes:
import pymilvus
name = "rg_for_jack"
node_num = 2
try:
milvus_client.create_resource_group(name, config=ResourceGroupConfig(requests={"node_num": node_num}, limits={"node_num": node_num}))
print(f"Succeeded in creating resource group {name}.")
except Exception:
print("Failed to create the resource group.")3. Assign the tenant's collection to the resource group to achieve isolation:
collection_name = "demo"
resource_groups = ['rg_for_jack']
milvus_client.load_collection(collection_name=collection_name, replica_number=2, _resource_groups=resource_groups)Future Exploration (Hulk Project)
Using resource groups, multiple tenants can share a single Milvus cluster, paying only for the query nodes they consume, which reduces overall cost. Additionally, different business lines within the same project can share the cluster while maintaining resource isolation through resource‑group management.
Conclusion
Milvus's multi‑tenant mechanism provides true cloud‑native isolation for vector databases by combining layered data structures with flexible resource‑group configurations. It enables a spectrum of isolation scenarios—from lightweight tenants to full business‑line segregation—ensuring privacy, compliance, and optimal resource utilization across shared infrastructure.
360 Zhihui Cloud Developer
360 Zhihui Cloud is an enterprise open service platform that aims to "aggregate data value and empower an intelligent future," leveraging 360's extensive product and technology resources to deliver platform services to customers.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
