Debunking the Top 3 Myths About Modern In-Memory Databases

Myth 1: Speed Is the Only Advantage

RAM provides read/write latency that is orders of magnitude lower than magnetic or SSD storage, so loading a table completely into memory can yield very high throughput. However, the amount of data that can stay resident is limited by the operating system’s virtual‑memory configuration. The size of the swap partition (often 1–2 × the physical RAM) caps the total addressable memory for a process. When the in‑memory database’s working set approaches the swap limit, the kernel begins paging out pages, causing a sudden increase in latency and a drop in throughput. Even with cheap DRAM, a dataset that exceeds the combined RAM + swap capacity will not benefit from the raw speed of memory.

Myth 2: Moving from 32‑bit to 64‑bit Is Trivial

On a 32‑bit architecture the virtual address space is limited to 4 GiB, of which the OS typically reserves a portion for kernel space, leaving roughly 2–3 GiB for user processes. Compiling an in‑memory database for a 64‑bit target removes this hard ceiling, allowing addressable memory up to 2^64 bytes. In practice current CPUs and operating systems expose only the lower 48 bits (256 TiB) of that space, which is still far beyond the needs of most big‑data workloads.

Recompilation is required because pointer sizes double (from 4 bytes to 8 bytes), affecting data structures, serialization formats, and binary compatibility.

Memory‑intensive algorithms can be redesigned to exploit the larger address space, e.g., using pointer‑based indexing or space‑for‑time trade‑offs that were impossible under 32‑bit limits.

Operating‑system support (e.g., large pages, NUMA awareness) must be enabled to achieve optimal performance on 64‑bit systems.

Myth 3: Virtual Memory Has No Impact

Virtual memory, introduced by Peter Denning in the 1970s, abstracts physical RAM into a contiguous address space for each process. The kernel may move infrequently used pages to a swap area on disk. For an in‑memory database, any swap activity defeats the purpose of keeping data in RAM. Therefore, designers must consider:

The size of the swap partition relative to expected data volume.

Configuration of vm.swappiness to discourage paging.

Use of huge pages (e.g., 2 MiB or 1 GiB) to reduce page‑table overhead and TLB misses.

Monitoring tools (e.g., top, vmstat, perf) to detect when the process starts to swap.

When swap is exhausted, the kernel may kill the process, leading to data loss unless persistence mechanisms are in place.

Practical Takeaways

Although only the lower 48 bits of a 64‑bit address space are currently usable, this provides ample headroom for most large‑scale analytics workloads. As DRAM becomes less scarce, developers should shift focus from pure speed to architectural concerns such as address‑space limits, virtual‑memory configuration, and the trade‑offs between memory consumption and algorithmic complexity.