Databases 11 min read

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.

360 Zhihui Cloud Developer
360 Zhihui Cloud Developer
360 Zhihui Cloud Developer
How Milvus Implements Multi‑Tenant Architecture: Design, RBAC, and Resource Group Isolation

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.

vector databaseMilvusMulti‑TenantRBACisolationResource Groups
360 Zhihui Cloud Developer
Written by

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.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.