Database Mesh 2.0 and Pisanix: Cloud‑Native Database Governance at iQIYI

In May this year, SphereEx officially introduced the Database Mesh 2.0 concept. Database Mesh is a dynamic, evolving notion that focuses on database traffic governance, offering capabilities such as data sharding, load balancing, observability, and audit based on protocol‑level awareness. It also addresses reliability engineering for various roles.

iQIYI strongly supports the Database Mesh vision of achieving high‑performance database expansion and solving data governance challenges in the cloud. To this end, iQIYI extended ShardingSphere‑JDBC and integrated the concrete implementation of Database Mesh—Pisanix—conducting a series of key tests and gradually evolving toward a Database Mesh architecture.

Rapid business growth and massive traffic spikes (e.g., flash‑sale events) have put pressure on databases, leading to slave lag, slow queries, and operations that cannot meet business needs. While micro‑service and cloud‑native acceleration creates new possibilities for deployment and governance, it also brings challenges such as difficult technology selection, high cost, and complex control.

With cloud‑native practices maturing, iQIYI aims to adopt a unified management approach to extend and upgrade databases in the cloud, supporting more applications and workloads.

To satisfy high requirements for performance and availability in cloud environments, iQIYI needs to migrate ShardingSphere’s distributed capabilities from on‑premises to the cloud and find a tool that can unify cloud database traffic entry and provide efficient governance.

While evaluating the Database Mesh solution Pisanix provided by the SphereEx community, iQIYI performed secondary development on ShardingSphere‑JDBC to meet needs for data sharding, load balancing, configuration storage, and security.

The overall architecture (illustrated in the accompanying diagram) shows a unified configuration center storing encrypted database connection settings via KMS, with ShardingSphere‑JDBC handling sharding and load‑balancing logic.

When a business accesses the data‑governance platform, connection configurations are encrypted and stored in the unified config center. At application startup, the enhanced ShardingSphere‑JDBC fetches the configuration, listens for changes, and supports hot‑updates.

Before the improvement, scenarios such as configuration changes, cluster scaling, version upgrades, database migration, or cloud migration required redeployment of services and complex procedures for switching, rollback, traffic gray‑release, and data verification.

After the improvement, custom ShardingSphere‑JDBC can smoothly handle new or modified sharding configurations. Modifying the config center triggers asynchronous tasks that close old connection pools and replace them with new ones, achieving seamless read/write traffic migration and greatly reducing the difficulty of moving governance capabilities to the cloud.

iQIYI’s future plan includes integrating Database Mesh with the Pisanix‑Proxy, moving governance logic from the SDK down to a sidecar.

At the traffic‑entry layer, the rise of cloud‑native micro‑services and serverless workloads demands configurable complex routing rules, multi‑protocol support, security, and observability. Previously, iQIYI managed Redis and MySQL uniformly through middleware.

SmartJedis now supports the unified configuration center, providing dynamic configuration for different environments. In non‑mesh scenarios it uses direct connections; in mesh scenarios it leverages Envoy’s RedisProxy to manage Redis protocol traffic and supports hot‑updates, avoiding the need for redeployment after Redis migration to the cloud.

For MySQL, iQIYI tested the Database Mesh practice—Pisanix. Written in Go and Rust and Kubernetes‑native, Pisanix currently supports the MySQL protocol and consists of three components: Pisa‑Controller, Pisa‑Proxy, and Pisa‑Daemon. It offers a “local‑as‑database” experience, a pluggable multi‑protocol architecture, hides the real data‑source state, and provides unified traffic control for DB operators.

Looking ahead, after Pisanix is further adopted, iQIYI will achieve standardized automatic database maintenance, support multi‑language applications, and enable cloud‑native orchestration of various database‑governance actions via custom resources such as unified DB access declarations and programmable resource limits.

01 Data Sharding – Near‑ShardingSphere‑JDBC Performance in the Cloud

Data sharding is an effective method for handling massive data storage and computation. It involves four key modules: SQL parsing, SQL rewriting, SQL routing, and result merging. To migrate ShardingSphere’s powerful sharding capabilities to the cloud, Pisanix provides governance for data sharding, allowing horizontal scaling and exposing custom metrics for intelligent, stable auto‑scaling of Pisa‑Proxy.

Based on the Pisa‑Controller control plane, iQIYI can manage data‑plane components together with Pisa‑Proxy deployed as a sidecar in the same pod as the business application, listening to MySQL protocol traffic. Pisanix offers several governance capabilities:

SQL traffic governance: parsing SQL to enable various load‑balancing strategies and rate limiting.

Access control: fine‑grained permission control based on user and data rights.

SQL firewall: blocking high‑risk SQL statements.

Observability: exposing metrics such as throughput and latency.

Thus, both Java and non‑Java workloads can achieve high‑performance sharding in the cloud under Pisanix.

02 Read‑Write Separation – Effectively Boosting Database Throughput

To meet throughput and availability requirements, many systems adopt a primary‑replica architecture, which introduces complexity. When read requests dominate, read‑write separation can break performance bottlenecks. iQIYI currently uses a one‑primary‑multiple‑replica setup, distributing queries across replicas to increase processing capacity and improve resilience against failures.

iQIYI plans to leverage Pisanix’s dynamic read‑write separation feature to manage multi‑primary‑multi‑replica clusters, providing transparent read‑write separation so applications can interact with the cluster as if it were a single database.

ShardingSphere‑JDBC refactoring is largely complete, and future work will combine Pisanix with ShardingSphere to achieve unified MySQL governance. Community efforts will continue to refine cloud solutions, offering reliable technical support for iQIYI’s business expansion.

Nevertheless, Pisanix is still a young project. Current limitations include limited expression support for database‑and‑table sharding, insufficient SQL configuration flexibility, and lacking visualization, metrics, circuit‑breaker, and tracing capabilities. Compatibility issues such as SQL audit, integration of Pisa‑Controller with Istio, and performance concerns are on the community’s roadmap.

In summary, iQIYI will build a unified data‑access specification and solution based on ShardingSphere‑JDBC and the evolving Pisanix project, making database access details completely transparent to developers, reducing usage complexity, enhancing security, and accelerating cloud migration.

For more details on Database Mesh 2.0 and Pisanix, see the linked articles and the GitHub repository.