"In-memory database" and "disk-based database" sound like opposites, but every database uses both RAM and disk. The real difference is which one is the source of truth and what the other one is for. That choice explains why Redis is so fast, why PostgreSQL survives a reboot without losing anything, and why log-structured stores like Cassandra are so good at writes.
RAM vs disk#
On disk (persistent): data lives on an SSD or HDD and survives power loss, crashes and restarts. When you insert a row into PostgreSQL, it eventually lands in files under its data directory, and those files are still there after a reboot.
In memory (volatile): data lives in RAM and disappears on power loss, crash or restart. When you SET a key in Redis, it is stored in RAM, and unless persistence is configured, a reboot loses it.
The speed gap#
Rough orders of magnitude for a single random access:
| Medium | Typical access time | Analogy |
|---|---|---|
| RAM | ~100 nanoseconds | The book on the desk in front of you |
| SSD | ~100 microseconds (about 1,000× slower than RAM) | Walking to a bookshelf across the room |
| HDD | ~10 milliseconds (about 100,000× slower than RAM) | Driving to the library across town. The platter must spin and the arm must move. |
How three kinds of database use RAM and disk#
Each kind of database splits the work between RAM and disk differently.
Disk-based (PostgreSQL, MySQL): disk is the truth, RAM is a cache#
| Operation | What happens |
|---|---|
| Write | Append to the WAL on disk (durability), then update the page in the buffer pool (RAM). The page is flushed to the data files later. |
| Read | Buffer pool hit: return from RAM. Miss: read the page from disk, keep it in the buffer pool, return it. |
| RAM full | Evict old pages. The data is still safe on disk. |
| Restart | The buffer pool is empty, but all data is on disk. The cache warms up again. |
Indexes and tables are stored as B-trees on disk (see Read Heavy Indexing).
In-memory (Redis, Memcached): RAM is the truth, disk is an optional backup#
| Operation | What happens |
|---|---|
| Write | Update RAM, done. Optionally, also take a periodic snapshot to disk (Redis RDB) or append every write to a log on disk (Redis AOF). |
| Read | Always from RAM. It never touches disk. |
| Restart | RAM is empty. Without RDB/AOF the data is gone. With them, reload from disk, possibly losing the last moments of writes. |
Data lives in in-memory structures such as hash tables (see Hash Indexes).
LSM-based (Cassandra, RocksDB, ScyllaDB): RAM takes writes first, disk holds everything#
| Operation | What happens |
|---|---|
| Write | Append to the WAL on disk (sequential), insert into the memtable (RAM), then acknowledge. Later, the memtable is flushed to disk as an immutable sorted file (SSTable). |
| Read | Check the memtable (RAM), then SSTables on disk, newest first. |
| Restart | Replay the WAL to rebuild the memtable. |
Here RAM isn't just a cache. It is the first place every write lands, and the disk work happens later in the background. See Write Heavy Indexing.
Side by side#
| Source of truth | RAM is used for | Disk is used for | After a crash | |
|---|---|---|---|---|
| Disk-based (PostgreSQL, MySQL) | Disk | Buffer pool (cache) | Data files + WAL | Safe. The cache rebuilds. |
| In-memory (Redis, Memcached) | RAM | All the data | Optional snapshots or log | Lost unless persistence is on |
| LSM-based (Cassandra, RocksDB) | Disk (SSTables) | Memtable, the write target | SSTables + WAL | Safe. The WAL is replayed. |
Some analogies help:
- A disk-based database is a filing cabinet with a desk for current work.
- An in-memory database keeps everything on the desk, perhaps photocopied into the cabinet now and then.
- An LSM database jots notes on a notepad and periodically files them in the cabinet.
Why LSM stores write faster and B-tree stores read faster#
The two designs spend their disk I/O in different places.
Writes#
| Engine | What a write does |
|---|---|
| B-tree (PostgreSQL) | Appends to the WAL, then updates the right page of the B-tree. Finding and rewriting that page means random I/O. |
| LSM (Cassandra) | Appends to the WAL (sequential) and inserts into the memtable (RAM), then acknowledges. Disk writes happen later, in large sequential batches. |
Reads#
A B-tree read walks 3–4 levels to the exact row, and it's done.
An LSM read may have to look in several places:
- Check the memtable: maybe not there.
- Check SSTable 1: maybe not there.
- Check SSTable 2: found.
Bloom filters skip most files, but there is still more work per read.
Trade-offs and when to use each#
Pick the design whose strengths match your workload.
| Choose | When |
|---|---|
| Disk-based | You need durability, transactions and flexible queries over data larger than RAM: the usual primary database. |
| In-memory | You need sub-millisecond reads and writes, the data fits in RAM, and losing it (or a few seconds of it) is acceptable: caches, sessions, rate-limit counters, leaderboards. |
| LSM-based | Writes dominate (events, logs, time series, messaging) and you can accept somewhat slower reads. |
Memory is far more expensive per GB than disk, so in-memory stores usually hold a hot subset of data, with a disk-based database behind them as the source of truth.
Key takeaways#
- Every database uses RAM and disk. The question is which one is the source of truth.
- Disk-based databases keep data on disk and use RAM as a cache, so restarts lose nothing.
- In-memory stores keep data in RAM for speed and use disk only as an optional backup.
- LSM stores write to RAM plus a sequential WAL first, which makes writes fast and reads a little slower.
- RAM is about 1,000× faster than SSD and 100,000× faster than HDD for random access, but much more expensive.