Highlights

Cloud-native GeminiDB is a key-value (KV) database service featuring high stability, cost-effectiveness, elasticity, and easy O&M. It is fully compatible with the Redis protocol, supports advanced functions such as PITR recoveries for game rollback and FastLoad for feature data import, and it allows you to set the field expiration time for hash keys and blacklist for high-risk keys.

GeminiDB is widely used in scenarios such as game friends list and player rankings, ad placement, personalized recommendations, e-commerce inventory, IoV data storage, and ERP systems. For details, see Application Scenarios.

GeminiDB has the following advantages over open-source on-premises KV databases (such as Redis and Pika databases):

**Table 1** Comparison between GeminiDB and open-source on-premises KV databases
Dimension	Item	Open-Source On-Premises KV Database	GeminiDB
Stability	Performance jitter caused by forks	Service stability is severely affected by fork issues. When RDB backups are generated, the Append Only File (AOF) is rewritten, or full data is synchronized, and a fork is called, which increases latency and causes out of memory (OOM) issues.	Service stability is improved as fork issues are addressed. There is no performance jitter during backup and synchronization.
	Long latency in big key scenarios	The single-thread architecture slows down subsequent requests. In a single-thread architecture, big key requests slow down all subsequent requests and may create flow control or OOM issues on shards.	The multi-thread architecture reduces the impact on subsequent keys. GeminiDB uses a multi-thread architecture, which improves concurrency and reduces the impact of big keys on subsequent read and write operations of other keys.
	Bandwidth limiting during peak hours	Flow control is easily triggered, affecting services. Open-source on-premises databases typically use a hybrid deployment that strictly limits the bandwidth. Flow control is easily triggered for smaller instances.	Up to 10 Gbit/s is supported, allowing GeminiDB to handle service surges. By using independent container deployment, GeminiDB can enable a load balancer to support a bandwidth of 10 Gbit/s.
	Impact of scale-out on services	Scale-out can take several minutes or sometimes even hours, greatly affecting services. Adding nodes involves data migration. Services may be affected for a few minutes or up to several hours.	Smooth scale-out is supported and has minimal impact on services. Scale-out can be completed in seconds and without interrupting services. Adding nodes does not requires any data migration. There is just a few seconds of jitter.
	HA scenarios such as node breakdowns and primary/secondary switchovers	Long switchover time: RTO > 30s	Second-level jitters, RTO < 10s
Performance	QPS	80,000 to 100,000 QPS per shard In a single-thread architecture, the QPS of a single shard does not increase after CPUs are added.	10,000 to 300,000 QPS per shard In a multi-thread architecture, the QPS can increase linearly as CPUs are added.
Performance	Latency	Low latency	Low latency In most service scenarios, the average latency is 1 ms, and the p99 latency is about 2 ms.
O&M capabilities	Audit logs of risky operations	Not supported	High-risk commands can be traced.
	Circuit breakers triggered by abnormal requests to keys	Not supported	Key blacklists and one-click circuit breakers for high-risk operations are supported, so the entire instance is not affected.
	Slow query logs	Supported	Supported. More details can be found in the logs.
	Big key diagnosis	Not supported	Online diagnosis of big keys by category is supported.
	Hot key diagnosis	Supported	Online diagnosis of hot keys is supported.
Cost	Utilization cost	The in-memory storage is expensive.	The cost of databases with the same specifications is 30% lower than open-source on-premises databases. Users can purchase additional compute resources and storage resources independently to eliminate the resource waste associated with coupled storage and compute.
	Data compression	Not supported	The compression ratio (4:1) enables databases with the same specifications to store more data.
	Scale-out	Coupled storage and compute increases costs exponentially.	Decoupled storage and compute supports independent scaling of compute and storage resources.
Availability	/	If any pair of primary and standby nodes is faulty, the entire cluster becomes unavailable.	GeminiDB provides superlative fault tolerance (N-1 reliability).
Data reliability	/	Weak Thousands or tens of thousands of records will be lost if nodes are restarted and the network fluctuates. Weak data consistency may cause dirty reads.	High reliability GeminiDB provides three-copy storage, so it can serve as the primary database to replace the traditional DB+Cache solution, and it also ensures strong data consistency and avoids dirty reads.
Advanced features	Autoscaling	Not supported	Supported
	Setting the expiration time for fields in hashes	Not supported	Supported. Service design is less complex and concurrency is increased.
	Fast data loading	Not supported	FastLoad allows feature data to be imported faster, reducing the impact on online services.
	Point-In-Time Recovery (PITR)	Not supported	Supported PITR rollbacks and quick data restoration to the original instance are supported, making GeminiDB a great fit for gaming applications.
	DR and dual-active instances	Not supported	Intra-region and cross-region DR and dual-active instances can be created.