How RedHub Revolutionizes Database Access for Billion‑User Scale

In a billion‑user business scenario, the database is the core data carrier, and its stability, performance, and maintainability directly determine system robustness and iteration efficiency.

Rapid business growth caused the database access methods to become fragmented—direct connections, multiple SDK versions, custom middleware—leading to poor protocol compatibility, slow fault recovery, and high operational costs.

RedHub: A Unified, High‑Performance Database Proxy

To solve this systemic problem, Xiaohongshu's database team developed RedHub, a next‑generation database proxy that provides a unified, high‑performance, and easy‑to‑operate access layer designed to support the next ten years of architectural evolution.

Why a New Architecture?

The legacy proxy (MyHub) suffered from weak SQL parsing, lack of complex query support, and a rudimentary execution engine, causing high availability risks, soaring operational costs, and limited scalability.

Business demands required a "unified entry" that is functional, stable, and evolvable.

Technical Path Selection

Two main approaches exist for data‑access layers: SDK‑heavy (embedding logic in services) and SDK‑light with a heavy proxy. Xiaohongshu chose the "light SDK + heavy Proxy" model and decided to build RedHub by deeply re‑engineering the open‑source PolarDB‑X compute layer, gaining a proven distributed SQL engine while retaining autonomy.

Key Design Goals

Stability : Short core paths, minimal dependencies, fast self‑healing.

Functionality : Full SQL compatibility, distributed optimizer, auto‑increment support.

Observability : Unified processlist, fine‑grained rate limiting, transparent governance.

Major Improvements

Independent Health Checks : Short‑connection probes detect disk failures within seconds.

Leader Arbitration : Only the leader node performs health checks, avoiding cascade failures.

Connection Control : Configurable min/max pool sizes prevent DB overload.

SQL Compatibility : Rebuilt parser (based on Druid) supports sub‑queries, JOIN across shards, and aggregates; SQLancer testing raised pass rate from 19% to 92% for sharding scenarios.

Auto‑Increment : AUTO_INCREMENT BY SEQUENCE with multiple sequence types (segment, Snowflake, time‑based).

Fine‑Grained Rate Limiting : Limits by database, table, user, IP, SQL type, and even specific parameter values.

Operational Experience : Logical processlist view enables one‑click KILL of related physical queries; physical processlist provides deeper diagnostics.

Migration Strategy

RedHub migration follows three stages with minimal business impact:

Traffic Replay : Record SQL templates on MyHub pods, replay on a RedHub cluster to verify compatibility.

Gray‑Scale Cut‑over : Deploy RedHub pods alongside MyHub, gradually shift traffic.

Full Upgrade : Decommission MyHub pods once RedHub handles all traffic.

Real‑World Validation

Disk‑full replica automatically isolated within 15 seconds, keeping queries uninterrupted.

Hotspot SQL throttling configured in two minutes, instantly reducing load and preventing service snow‑balling.

Future Directions

Unified access governance with fine‑grained permissions, field‑level masking, and row‑level security.

Enhanced data security via dynamic masking, SQL audit, and operation‑level circuit breaking.

Intelligent ops: performance profiling, automatic index recommendation, capacity prediction.

HTAP exploration: automatic hot‑cold data separation, column‑store routing for analytical workloads.

RedHub aims to become Xiaohongshu’s central database control plane, integrating traffic governance, security, observability, and intelligent optimization into a single, cloud‑native solution.