Cache vs Database
Cache vs database explained for system design interviews. Why caches are fast but temporary, and how they work together.
A cache stores data in memory for very fast access but can lose that data if it restarts, and is meant to be temporary. A database stores data on disk so it survives restarts and is the durable source of truth, but reading from disk is slower than reading from memory.
Cache vs Database at a glance
| Cache | Database | |
|---|---|---|
| Storage location | RAM, in memory | Disk, persistent storage |
| Speed | Very fast, microseconds | Slower, milliseconds |
| Durability | Temporary, data can be lost on restart | Durable, survives restarts and crashes |
| Purpose | Speed up repeated reads of hot data | Be the reliable source of truth |
| Data size | Small subset of frequently accessed data | Full dataset |
| Example tools | Redis, Memcached | PostgreSQL, MySQL, MongoDB |
When to use each
Choose Cache when
- The same data is read very frequently and recomputing or refetching it is expensive.
- You can tolerate the small risk of slightly stale data for a big speed win.
- You want to reduce load on your database by absorbing repeated reads.
Choose Database when
- The data must be durable and cannot be lost if a server restarts.
- You need the guaranteed correct, current version of the data.
- You are storing the full dataset rather than just frequently accessed pieces.
Why you almost never replace a database with a cache
A cache is not a replacement for a database, it sits in front of one. When your application needs data, it checks the cache first. If the data is there, called a cache hit, it returns almost instantly. If not, called a cache miss, the application reads from the database, then usually stores a copy in the cache so the next request is fast. This pattern is called cache aside, and it is one of the most common patterns in system design.
The real trade off, staleness
Because a cache holds a copy of the data, that copy can become out of date if the underlying data changes in the database without the cache being updated or cleared. This is exactly the famous hard problem in computer science, cache invalidation. Every caching strategy has to answer the question of when to update or clear cached data so users are not shown stale information.
A strong system design answer mentions setting a time to live, or TTL, on cached entries, so even if you forget to invalidate something manually, it naturally expires and gets refreshed from the database after a set period.
Frequently asked questions
What is cache invalidation?
It is the process of removing or updating cached data once the underlying source of truth changes, so users do not keep seeing outdated information. It is famously considered one of the hardest problems in computer science to get exactly right.
Is Redis a database or a cache?
Redis is technically an in memory data store that can be used as either. It is most commonly used as a cache in front of a primary database, but it also supports persistence and can be used as a lightweight primary database in some systems.
What happens if the cache and database disagree?
The database is treated as the source of truth. A well designed system falls back to the database on a cache miss and refreshes the cache, and uses a short TTL or explicit invalidation to limit how long the two can disagree.
Want more interview ready comparisons?
Browse every Cache vs Database style breakdown, or explore the full question library.
All comparisons Browse questions