IM Engineer Study Notes
← Back to list
Database
#인메모리DB#Redis#SAP HANA#지속성#HTAP
Last updated · 2026-10-18

In-Memory Database (IMDB)

1. Overview

A. Definition

An in-memory database (In-Memory Database, IMDB — also MMDB, Main-Memory Database) is a database management system designed to keep the primary store of the data in main memory (RAM) rather than on disk and to perform query processing, computation, and buffering entirely in memory. Unlike a disk-based DBMS that "pulls data residing on disk into a buffer pool and processes it there," an IMDB redesigns its data structures, query processor, and recovery techniques as a whole under the assumption that the data always resides in memory, so it is fundamentally different from "a disk DB with a large buffer."

The key point here is that the disk's role is demoted from a "working store" to a "backup and log store for durability." That is, disk does not disappear in an IMDB. Rather, disk access is removed from the normal path (hot path) of reads and writes, and disk is used only as a secondary medium that keeps logs and snapshots for crash recovery.

B. Background and Necessity

The performance model of a traditional disk-based DBMS was built on the premise that "disk I/O is the most expensive resource." The B-Tree index ([[btree-bplus-index]]), buffer pool, page-based storage, and write-ahead logging ([[write-ahead-logging]]) are all devices to reduce or sequentialize slow disk access. But this premise was shaken by hardware change. Since the 2010s, a single server has come to carry hundreds of GB to several TB of DRAM, so a large share of operational datasets (the OLTP working set) can now fit entirely in memory. If the data is in memory, a structure optimized on the premise of disk I/O becomes, instead, unnecessary overhead.

In fact, a study measuring the "memory hit" situation where data is already cached in the buffer pool of a disk DB (for example, the Shore analysis from the VoltDB camp) showed that most of a transaction's execution time is spent on auxiliary work premised on disk — buffer-pool management, latches, logging, locks — while the actual real computation accounts for only around 10%. In other words, the "layers stacked up to hide slow disk" become, in a world where disk is not the bottleneck, pure cost.

Necessity also grew from business demand. Workloads demanding hundreds of thousands to millions of TPS and sub-millisecond latency — securities matching, real-time ad bidding (RTB), game sessions, telecom charging (OCS), recommendation feature serving — increased, and at the same time the demand to "analyze operational data immediately" ([[htap]]) grew. A disk-based structure made it hard to meet these latency and throughput goals cost-effectively, and as a result a design that treats memory as the primary store rose to a mainstream option. Redis (both cache and data store), SAP HANA (enterprise HTAP), VoltDB (ultra-fast OLTP), Apache Ignite, and Oracle TimesTen are representative.

Another background that cannot be overlooked is the demand on the "tail latency." It is not enough for the average response to be fast; services that must keep even the upper 99.9th percentile (p99.9) predictably short have increased. A disk-based structure is prone to intermittent latency spikes due to buffer misses, checkpoints, background merges, and the like. An IMDB structurally suppresses this tail latency by removing disk access from the normal path, so it is especially preferred in finance and telecom domains that demand not merely "not slow" but "consistently fast (deterministic latency)." This is precisely the distinctive value of an IMDB that "a disk DB with a bigger buffer pool" cannot substitute.

C. Characteristics

The properties of an IMDB all derive from the single design decision that "memory is the primary store." Memory is fast but volatile, expensive relative to capacity, and has no reason to be accessed sequentially in blocks like a disk. Therefore, in exchange for gaining speed, an IMDB must solve three challenges by design: durability, capacity, and cost.

  • Pointer-based direct access: records are pointed to directly by memory address, so the disk-page translation and buffer-lookup steps disappear.
  • Disk I/O removed (normal path): both reads and writes finish in memory, and disk is involved only in log and snapshot writes.
  • Durability design to compensate for volatility: snapshots (checkpoints) + transaction logs restore state on restart.
  • Lightweight concurrency control: with no disk wait, lock-hold time is short, so single-thread serial execution or optimistic / [[mvcc-snapshot-concurrency-control|MVCC]] schemes are favorable.
  • Memory-friendly data structures: instead of B-Tree, T-Tree, hash, and skip list are used, and beyond row storage, columnar storage ([[columnar-storage]]) is used together.
  • Capacity and cost constraints: because of RAM price and capacity limits, a hybrid that keeps only hot data in memory rather than all data is common.

2. Overall Structure of an In-Memory Database

The structure diagram below shows the dual path by which an IMDB "finishes all processing in memory, yet guarantees durability on disk alone." A normal query completes within the memory region (the blue path), and committed changes are asynchronously persisted to disk via logs and snapshots (the dotted path).

