Design and Practices of Multi‑Tenant Database Management in the QiaoFang SaaS System

1. Introduction

The QiaoFang SaaS system is a leading one‑stop solution for real‑estate brokerage, supporting a wide range of operations such as tenant follow‑up, client viewings, property inspections, order management, marketing, performance queries, scheduling statistics, and financial settlement. It serves over 10,000 customers in more than 300 cities, handling billions of daily visits and managing terabytes of core data across hundreds of services and thousands of instances.

Given the massive database resources and frequent schema upgrades, systematic governance is required to ensure data security and system stability.

2. Database Architecture Patterns

The SaaS model requires tenant data isolation. Three common patterns are compared:

Architecture

Isolation Method

Granularity

Advantages

Disadvantages

Multi‑instance Multi‑tenant

Separate application and database instances per tenant

Coarse

Strong isolation, simple implementation, easy migration

High cost, low resource utilization, complex maintenance and upgrades

Single‑instance Multi‑tenant (shared DB, separate tables)

Shared database, independent tables

Medium

Good isolation, higher resource utilization

Complex data management, upgrade difficulty

Single‑instance Multi‑tenant (shared DB, shared tables)

Shared database and tables

Fine

High utilization, simple management

Poor isolation, potential slow queries with large data volumes

QiaoFang initially adopted the multi‑instance multi‑tenant pattern, later extending to a “one‑company‑multiple‑databases” model during migration to a private cloud.

3. Tenant Database Management

3.1 Database Operations

A custom Data Management System (DMS) centralizes all operations on company and common databases. It enforces approval workflows, hides internal identifiers, and provides capabilities such as permission management, DDL/DML execution, data masking, automatic backup of modified tables, export, and configuration management.

General Capabilities

Company‑Specific Capabilities

Permission & approval management

DDL/DML on designated databases

Sensitive field masking

Automatic backup of modified tables

Data export

Managed database configuration

Table structure inspection

Query business databases by company

Operate on one or multiple company databases

Operate on all databases within a partition

Concurrent execution across many companies

Batch export of execution results

Partition‑level database switching

3.2 Database Cleanup

Cleanup consists of backup‑table cleanup and expired‑company‑database cleanup.

Backup‑table cleanup: Scan tables older than the retention period, rename them with a “_x” suffix via the CDB platform API, then delete them.

Expired‑company cleanup: Manual confirmation, logical deletion (soft delete), optional renaming, and final hard deletion after backup.

Both processes are illustrated in the accompanying flow diagrams.

3.3 Database Monitoring

With tens of thousands of companies and hundreds of clusters, a dedicated monitoring system built on the CDB platform provides a global view, including cluster load dashboards and functional UI screenshots.

4. Multi‑Partition Service Design

The SaaS platform separates environments into BETA, gray, and full‑scale partitions, each with independent service groups and domains. Global routing directs requests to the appropriate partition based on the company’s assignment.

4.1 Partition Usage

BETA Partition: Pre‑production validation of new versions and schema changes.

Gray Partition: Limited set of small‑scale customers for early feedback before full rollout.

Full Partition: Production environment for the majority of customers.

5. Open‑Database System Design

When a new tenant signs a contract, the system creates a dedicated database using a templated company model. Templates are pre‑configured for different company types and scales, enabling rapid provisioning.

5.1 Company Template Customization

Operators select a template that matches the tenant’s characteristics; the system clones the template’s database to create the new tenant’s instance.

5.2 Database Selection Strategy

An automated pool of candidate clusters evaluates remaining port quotas and selects the least‑utilized cluster among the lowest‑N candidates, ensuring balanced resource distribution and avoiding the pitfalls of always using the single most idle cluster.

6. Conclusion and Outlook

The article outlines QiaoFang SaaS’s practical innovations in tenant data governance, multi‑tenant database architecture, automated cleanup, and monitoring. Future work will continue to refine these mechanisms to support the evolving needs of the real‑estate brokerage market and promote digital transformation across the industry.