In-Memory Databases: Concepts, Evolution, Applications, and Selection Guidance

In‑memory databases, also known as main‑memory databases, store data primarily in RAM, offering microsecond‑level read/write latency and high throughput compared with traditional disk‑based systems, making them ideal for high‑concurrency scenarios such as e‑commerce, live streaming, and telecom.

Rapid advances in DRAM capacity and price reductions, together with the emergence of non‑volatile memory (NVM) technologies, have expanded the feasibility of storing large data sets entirely in memory.

The paper reviews the evolution of memory technology, from early 64 KB chips to modern DDR3/DDR4 modules, highlighting the dramatic cost decline and capacity growth that enable widespread adoption of in‑memory databases.

It also examines the performance gap between volatile DRAM and slower NAND‑SSD storage, introducing persistent memory (PM/SCM) as a bridge that offers load/store access with data durability, albeit with trade‑offs in speed versus capacity and cost.

Four development stages of in‑memory databases are identified: prototype, theoretical maturity, market growth, and rapid expansion, illustrated with a timeline of hardware and software milestones.

The advantages include ultra‑high read/write performance (single‑digit microsecond latency, tens of thousands of QPS per node), while challenges focus on data volatility, requiring persistence strategies that may impact performance.

In‑memory databases are categorized into key‑value stores (e.g., Redis, Memcached, Aerospike), relational in‑memory databases (e.g., Oracle TimesTen, SAP HANA, MemSQL, SQLite), and other specialized types such as graph in‑memory databases.

Market analysis based on DB‑Engines rankings shows Redis and Memcached dominate the key‑value segment, while SAP HANA leads the relational segment; most products are commercial with varying levels of ACID support.

Selection guidance emphasizes aligning business requirements (throughput, latency, consistency, SQL compatibility) with technical factors (performance, consistency, SQL support) and non‑technical factors (ecosystem maturity, architectural fit, team expertise).

Overall, the paper advises a systematic evaluation of workload characteristics, data volume, and operational constraints to choose the appropriate in‑memory database solution.