Case Study: Replacing Legacy OLAP Database with RisingWave for Real-Time Monitoring at QianXiang Investment

1 Background Introduction

Company Background

QianXiang Investment is a technology‑driven quantitative investment firm built on artificial intelligence and machine learning, combining rigorous statistical theory with cutting‑edge computing to deliver sustainable long‑term returns. Its core team comes from Stanford, CMU, Facebook, and Google, and it now manages over CNY 100 billion.

Business Background

The firm operates an alert system that monitors trading activity, cash adequacy, and regulatory compliance, requiring low latency, high stability, and accurate computation. The system ingests real‑time business data from trading machines and outputs alerts. QianXiang built this system on RisingWave, which currently handles tens of thousands of QPS with second‑level latency.

2 Why Replace the Original Database System?

Before adopting RisingWave, QianXiang used a self‑built service to write live data into a mainstream OLAP database (referred to as “X system”) and performed periodic queries for alerts. The X system offered strong write throughput (50‑200 MB/s) and materialized views for query optimization.

However, several issues emerged:

Poor support for high‑concurrency queries; the system is designed for low‑volume, compute‑intensive requests, with a recommended QPS of 100, limiting further growth.

Insufficient distributed consistency; only eventual consistency is guaranteed, preventing strong consistency and join operations.

Lack of horizontal scalability; sharding impacts query performance and introduces data inconsistency.

Seeking a solution, QianXiang evaluated RisingWave, a high‑performance, highly available streaming database. After adoption, the company halved the number of compute nodes while tripling real‑time data processing, dramatically improving cost‑effectiveness.

3 Why Choose RisingWave?

3.1 Efficient Incremental Model

RisingWave supports PostgreSQL‑compatible SQL materialized views that update incrementally as new data arrives, maintaining internal operator state for fast updates. This design reduced end‑to‑end latency from seconds to sub‑second levels, outperforming the previous minute‑level monitoring.

3.2 Incremental Computation Saves Resources

Incremental computation processes only new or changed data, avoiding the heavy cost of full recomputation. RisingWave’s support for window functions via the OverWindow operator enables sophisticated analytics. Compared to the X system, RisingWave achieved over 95% reduction in compute resources without materialized views and at least 70% reduction with tuned materialized views.

3.3 Hybrid Architecture for Horizontal Scaling

RisingWave combines remote state (cloud storage) with local cache, offering elastic scaling while preserving high‑performance query execution, eliminating the typical trade‑off between scaling and query speed.

3.4 Strong Distributed Consistency

The platform uses a Barrier mechanism to guarantee atomic, consistent state across distributed nodes, ensuring materialized view results are strongly consistent even in a distributed environment.

3.5 Rich Sink and Source Connectors

RisingWave provides extensive connectors for various sources and sinks, supporting formats such as JSON, Avro, and Protobuf. This simplifies data integration, enables real‑time processing of large streams, and allows materialized view results to be written back to Kafka for proactive alerting.

3.6 UDF Support

Users can extend functionality with user‑defined functions (UDFs), similar to MySQL custom functions, facilitating migration of proprietary logic without altering the overall architecture.

3.7 Observability

Built‑in observability integrates with Grafana and Prometheus, offering detailed metrics and dashboards for seamless monitoring within existing infrastructure.

3.8 Technical Support

During the proof‑of‑concept phase, RisingWave provided strong technical assistance, helping developers adopt the streaming database and resolve migration challenges.

4 Solution Based on RisingWave

After selecting RisingWave as the database and compute engine, QianXiang built a real‑time monitoring architecture: trading machines publish data to Kafka; RisingWave creates materialized views on Kafka source tables to compute aggregates, compare against thresholds, and generate alerts; results can be written back to Kafka, and an alert service consumes the stream to notify operators.

The solution delivers several benefits:

Unified storage and computation: all trading data and alert results reside in RisingWave, enabling flexible SQL queries for raw, intermediate, and processed data.

Stream‑table integration: materialized views are defined via SQL, allowing rapid rule changes without code modifications and providing true real‑time data warehousing.

Data flow capability: processed results can be streamed back to Kafka, turning passive queries into active alerts and removing QPS limitations.

5 Summary and Outlook

Through deep study and practice, QianXiang has successfully deployed RisingWave in production, achieving stable operation. RisingWave offers strong reliability, scalability, efficient connectivity, excellent observability, and robust customer support, addressing previous system pain points. Future work will focus on unified stream‑batch processing, enabling real‑time handling of diverse data sources and efficient analysis of large data lakes to meet evolving market and technical demands.