flowchart TB
  APP["Application / Client"] --> QE["Query processor<br/>(compile·execute)"]
  QE --> CC["Concurrency control<br/>(serial·optimistic·MVCC)"]
  subgraph MEM["Main memory (RAM) — primary store"]
    DATA[("In-memory data<br/>row/column region")]
    IDX["In-memory index<br/>T-Tree·hash·skip list"]
    UNDO["Version/undo region"]
  end
  CC --> DATA
  CC --> IDX
  DATA -. "write commit log" .-> LOG["Transaction log<br/>(WAL, append-only)"]
  DATA -. "periodic checkpoint" .-> SNAP["Snapshot/checkpoint"]
  LOG -. "async flush" .-> DISK[("Disk/SSD<br/>persistent medium")]
  SNAP -. "async flush" .-> DISK
  DISK -. "restore on restart" .-> DATA
  CC -. "synchronous replication" .-> REP["Replica (HA)<br/>standby node"]

The structure has three essentials. First, because data, indexes, and version information all reside in RAM, the query processor follows pointers without being aware of disk pages. Second, durability is separated into logs and snapshots, so it does not harm normal processing performance. Third, the volatility and capacity limits of a single node's memory are compensated by replicas (HA) and disk persistence. These three axes form the skeleton of IMDB design.

3. Core Mechanisms — Durability, Concurrency, Storage Structure

A. Guaranteeing Durability — Logs and Snapshots

The biggest challenge of an IMDB is the fact that "memory disappears when the power goes off." To keep the D (durability) of ACID ([[transaction-acid]]) on top of memory, the effect of a committed transaction must be left on a non-volatile medium without fail. The standard solution is a combination of two means. One is the transaction log (WAL, append-only), which sequentially records the change set (or the command) to disk at commit time. Sequential writes are much faster than random writes, so the logging cost is relatively small. The other is the snapshot (checkpoint), which dumps the entire memory state to disk at regular intervals.

On restart (crash recovery), it loads the most recent snapshot into memory and then replays only the logs after it to restore the committed state. This adapts the "write-ahead logging + checkpoint" principle of [[write-ahead-logging|ARIES]] to a memory environment. The diagram below shows this write and recovery path in time order.

sequenceDiagram
  participant T as Transaction
  participant M as In-memory state
  participant L as Transaction log (disk)
  participant S as Snapshot (disk)
  T->>M: change data (memory)
  T->>L: append commit log (sequential write)
  L-->>T: fsync done -> commit confirmed
  Note over M,S: periodic checkpoint
  M->>S: write snapshot (async)
  Note over M,L: restart after a crash
  S->>M: load recent snapshot
  L->>M: replay logs after snapshot (redo)

There is also a choice in the "granularity" of the log. A disk DB's ARIES leaves a physical (or physiological) log — changed bytes or page images — so replay cost is predictable. VoltDB-style systems, by contrast, choose a command log, recording only "the executed transaction (stored procedure) and its inputs." The recorded volume is dramatically smaller, so logging overhead is minimized, but on recovery the transactions after the snapshot must be re-executed, so replay time can grow, and there is a constraint that transactions must be deterministic. This is the typical design choice of "reducing write cost at the expense of recovery cost," and it splits by workload characteristics.

The durability design has a trade-off. If the log is flushed to disk immediately with fsync on every commit (synchronous commit), full durability is obtained but latency rises; if logs are batched and flushed with delay (group commit / asynchronous), throughput grows but the last few milliseconds of commits can be lost on a crash. Redis's AOF everysec (flush once per second) / RDB snapshot and VoltDB's Command Logging are all choices on this spectrum. So when adopting an IMDB, one must explicitly design "how much data loss is tolerable ([[rpo-rto-disaster-recovery|RPO]])." In addition, using battery-backed memory (NVDIMM) or the persistent memory (SCM) discussed later can greatly reduce the logging cost itself.

B. Concurrency Control — Why "Serial Execution" Becomes Faster

A disk DB's concurrency control had the large purpose of "not idling the CPU by running other transactions while waiting for slow I/O." Instead of raising concurrency with finely grained locks and latches, that management cost itself was substantial. But in an IMDB, because a transaction does not wait on disk, its execution time is short — on the order of microseconds. At that point, paradoxically, a regime appears in which the cost of taking a lock > the cost of simply processing in order, quickly.

VoltDB (the H-Store lineage) takes this insight to the extreme, partitioning data and executing each partition serially on a single thread. Because there are no locks or latches at all, the overhead disappears, and transactions within a partition finish deterministically fast. SAP HANA, Oracle TimesTen, and MemSQL (SingleStore), by contrast, adopt MVCC ([[mvcc-snapshot-concurrency-control]]), where reads see a snapshot and writes create a new version to eliminate read-write conflicts. Either way, the key is that the premise "the disk wait is gone" leads to the conclusion "heavy lock management can be stripped away."

