Comparison between ApsaraDB for Redis and self-managed Redis

Compared with self-managed Redis databases deployed on your servers, ApsaraDB for Redis instances have multiple advantages, such as high data security, easy operations and maintenance (O&M), and optimized kernel.

Item	ApsaraDB for Redis	Self-managed Redis
Security protection	Pre-operational protection: Uses virtual private clouds (VPCs) to isolate the network. Uses whitelists for access control. Supports custom accounts and permissions.	Pre-operational protection: Requires a self-defined network security system. It is difficult to build such a system and causes high costs. Has data leak risks due to security vulnerabilities in the default access configuration of open source Redis. Does not have an account authentication system.
	Operational protection: implements SSL encryption.	Operational protection: requires a third-party tool to implement SSL encryption.
	Post-operational auditing: supports audit logs.	Post-operational auditing: does not support the auditing feature.
Backup and restoration	Performance-enhanced instances of ApsaraDB for Redis Enhanced Edition (Tair) support the flashback feature. This feature allows you to restore data to a specified point in time. For more information, see Data flashback.	Only full data restoration is supported.
Operations and maintenance (O&M)	Supports more than ten groups of metrics and a minimum monitoring frequency of 5 seconds. For more information, see Metrics. Supports alert settings. Allows you to create instances of different architectures based on your business requirements and change specifications. Supports big key analytics based on snapshots. This ensures high accuracy and prevents performance loss. For more information, see Use the cache analytics feature to find big keys.	Requires a more sophisticated third-party monitoring tool to monitor services. Stops services when you change the specifications or architecture. The operation to change the specifications or architecture is complex. Supports big key analytics based on sampling, which is inaccurate.
Deployment and scaling	Instantly activated and supports auto scaling.	Requires a long period of time to complete hardware procurement, hosting of data centers, and machine deployment. You must manage node relationships when you add nodes.
High availability (HA)	Single-zone high availability. Zone-disaster recovery. Uses an independent and central module to ensure high availability. This module ensures stable and efficient decision-making, and helps prevent split-brain issues.	Allows you to deploy a high-availability architecture in Sentinel mode in a data center. Allows you to deploy a zone-disaster recovery architecture in Sentinel mode. Uses the Sentinel mode to ensure high availability. The cost is high and the decision-making efficiency is low during peak hours. Split-brain issues may occur, which can affect your services.
Kernel optimization	Provides performance-enhanced instances based on multi-threading. The performance of a performance-enhanced instance is three times the performance of a standard instance with the same specifications. Provides storage-optimized and persistent memory-optimized instances to support large-capacity storage and command-level persistence.	Instances of Redis 6.0 or later support multiple I/O threads to enhance performance. The performance of an instance can be increased by up to twice the original performance. However, the CPU utilization is high. Supports systems such as SSDB or Pika as the persistent storage. However, these systems are not well compatible with the Redis protocol. They can manage hot and cold data only at the key level. Transferring big keys between the memory and disks is costly. These systems are difficult to manage.