This topic compares the features of ApsaraDB for Redis Enhanced Edition (Tair) and Community Edition to help you select an instance type based on your business requirements.

Key features and applicable scenarios

Edition Series Feature Scenario
ApsaraDB for Redis Enhanced Edition (Tair) Performance-enhanced instances
  • Provides high performance. Performance-enhanced instances use the multi-threading model to provide read and write performance three times that of native Redis databases or ApsaraDB for Redis Community Edition instances of the same specifications.
  • Supports multiple Redis modules that are developed by Alibaba Cloud. These modules include TairString, TairHash, TairGIS, TairBloom, TairDoc, and TairZset. These modules make ApsaraDB for Redis suitable in more scenarios, simplify development workloads in complex scenarios, and allow you to focus on business innovations.
  • Provides high compatibility. Performance-enhanced instances are fully compatible with native Redis databases. To switch from native Redis databases to ApsaraDB for Redis instances, you do not need to modify the application code.
Performance-centric business scenarios.
Persistent memory-optimized instances
  • Provides an ultra-high cost efficiency. The price of persistent memory-optimized instances is 30% lower than that of ApsaraDB for Redis Community Edition instances with the same capacity. The performance of persistent memory-optimized instances reaches 90% of that of native Redis databases.
  • Prevents data loss when power failures occur. Persistent memory-optimized instances implement data persistence for each command. The system returns success for write operations only after data is persistently stored. You can use persistent memory-optimized instances as in-memory databases instead of caches.
  • Optimizes append-only file (AOF) rewriting performance for large-sized Redis databases. Persistent memory-optimized instances reduce the latency and jitter that are caused when Redis calls forks to rewrite the AOF.
  • Delivers high compatibility. Persistent memory-optimized instances are compatible with most data structures and commands of native Redis databases.
Data cache and storage scenarios that require high performance and high data persistence, and can bear high costs.
Storage-optimized instances
  • Saves costs. Storage-optimized instances save up to 85% of costs compared with ApsaraDB for Redis Community Edition instances.
  • Stores data in disks. Storage-optimized instances store data in ESSDs with high data reliability. The capacity of a storage-optimized instance reaches hundreds of TBs.
  • Optimizes memory usage for large-sized Redis databases. Storage-optimized instances reduce the amount of reserved memory that is required for the forks of native Redis databases.
  • Delivers high compatibility. Storage-optimized instances are compatible with most data structures and commands of native Redis databases.
Data storage scenarios that require a large capacity and low costs, involve only infrequent data access, and can bear high access latency.
ApsaraDB for Redis Community Edition N/A Compatible with open source Redis databases and provides high performance. These instances apply to small-sized applications, medium-sized applications, and applications for verification. They also apply to standard Redis usage and data migration scenarios.
Note For more information about instance types, see Select ApsaraDB for Redis instances.

Feature comparison

In the following table, ✔️ indicates that this feature is supported, and ❌ indicates that this feature is not supported.

Category Item ApsaraDB for Redis Enhanced Edition (Tair) ApsaraDB for Redis Community Edition
Performance-enhanced instances Hybrid-storage instances Redis 2.8, Redis 4.0, and Redis 5.0
Basic performance Performance benchmark based on Community Edition 300% 90% to 40% ② Same
Maximum number of connections to each data node 30,000 10,000 10,000
Service capability of an individual key (QPS reference value) ① 450,000 120,000 to 60,000 ② 140,000
Specifications Disk type Local disks Local disks Local disks
Thread model Multiple I/O threads+ single worker (Real Multi-I/O) ③ Single I/O thread + multiple workers Single I/O thread + single worker
Cost per unit (based on Community Edition) 117% 30% Same
Data structure Basic data structures and supported commands Different instances support different commands. For more information, see Limits on commands supported by ApsaraDB for Redis Enhanced Edition (Tair). For more information about the commands that are supported, see Commands supported by Community Edition.
Integration with multiple Redis modules ✔️
Data persistence Master-replica replication consistency Eventual consistency Eventual consistency Eventual consistency
Persistent data consistency ④ Write Back Write Back Write Back
Persistence level Seconds-level Seconds-level Seconds-level
Security Audit log feature for databases ✔️ ✔️
SSL encryption ✔️ ✔️ ✔️
IP address whitelist ✔️ ✔️ ✔️
Performance analysis Query hotkeys in real time ✔️ ✔️
Query historical hotkeys ✔️ ✔️
Real-time big key query ✔️ ✔️ (not supported in Redis 2.8)
Offline big key analysis ✔️ ✔️
Advanced features Use data flashback to restore data by point in time ✔️
Proxy query cache ✔️
Global Distributed Cache for Redis ✔️
One-way data synchronization by using DTS ✔️ ✔️ ✔️
Two-way data synchronization by using DTS ✔️

The following sections show the description of each number label:

  • ①: The QPS (number of visits per second) reference value is measured by a command with a time complexity of O(1). A higher time complexity indicates a lower QPS reference value.
  • ②: A higher hit ratio on memory indicates that hybrid-storage instances provide higher performance. The performance is similar to that of Community Edition.
  • ③: Different from the multi-threading feature of Redis Community Edition 6.0, Real Multi-I/O of performance-enhanced instances supports multiple connections, linearly increases in throughput, and provides fully accelerated I/O threads.
  • ④: ApsaraDB for Redis uses the following methods to store data:
    • Write Through: writes the data directly to disks and returns a successful response.
    • Write Back: writes the data to the cache and returns a successful response. The data will be written to disks later.