C. Memory-Friendly Data Structures and Storage Model

A disk B-Tree designs nodes large (page-sized) to match the goal of "reading many keys with one I/O." Memory has no notion of I/O, so this premise is meaningless. Instead, cache efficiency (CPU cache lines, TLB) governs performance. So an IMDB favors the T-Tree with small pointer overhead, the skip list with simple balance maintenance, and the hash index advantageous for point lookups. The storage model also splits by purpose. For OLTP-centric work, row store is advantageous; for analytics-centric work, columnar storage ([[columnar-storage]]) is advantageous, and like SAP HANA, both can be placed in one engine to realize [[htap|HTAP]].

Aspect Disk-based DBMS In-memory DBMS (IMDB)
Primary store Disk (via buffer pool) Main memory (RAM)
Access method Page -> buffer lookup -> address Pointer direct access
Primary index B+Tree (large node) T-Tree·hash·skip list
Durability Disk is itself the persistent medium Guaranteed separately by log+snapshot
Concurrency cost Heavy lock·latch management Lightened by serial·optimistic·MVCC
Bottleneck Disk I/O Memory bandwidth·capacity·CPU cache
Cost profile Cheap per GB Expensive per GB (RAM)

D. Scalability — Distributed In-Memory and Partitioning

To handle datasets exceeding a single server's memory capacity (hundreds of GB to several TB), horizontal scale-out is needed. Here an IMDB applies partitioning (sharding) ([[db-sharding]]) that splits data across multiple nodes, distributing data by key range or hash and having each node keep its own partition in memory. Redis Cluster divides the key space into 16,384 hash slots and assigns them to nodes, while Apache Ignite and Hazelcast distribute and replicate data across JVM heaps as an in-memory data grid (IMDG).

The design difficulty of a distributed IMDB lies in transactions that cross partitions. A single-partition transaction is finished serially and fast by that node, but a transaction spanning two partitions needs distributed consensus such as [[two-phase-commit|two-phase commit (2PC)]], so latency surges. Thus the core of distributed IMDB design is a data locality (co-location) design that gathers data accessed together into the same partition. This is why VoltDB stresses choosing the partition key carefully.

  • Hash partitioning: hashes the key for even distribution, but is unfavorable for range queries.
  • Range partitioning: favorable for range scans, but a hot partition can appear.
  • Replica: replicates each partition into 2-3 copies to secure availability and read scaling on node failure.
  • Rebalancing: redistributes slots/partitions when adding or removing nodes, minimizing movement with [[consistent-hashing|consistent hashing]].

4. Comparison with Disk-based DB and Use Cases

Because a table alone does not explain "why" these differences arise, context is added. The performance gap between a disk DB and an IMDB is not merely "RAM is faster than disk." It is because the location of the bottleneck itself moves. In a disk DB the bottleneck was I/O, but in an IMDB it moves to memory bandwidth, CPU cache locality, and the synchronization point of logging. Therefore IMDB tuning concentrates less on "how to place indexes" and more on "how to partition data and lay it out cache-friendly per core" and "how to batch log flushes."

In concrete numbers, the gap becomes more specific. On the same hardware, under the condition that data all resides in memory, a simple key lookup in an IMDB is usually on the order of a few to tens of microseconds, responding within 1 ms even including a network round trip, whereas a disk DB surges to hundreds of microseconds to a few milliseconds on SSD, and a few to tens of milliseconds on HDD, the moment even a single buffer miss occurs. The difference in single-request latency may look small, but when processing hundreds of thousands per second, it widens into a dozens-fold difference in cumulative throughput and tail latency. For this reason the economics of an IMDB are also converted into "reducing the number of servers" — if what would take ten disk DB servers to handle the same TPS is handled by one or two IMDB servers, there is a regime where, even with the high unit price of RAM, total cost of ownership (TCO) is reversed.

Use cases concentrate in domains where latency and throughput demands are extreme.

  • Real-time session·cache·feature serving: Redis is widely used with sub-millisecond response for session stores, leaderboards, [[caching-strategy|distributed caches]], and AI feature stores ([[feature-store]]). For example, a large commerce site's cart and inventory counters must withstand hundreds of thousands of updates per second, for which a disk DB's cost explodes.
  • Ultra-fast OLTP: a telecom's real-time charging (OCS) must debit and verify the balance for each call, and VoltDB-style systems process hundreds of thousands of TPS at deterministic latency through per-partition serial execution.
  • Unified operations·analytics (HTAP): SAP HANA places ERP operational data in memory columnar storage, providing real-time management analytics without separate ETL — bringing a report that used to be built by a nightly batch down to seconds.
  • Time series·telemetry: tiering that keeps the recent window in memory and the past on disk has become the standard pattern of [[time-series-database|time series DBs]].
  • Real-time analytics·stream state storage: suitable for holding "state that lives briefly but is updated very frequently," such as the window-aggregation state of a stream processing ([[stream-processing-windowing]]) engine or the intermediate results of real-time risk computation.

