In-Memory Databases

Here's a number that changes how you think about databases: reading 1 MB from RAM takes about 3 microseconds. Reading 1 MB from an SSD takes about 200 microseconds. Reading 1 MB from a spinning hard drive takes about 2,000 microseconds.

RAM is 65x faster than SSD and 650x faster than HDD.

For most applications, this doesn't matter. Your web app fetches a user profile in 5ms from PostgreSQL and nobody notices. But for some workloads, real-time bidding (you have 100ms to decide which ad to show), high-frequency trading (microseconds determine profit), session management (millions of concurrent users hitting your auth layer), disk-based databases are the bottleneck.

In-memory databases eliminate the disk bottleneck entirely. All data lives in RAM. Every read is a memory access. Every write goes to RAM first, optionally flushed to disk later for durability.

Redis, the most famous in-memory database, handles 100,000+ operations per second on a single node. Memcached does even more for pure key-value lookups. SAP HANA runs entire ERP systems in memory. VoltDB processes financial transactions with microsecond latency.

But here's the catch everyone glosses over: RAM is volatile. Power goes out, your data is gone. Every in-memory database has to grapple with this fundamental tension between speed and durability.

The core idea is simple: keep the entire dataset in RAM and use optimized in-memory data structures instead of disk-oriented ones.

Traditional disk-based databases use B-trees because B-trees minimize the number of disk seeks. In-memory databases don't care about disk seeks, they use hash tables, skip lists, radix trees, and other structures that are optimal for RAM access patterns.

Redis internals, a quick look:

• Strings: Simple dynamic strings (SDS)
• Lists: Quicklists (linked list of ziplist chunks)
• Sets: Hash tables or intsets (for small integer sets)
• Sorted Sets: Skip lists + hash tables
• Hashes: Ziplists (small) or hash tables (large)

None of these structures are designed for disk. They're designed for pointer traversal in memory, which is exactly what makes them fast.

The durability problem, three approaches:

1. No persistence (Memcached). Pure cache. If the process dies, data is lost. Acceptable when the data can be regenerated from a backing database.

2. Periodic snapshots (Redis RDB). Every N minutes, fork the process and dump the entire dataset to disk. You lose at most N minutes of data on a crash. The snapshot happens in a child process, so the main process keeps serving requests.

3. Append-only log (Redis AOF). Log every write operation to disk. On restart, replay the log to reconstruct the dataset. You can configure how often the log is fsynced, every second (lose at most 1 second), every write (slowest but safest), or never (OS decides).

4. Hybrid persistence. Redis uses both RDB and AOF together. Snapshots for fast recovery, AOF for minimal data loss.