How Metadata‑Driven Multi‑Tenant Architecture Powers Scalable SaaS Platforms

Introduction

"When the Tao is used without filling, it is like the source of all things." — Laozi

Three‑Step Roadmap for Business System Development

Rapidly build business pipelines to get online services running, enable fast iteration, and solve survival problems.

After the pipeline is stable, focus on supporting faster growth by addressing scalability challenges.

Once rapid growth is supported, pursue fine‑grained improvements: refine system functions and experience, abstract capabilities, consolidate products, and boost efficiency.

Looking ahead, the goal is to turn platform products into SaaS offerings, exposing valuable capabilities to the broader industry and providing a foundation for the commercial ecosystem.

Key Questions for SaaS Platform Enablement

How to schedule and allocate compute resources on demand for different user needs? (IaaS/PaaS)

How to ensure strict data isolation so each user only sees their own data? (PaaS)

How to allow users to add custom data objects or extend data models on standard objects? (PaaS & SaaS)

How to compose features per user to satisfy scenarios ranging from basic to professional? (SaaS)

How to upgrade the platform without affecting existing user data or functionality? (IaaS, PaaS, SaaS)

These questions highlight that the core of SaaS productization lies in providing on‑demand compute, secure multi‑tenant data handling, and flexible feature composition.

Solving the Core Problems

Elastic compute and Serverless address the compute problem. Domain‑driven design and micro‑services address function decomposition and on‑demand composition. However, this leads to data redundancy, inconsistency, and high coupling between logical and physical models.

Introducing a Metadata Layer

To break the tight coupling between business logic and physical storage, we add a metadata layer. The process includes:

Model the business domain and define a logical model.

Abstract the logical model into metadata (the definition of objects, fields, and relationships).

Store the metadata in dedicated tables.

Map metadata to a physical storage schema, keeping the logical‑physical separation.

This approach enables schema changes without touching the underlying tables.

Metadata‑Driven Multi‑Tenant Architecture Overview

The architecture consists of five logical layers:

Data layer (stores raw business data).

Common metadata layer (stores standard object and field definitions).

Tenant‑specific metadata layer (stores custom object and field definitions per tenant).

Universal Data Dictionary (UDD) engine (maps object models to physical storage, provides query parsing, optimization, and full‑text search).

Platform service layer (provides PaaS services such as object creation, permission models, workflows, and UI components).

Standard application layer (offers end‑to‑end standard business functions).

Tenant virtual application layer (allows tenants to define custom applications on top of the platform).

The cornerstone is the data layer, which stores both standard and custom data in a unified, shared database.

Core Metadata Tables

Objects Table

Each record represents an object definition (standard or custom). Key fields include:

ObjID – unique identifier for the object.

OrgID – tenant identifier for data isolation.

ObjName/Name – developer name of the object.

Label – display name.

Fields Table

Each record defines a field belonging to an object. Important columns:

FieldID – unique field identifier.

OrgID – tenant identifier.

ObjID – object to which the field belongs.

FieldName/Name – developer name.

Label – display name.

FieldNum – maps to a column (ValueX) in the Data table.

DataType – field data type (Number, TEXT, Currency, Date/Time, Email, Text Area, Lookup, Master‑Detail, etc.).

DigitLeft, Scale, TextLength – type‑specific constraints.

RelatedTo, ChildRelationshipName – used for relationship fields.

IsRequired, IsUnique, IsIndexed – validation and indexing flags.

Data Tables

Data Table (MTData)

Stores actual records for all objects. Columns include:

GUID – primary key for each record.

ObjID – links to the object definition.

Name – record name.

Value0 … Value500 – flexible string columns that hold field values; the column used is determined by FieldNum in the Fields table.

Clobs Table

Stores large text (CLOB) data referenced by the Data table.

Indexing Tables

Indexes Table

Provides strong‑type indexes (StringValue, NumValue, DateValue) copied from the Data table after type conversion, enabling efficient queries.

UniqueIndexes Table

Enforces uniqueness constraints using native database unique indexes (UniqueStringValue, UniqueNumValue, UniqueDateValue).

Relationships Table

Accelerates object relationship queries. Columns include OrgID, ObjID (child object), GUID (child record), RelationID (relationship field), TargetObjInstanceID (parent record). Composite indexes (OrgID+GUID) and (OrgID+ObjID+RelationID+TargetObjInstanceID) support child‑to‑parent and parent‑to‑child lookups.

SOQL and Relationships

SOQL (Salesforce Object Query Language) is a read‑only, SQL‑like language for querying SObjects. Differences from SQL include no SELECT *, no views, and reliance on the metadata layer for object‑relational mapping.

Basic SOQL Example

select id,productno__c,name,productprice__c,productstatus__c from product__c

Standard fields have no "__c" suffix; custom fields and objects use "__c" to differentiate them.

Child‑to‑Parent Query

select id,name,orderno__c,customer__c,customer__r.customerno__c,customer__r.name,orderstatus__c,ordertime__c from order__c order by orderno__c

"customer__r" denotes the parent relationship, allowing access to parent fields.

Parent‑to‑Child Query

select id,orderno__c,customer__r.name,ordertime__c,orderstatus__c,(select id,product__r.productno__c,product__r.name,product__r.productprice__c from orderitem__r) from order__c order by orderno__c

The sub‑query inside parentheses fetches child OrderItem records; "orderitem__r" corresponds to the ChildRelationshipName defined in the Fields table.

Scaling to Massive Multi‑Tenant Data Volumes

Salesforce partitions data by OrgID using native database partitioning. Queries are routed only to the relevant partition, dramatically improving performance and scalability.

No‑DDL Schema Evolution

Schema changes are performed by updating metadata records rather than executing DDL on physical tables. When a field’s type changes, the platform creates a new flexible column, copies existing data, updates the Fields record, and switches the FieldNum to the new column—all without downtime.

Implications for Developers

Developers work with only two versions: the current and the next. No legacy versions need maintenance. Feature flags enable gradual rollout. Bug fixes are applied uniformly across all tenants. The platform avoids any physical DDL during normal operation, ensuring high availability.

Author bio: Cheng Yan, former senior supply‑chain planning engineer at Alibaba Digital Supply Chain, now developing commercial products in Alibaba Data Middle Platform.

Related Reading

What Is Cloud‑Native Middleware? Impact on Programming (15‑page PPT)

System Architecture Design: Horizontal vs. Vertical Scaling

iQIYI Knowledge Web Front‑End Componentization Practice

About 21CTO: 21CTO.com is China’s leading technical social and learning platform for CTOs, architects, senior engineers, and product managers, offering education, recruitment, and enterprise services.