What these cases have in common is that the condition "even if the data is not small, the working set (the part actually accessed frequently) fits in memory" holds. Conversely, if the working set greatly exceeds memory, or if the main workload is analytics that sequentially scans large cold data, the IMDB's advantage is diluted and only cost grows. The essence of case selection is not the flashiness of the technology but a quantitative answer to the question "is I/O really the bottleneck in this workload?"

5. Advanced — Recent Trends and Hardware Change

The IMDB is the field that most sharply demonstrates the proposition that "a change in the hardware premise changes the software structure." Therefore, recent trends too cannot be seen apart from advances in memory and interconnect hardware.

The future of IMDBs is interlocked with the evolution of the memory hierarchy. First, the emergence of persistent memory and storage-class memory (SCM) ([[emerging-nvm-scm]]). This tier, once represented by Intel Optane PMem, with its property of "DRAM-class latency + retained even when power is off," simultaneously mitigates the IMDB's biggest weaknesses, volatility and logging cost. Placing data directly in persistent memory reduces snapshot and log burden and speeds up restart. However, after the discontinuation of Optane (2022), CXL (Compute Express Link) based memory expansion and pooling ([[cxl-compute-express-link]]) has taken over its place, developing in the direction of flexibly attaching terabyte-class memory across node boundaries.

Second, cloud managed / serverless-ization. Amazon ElastiCache, MemoryDB (Redis-compatible yet with durability strengthened by log replication), Azure Cache, Redis Enterprise, and others provide IMDBs as a "managed service," freeing operators from directly handling capacity, replication, and backup. In particular, MemoryDB combines "in-memory speed + multi-AZ log-based durability" and presents the position of an IMDB usable as a primary database, beyond a cache.

Third, the spread of HTAP / translytical. As the boundary between operations and analytics blurs, an architecture that processes both OLTP and OLAP in one in-memory engine ([[htap]]) is spreading, centered on finance and retail. As likely exam directions: (1) the IMDB's durability-guarantee mechanism (log + snapshot) and RPO design, (2) the grounds for the difference in concurrency control versus a disk DB (serial vs MVCC), (3) the changes SCM/CXL bring to IMDB architecture, and (4) considerations when promoting Redis from a "cache" to a "primary store" are strong candidates. An answer is persuasive when organized around the causation "change in the hardware premise -> redesign of the software structure."

6. Considerations and Implications

  • Durability and availability design is the essence (trade-off): the success of adopting an IMDB depends not on speed but on "what is lost when memory is wiped." Decide synchronous/asynchronous commit, snapshot interval, and the number of replicas explicitly against RPO·RTO targets ([[rpo-rto-disaster-recovery]]), and presume replication ([[database-replication-high-availability]]) so as not to depend on a single node's memory for everything.
  • Hybrid·hot-data strategy over a full switch: because RAM is expensive per GB and limited in capacity, a design that puts all data in memory is usually uneconomical. It is more realistic to tier so that hot data is in memory and cold data is on disk / object storage, and to manage consistency with [[caching-strategy|cache strategies]] such as cache-aside and write-through.
  • Judging workload fit comes first: a disk DB is also quite fast if the buffer pool is sufficient. An IMDB shows its true value when characteristics such as extreme latency·throughput demand, predictable deterministic latency, and HTAP are pronounced. Rather than "fast no matter what, so it is good," one must first quantitatively verify whether I/O is the real bottleneck and whether the working set fits in memory.
  • Operations·observability·security perspective: memory-resident data needs warm-up on every restart, and there is a risk that sensitive information is exposed to disk via dumps and swap, so encryption, swap disabling, and access control are needed. Also, constantly observe ([[observability]]) memory usage, fragmentation, and replication lag to prevent a full outage caused by OOM.
  • Alignment with the hardware roadmap: the memory tier changes fast, as with the discontinuation of SCM and the rise of CXL. A design strongly coupled to specific hardware (e.g., Optane) carries a longevity risk, so placing an abstracted durability layer to make the design flexible against hardware replacement is a strategic judgment from a Professional Engineer's perspective.

References

In one line: An in-memory database moves the primary store of data to RAM, removes disk I/O from the normal path, and redesigns data structures, concurrency control, and recovery on the memory premise; in exchange for speed it compensates for volatility with logs, snapshots, and replication, and its essence is designing the trade-off between durability (RPO) and cost·capacity.