In-memory database

An in-memory database keeps its working data set in RAM rather than reading it from disk on each query, which removes the disk I/O that dominates latency in conventional databases and is one reason many Real-time OLAP engines rely on in-memory techniques internally. Some in-memory databases are purely volatile caches, while others still persist to disk for durability but serve reads and writes from memory.

The performance gain comes from memory being orders of magnitude faster to access than even fast solid-state disks, which matters most for workloads with heavy random access or very high query rates, such as session state, real-time leaderboards, or feeding a live analytics dashboard. The trade-off is cost and capacity: RAM is far more expensive per gigabyte than disk, which limits how much data can practically be held in memory, and a purely in-memory system risks data loss on a crash unless paired with persistence or replication.

In-memory databases are commonly used as a caching layer in front of a slower primary database, or as the engine behind applications needing microsecond-to-millisecond response times that disk-based storage cannot deliver, sometimes combined with a materialized view to keep precomputed results in memory. A frequent design mistake is treating an in-memory cache as a system of record without understanding its durability guarantees, which can silently lose data never intended to be the only copy.