An in-memory database is a database management system that keeps its primary copy of data in main memory (RAM) and uses disk, if at all, only for durability and recovery. Among database models it is defined by where data lives rather than by its data model, so an in-memory system can be a key-value store, a relational engine, a columnar analytics engine or a document store.
Removing disk access from the read and write path lets operations complete in microseconds rather than milliseconds. The cost is that memory is more expensive and volatile, so every in-memory database must decide how much it pays in speed to avoid losing data on a crash or power failure.
How an in-memory database is designed
A disk-based engine organizes data in fixed-size pages and relies on a buffer pool to cache hot pages; its structures, such as B-trees, are tuned to minimize disk reads. An in-memory database drops the buffer pool and page abstraction and uses memory-native structures like hash tables, skip lists, T-trees or adaptive radix trees that follow pointers directly.
Because there is no disk wait, the bottlenecks shift to CPU caches, memory bandwidth and locking. Engines therefore use techniques such as lock-free or latch-free indexes, multiversion concurrency control and, in some systems, a single-threaded execution model per partition that avoids locks entirely by running one operation at a time on each core.
Durability is added by writing to disk outside the critical path. The table below shows the main options and what each one costs.
| Mechanism | How it works | Possible data loss | Performance cost |
|---|---|---|---|
| None | Data lives only in RAM | Everything on restart | None |
| Periodic snapshots | Full image written at intervals | Changes since the last snapshot | Low, but forks or pauses can occur |
| Append-only log, batched sync | Every write logged, flushed about once per second | Roughly one second of writes | Moderate |
| Append-only log, sync per write | Each commit flushed to disk | None after commit | High, bounded by disk latency |
| Synchronous replication | Commit confirmed by another node | None while a replica survives | Network round trip per commit |
Main types of in-memory databases
In-memory systems span several data models and purposes. Knowing the category matters more than the label, because it determines query capabilities and consistency guarantees.
| Category | Data model | Typical use | Representative systems |
|---|---|---|---|
| In-memory key-value store | Keys mapped to values and structures | Caching, sessions, counters, queues | Redis, Valkey, Memcached |
| In-memory OLTP engine | Relational with SQL | High-rate transactions | VoltDB, SQL Server In-Memory OLTP |
| In-memory columnar analytics | Columns compressed in RAM | Real-time reporting | SAP HANA, Oracle Database In-Memory |
| In-memory data grid | Distributed objects or tables | Shared state across application servers | Apache Ignite, Hazelcast |
| Embedded in-memory mode | Library inside the application | Tests and temporary processing | SQLite in-memory, H2 |
Some disk-based systems also offer hybrid options: a relational database may keep selected hot tables memory-optimized while the rest stay on disk, which brings speed to critical paths without moving the entire dataset into RAM.
In-memory compared with disk-based databases and caches
A disk-based database with a large buffer pool can also serve most reads from memory, so the real distinction is how the engine is built and where the authoritative copy lives. An in-memory database also differs from a plain cache, which holds a disposable copy of data owned by another system.
| Aspect | In-memory database | Disk-based database | Cache |
|---|---|---|---|
| Authoritative copy | RAM, persisted by logs | Disk | Another system |
| Typical latency | Microseconds | Sub-millisecond to milliseconds | Microseconds |
| Dataset size limit | Total cluster memory | Disk capacity | Memory, with eviction |
| Cost per GB | High | Low | High |
| Behavior when full | Writes rejected or eviction by policy | Grows on disk | Evicts entries freely |
| Recovery after restart | Reload from snapshot and log | Immediate, data on disk | Starts empty or warms up |
The same product can play both roles. Redis used with persistence disabled and an eviction policy is a cache; Redis with an append-only log, replication and no eviction is being used as a primary in-memory database, with very different operational requirements.
When to choose an in-memory database
An in-memory database is justified when latency or throughput requirements exceed what a disk-based engine can deliver at reasonable cost, and when the working dataset fits in memory with room to grow. Common cases include session stores, leaderboards, rate limiters, real-time bidding, fraud scoring and live dashboards.
- Size memory for peak data plus overhead: indexes, fragmentation, replication buffers and snapshot copies can add substantial extra memory.
- Match durability to the data: session data may tolerate a second of loss, while payments may not.
- Plan for restarts: reloading tens of gigabytes from snapshots and logs can take minutes, so replicas should take over first.
- Shard early when growth is expected, because a single node is limited by its RAM.
Limitations and misconceptions
The most common misconception is that in-memory means data is lost on restart. Most production systems persist data and recover it; what differs is the window of possible loss and the time recovery takes. Teams must read the actual configuration rather than assume either extreme.
Other limitations are economic and operational. RAM costs far more per gigabyte than SSD storage, so storing cold or archival data in memory wastes money. Snapshotting a large dataset can briefly double memory use or pause the process, and running out of memory turns into rejected writes or crashes rather than gradual slowdown. For datasets that are mostly cold, a disk-based engine with a well-sized buffer pool is usually the better choice.
The short version
An in-memory database keeps all its data in the computer’s working memory instead of on a disk. Reading from memory is like taking a paper from your desk. Reading from disk is like walking to a filing cabinet in another room.
This makes it extremely fast. But memory is expensive and forgets everything when the power goes off. So these databases also write notes to disk to rebuild their data after a restart.
Where it makes a difference
An online game with around 200,000 concurrent players must update scores and show live leaderboards after every match. The relational database storing player accounts could not handle tens of thousands of score updates per second while also answering ranking queries quickly.
The team moves leaderboards into an in-memory key-value store that uses sorted sets, with an append-only log flushed once per second and a replica in another availability zone. Rank lookups return in well under a millisecond, and the main database handles only account data and purchases. In the rare case of a node failure, players lose at most about a second of score updates, which the game accepts.