An in-memory database (IMDB) keeps its primary working data in RAM instead of reading it from disk for each request. Examples include Redis, its Linux Foundation fork Valkey, and SAP HANA. Memcached is often grouped with them, though it is a pure cache with no persistence.
Reading from RAM takes on the order of a hundred nanoseconds, while even a fast NVMe SSD read takes tens of microseconds and a network round trip to a disk-based database adds more. Keeping data in memory removes most disk I/O from the request path, so in-memory systems can answer simple lookups in well under a millisecond.
Typical Use: A Cache in Front of a Database
In-memory stores are most often used as a caching layer in front of a primary relational database or an analytical system.
Consider an e-commerce homepage that shows the “Top 10 Bestselling Items” during a holiday sale. If every page view ran the ranking query against PostgreSQL, thousands of identical queries per second could saturate the database. Instead, the application runs the query every five minutes and stores the result in Redis. Page views read the cached result from memory, and PostgreSQL handles one query per refresh instead of one per visitor. The trade-off is staleness: users may see results up to five minutes old.
Trade-offs: Durability and Cost
1. Volatility
RAM loses its contents when power is lost or the process restarts. In-memory databases address this in different ways. Redis offers point-in-time snapshots (RDB) and an append-only file (AOF) that logs writes, plus replication to other nodes. SAP HANA persists data and logs to disk and reloads after a restart. Configured carefully, these can be durable systems, but a pure cache like Memcached keeps nothing across restarts, so treat each product’s durability settings as a design decision.
2. Cost
S3 Standard storage costs about $0.023 per GB-month in us-east-1, while cloud RAM costs far more per GB. Keeping a petabyte-scale dataset in memory is rarely affordable. In-memory stores are therefore used for hot, small datasets: user sessions, leaderboards, rate-limit counters, feature lookups for model serving, and cached query results.
A Note on Licensing
Redis moved from the BSD license to RSALv2 and SSPLv1 in March 2024, and the Linux Foundation launched Valkey as a BSD-licensed fork of Redis 7.2.4. Redis 8 (May 2025) added AGPLv3 as a third license option. Check which license applies before embedding or offering either one as a service.
In-Memory Databases vs Lakehouse Engines
A data lakehouse keeps its tables in object storage as Apache Iceberg metadata over Parquet files. Query engines still rely on memory heavily, but as a processing and caching layer rather than as the system of record:
| In-memory database | Lakehouse engine (Dremio, Trino, Spark, DuckDB) | |
|---|---|---|
| Source of truth | RAM, with optional persistence | Iceberg tables in object storage |
| Typical query | Point lookups by key, simple ranges | Scans, joins, and aggregations over large tables |
| Use of memory | Holds the dataset | Holds working data during execution, often in the Apache Arrow columnar format, and spills to disk when it runs out |
| Speed-up technique | Everything in RAM | File and metadata caches on local NVMe, plus precomputed results such as Dremio reflections or materialized views |
DuckDB blurs the line: it can run as an in-process database with an in-memory catalog and also read Iceberg tables from object storage. For dashboards that need sub-second answers, the usual lakehouse approach is to precompute aggregates and cache hot files near the engine, and to reserve a key-value store like Redis for application-facing lookups that need consistent sub-millisecond latency. For how engines manage buffer pools and caches, see Buffer Pools, Caches, and the Memory Hierarchy.
Summary
An in-memory database keeps working data in RAM to remove disk I/O from the request path, which suits small, hot datasets and caching in front of slower systems. It trades higher cost and careful durability configuration for that speed. Lakehouse engines use memory differently: the data lives in Iceberg tables on object storage, and RAM, local caches, and precomputed reflections speed up queries on top of it.
Learn More
To learn more about the Data Lakehouse, read The Lakehouse Built for Everyone by Alex Merced. You can find this and other books by Alex Merced at books.alexmerced.com.