Why Pika Is the Next‑Gen Large‑Scale Redis Alternative for Persistent Storage

Pika is a large‑capacity Redis‑compatible storage system jointly developed by 360’s Web Platform DBA and infrastructure teams, aiming to solve Redis limitations in massive‑data scenarios through persistent storage.

Pika 2.2 Improvements and Bug Fixes

Updated RocksDB to 5.0.1 and modularized it for future dynamic upgrades.

Added GEO and HyperLogLog interfaces.

Optimized the underlying network framework to prevent file‑descriptor overflow under slow‑request and many‑short‑connection loads.

Improved write performance by enabling parallel writes at the engine layer, boosting SET throughput by about 30%.

Enhanced the performance of the RANGE interface.

Meta information left by expired multi‑data structures can now be reclaimed with the compact command.

Fixed a bug that could cause SCAN to block.

Fixed an issue where RANGE might fail to read existing keys.

Resolved a rare deadlock when BGSAVE and INFO run concurrently.

Virtual DB numbers now have an upper limit of 16 (db0‑db15), avoiding tool‑related hangs.

Full support for RocksDB multi‑threaded compaction, increasing compaction speed.

Added new configuration parameters: max-background-flushes , max-background-compactions , max‑bytes‑for‑level‑multiplier (see wiki for details).

If You Are Unfamiliar with Pika, See the Introduction Below

Pika fully complies with the Redis protocol, allowing direct use of existing Redis clients without code changes. It supports over 80% of Redis commands, provides automatic persistence to disk, and offers multi‑threaded execution with optimized thread allocation, resulting in higher survivability under extreme workloads.

Its compression reduces memory usage dramatically; real‑world tests show a 3‑8× compression ratio (e.g., 80 GB of Redis data becomes 10‑30 GB on disk). Multiple compression algorithms are available.

Pika inherits Redis’s convenient operational design while adding improvements such as one‑click master‑slave creation, support for Redis cluster mode, instant data loading after restart, binary‑log‑based replication to avoid long‑running sync after failures, and non‑blocking snapshot hot‑backup with incremental backup tools.

It also provides multi‑user support with command blacklists for risk mitigation, and its status output closely mirrors Redis, enabling reuse of existing monitoring setups.

Pika is compatible with Codis and offers migration tools for Redis→Pika, SSDB→Pika, and Pika→Redis.

Other “features”:

Pika has three part‑time product managers who are also DBAs, handling feature improvements, bug tracking, and testing.

The development team is among the most knowledgeable about RocksDB in China.

Every new Pika version passes nearly 1,500 test cases internally before public release.

The internal and open‑source versions are identical.

Pika’s Position as a Complement to Redis Scenarios

High server cost when using Redis.

Massive data volumes exceeding single‑machine memory limits, difficult to shard.

Frequent high‑complexity requests causing intermittent Redis blocking.

Need for true persistence beyond AOF.

Long data reload times after disasters.

Read‑write separation without affecting replicas after failover.

Pika User Status

360 Internal

Instances: over 500+ Requests handled: 400 billion per day Total data: 4 TB (equivalent to roughly 20 TB of Redis memory)

Community Users

Refer to the GitHub repository or join the QQ group for more information.