Redis is an in-memory database, so it is fast. We saw that in Part 1. But that explanation is true and still incomplete.
Modern databases serve a large percentage of reads from memory. In many real systems, PostgreSQL can read almost everything it needs from Shared Buffers and avoid touching the disk. Prepared statements and reusable query plans can reduce repeated parsing and planning work as well.
So the more useful question is this: if both systems are reading from RAM, why can they behave so differently under load?
Let’s assume the best case for PostgreSQL: the required pages are already in memory, and the application uses prepared statements and cached plans. Imagine a live-score application during a World Cup final, with hundreds of thousands of users asking the same question at nearly the same time: “What is the current score?”
1. Parsing and execution setup
With prepared statements and cached plans, PostgreSQL can avoid much of the repeated parsing and planning work. Redis can still have a lower per-command overhead, but at this stage the difference is better described as low versus very low, not as disk speed versus RAM speed.
2. Finding the value
PostgreSQL still needs to answer: where is the row that contains the requested value? Even with a cached execution plan, an index scan may begin at the root of a B-tree, compare keys, and traverse internal nodes until it reaches a leaf node.
The leaf entry contains a TID (Tuple Identifier), which points to the row version’s location in the table. For a B-tree, this lookup is typically O(log n): the amount of work grows with the height of the tree, although caching and the small height of practical indexes make the operation efficient.
Redis answers a narrower question: given this key, what value is associated with it? For a typical string-key lookup, Redis uses a hash-table lookup with average-case O(1) complexity, subject to hash-table behavior and implementation details.
Conceptually, the difference is:
PostgreSQL: key → index structure → tuple location → row
Redis: key → hash-table entry → value3. MVCC visibility checks
PostgreSQL uses Multi-Version Concurrency Control (MVCC). This means that several row versions may exist, and each transaction reads according to a particular snapshot. PostgreSQL must check transaction and visibility metadata to determine whether the version it found is visible to that query.
A normal PostgreSQL read does not usually acquire a blocking row lock, but visibility and transaction checks are still necessary for correctness.
For a simple Redis read, the server does not perform an equivalent MVCC snapshot check for each key. Redis commands are processed atomically with respect to other commands on the same Redis event loop, and the key-value model does not provide PostgreSQL-style row-version visibility for that read.
4. Decoding the stored value
In PostgreSQL, the value is stored inside a database page, commonly an 8 KB page. The engine may need to use the page’s line pointer to locate the tuple, interpret tuple metadata, and find the requested column within the row representation.
Redis stores a value in a data structure designed for its command model. For a simple key lookup, it can follow the hash-table entry and return the associated object without navigating a relational page and tuple layout.
This comparison concerns simple reads. Writes can produce an even wider difference in work for some workloads, but Redis is not automatically faster for every write or every data model. Durability settings, persistence, replication, networking, serialization, and workload shape all matter.
Redis is fast not only because it keeps data in memory. It is fast because, for selected use cases, it performs less work. It performs less work because it solves a smaller set of problems than a full database: Redis does not provide PostgreSQL’s relational queries, general transaction model, MVCC visibility rules, or the same durability and consistency guarantees by default.
That is the real trade-off. Redis can be an excellent accelerator for carefully chosen hot paths, while PostgreSQL remains the system of record and handles the broader correctness requirements.