An in-memory database keeps its working data set in main memory (RAM) instead of reading and writing primarily from disk. Because RAM access is orders of magnitude faster than disk or even SSD, this design targets very low latency and high throughput for reads and writes. Redis is a well-known example, alongside Memcached and SAP HANA.
Redis states the motivation directly: “to achieve top performance, Redis works with an in-memory dataset.” Holding the live data in memory is what lets such systems answer queries in microseconds rather than milliseconds, which matters for caches, session stores, leaderboards, and other hot paths.
The trade-off is durability and cost. RAM is more expensive per gigabyte than disk and is volatile, so a crash or restart loses anything not written elsewhere. In-memory systems address this by persisting asynchronously: Redis describes two options, “periodically dumping the dataset to disk” with point-in-time snapshots, or “appending each command to a disk-based log.” Both happen alongside the in-memory operations rather than on the critical read path.
This is why an in-memory database is often paired with a slower, larger system of record. The fast store handles the working set and the latest activity, while a disk-based database or the append-only log provides the durable backing copy. The design buys speed by accepting tighter limits on data size and a controlled relaxation of how immediately data is made durable.