ApsaraDB for Redis:Comparison between ApsaraDB for Redis and self-managed Redis

• Uses virtual private clouds (VPCs) to isolate the network.
• Uses whitelists for access control. For more information, see Step 2: Configure whitelists.
• Supports custom accounts and permissions. For more information, see Create and manage database accounts.

• Requires a self-managed network security system, which is expensive and difficult to build.
• Comes with risks of data leaks due to security vulnerabilities in the default access configuration of open source Redis.
• Does not have an account authentication system.

• Supports more than ten groups of metrics and a minimum monitoring frequency of 5 seconds. For more information, see Metrics.
• Supports the configuration of alert rules. For more information, see Alert settings.
• Allows you to create instances of different architectures based on your business requirements and change specifications or architecture.
• Supports large key analysis based on snapshots. This feature has high accuracy and does not cause performance loss. For more information, see Use the offline key analysis feature.

• Requires a more complex 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 large key analysis based on sampling, which can be inaccurate.

• Supports the single-zone HA solution. For more information, see Single-zone HA solution.
• Supports the zone-disaster recovery solution. For more information, see Zone-disaster recovery solution.
• Uses an independent central module to ensure HA. This module ensures stable and efficient decision-making and helps prevent split-brain issues.

• Allows you to deploy an HA 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 HA. The Sentinel mode is costly and has a low decision-making efficiency during peak hours. Split-brain issues may occur, which can affect your services.

• Provides DRAM-based instances of the ApsaraDB for Redis Enhanced Edition (Tair) based on the multi-threading model. For more information about DRAM-based instances, see DRAM-based instances. The performance of a DRAM-based instance is three times that of a standard instance with the same specifications.
• Provides ESSD-based and persistent memory-optimized instances of the ApsaraDB for Redis Enhanced Edition (Tair) to support large-capacity storage and command-level persistence. For more information, see ESSD-based instances and Persistent memory-optimized instances.

• Instances of Redis 6.0 or later support multiple I/O threads to enhance performance. The performance may increase by up to twice the original performance, but CPU utilization also becomes high.
• Uses a storage service such as SSDB or Pika as persistent storage. However, these storage services are not fully compatible with the Redis protocol and can manage hot and cold data only at the key level. These storage services are difficult to manage, and it is expensive to transfer large keys between memory and disks in these services.

For example, if you create a 64 GB ApsaraDB for Redis instance, the available memory capacity is 64 GB.

For example, if you purchase two 64 GB Elastic Compute Service (ECS) instances to build master-replica Redis instances, the available total memory capacity is usually less than 45 GB.