When to Use MEMORY or NDB Cluster Feature Support Hash indexes Yes Index caches N/A Locking granularity Table MVCC No Replication support  (Implemented in the server, rather than in the storage engine.) Limited (See the discussion later in this section.) Storage limits RAM T-tree indexes No Transactions No Update statistics for data dictionary Yes •When to Use MEMORY or NDB Cluster •Partitioning •Performance Characteristics •Characteristics of MEMORY Tables •DDL Operations for MEMORY Tables •Indexes •User-Created and Temporary Tables •Loading Data •MEMORY Tables and Replication •Managing Memory Use •Additional Resources When to Use MEMORY or NDB Cluster Developers looking to deploy applications that use the  MEMORY  storage engine for important, highly available, or frequently updated data should consider whether NDB Cluster is a better choice. A typical use case for the  MEMORY  engine involves these characteristics: •Operations involving transient, non-critical data such as session management or caching. When the MySQL server halts or restarts, the data in  MEMORY  tables is lost. •In-memory storage for fast access and low latency. Data volume can fit entirely in memory without causing the operating system to swap out virtual memory pages. •A read-only or read-mostly data access pattern (limited updates). •Row-level locking and multiple-thread operation for low contention between clients. •Scalability even with statement mixes that include writes. NDB Cluster offers the same features as the  MEMORY  engine with higher performance levels, and provides additional features not available with  MEMORY : 3411