---
title: "Why Cheap Hardware Won't Make Redis Replace a Core Database"
description: "As hardware gets cheaper, why not use Redis as the main database? The short answer: because the limitation isn't speed. It's guarantees and data semantics."
pubDate: "2023-05-25"
lang: "en"
slug: "redis-vs-core-database"
url: "https://hoangyell.com/redis-vs-core-database/"
author: "HoangYell"
translation_vi: "https://hoangyell.com/vi/redis-vs-core-database/"
categories: ["System Design"]
tags: ["system-design", "databases", "redis", "architecture", "caching"]
heroImage: "https://raw.githubusercontent.com/HoangGeek/store/main/webp/photo-1544383835-bda2bc66a55d.webp"
---

# Why Cheap, Powerful Hardware Still Won’t Make Redis Replace a Core Database

As hardware gets cheaper - more RAM, faster NVMe SSDs, higher network bandwidth - a common assumption appears:

> If Redis can keep everything in memory and disks are blazing fast, why not use Redis as the main database and forget MySQL or Postgres?

The short answer: because the limitation isn’t speed. It’s guarantees and data semantics.

Below is a concise breakdown.

***

## 1. Durability Guarantees

**Durability** (the “D” in ACID) means: once a transaction commits, the data will not be lost - even if the server crashes immediately after.

Traditional core databases (e.g., MySQL, PostgreSQL) rely on:

* **WAL (Write-Ahead Log)** - changes are written to disk before commit.
* **ACID** - Atomicity, Consistency, Isolation, Durability.

Redis offers:

* **AOF (Append-Only File)** - logs commands.
* **RDB (Snapshot)** - periodic full-memory dump.

Even with fast disks:

* AOF durability depends on `fsync` configuration.
* Replication is typically asynchronous.
* Small windows of data loss are possible.

Faster hardware reduces latency. It does not change the durability model.

***

## 2. Transaction Semantics

**Transaction semantics** define how multiple operations behave as a unit.

Core databases provide:

* Full **ACID transactions**.
* Isolation levels (Read Committed, Repeatable Read, Serializable).
* True rollback guarantees.

Redis provides:

* **MULTI/EXEC** - queued command execution.
* Lua scripting for atomic key-level logic.

But:

* No advanced isolation levels.
* No relational constraint enforcement inside transactions.
* No full rollback model like MVCC-based systems.

More RAM does not turn MULTI/EXEC into full ACID.

***

## 3. Query Engine Capability

A **query engine** is the system that parses, optimizes, and executes complex data retrieval.

Relational databases offer:

* SQL (Structured Query Language).
* Joins.
* Secondary indexes.
* Query optimizers.
* Aggregations and relational algebra.

Redis is primarily:

* Key-based lookup.
* Data-structure oriented (hash, set, sorted set, stream).

Complex relational queries must be manually modeled at the application layer.

Better hardware improves throughput. It does not create a relational query engine.

***

## 4. Data Integrity Enforcement

**Data integrity** means the database enforces correctness rules.

Core DB features:

* Foreign keys.
* Constraints.
* Schema enforcement.
* Declarative integrity rules.

Redis typically:

* Relies on application logic for integrity.
* Does not enforce relational constraints.

Hardware cannot replace a constraint engine.

***

## 5. System-of-Record Expectations

A **System of Record** is the authoritative source of truth for business-critical data.

In regulated or high-risk systems (fintech, healthcare, accounting):

* Zero data loss tolerance.
* Strict audit trails.
* Strong transactional correctness.

Redis excels at:

* Caching.
* Session storage.
* Rate limiting.
* Real-time counters.
* Leaderboards.

But replacing a relational core database requires more than speed - it requires formal guarantees.

***

# The Core Insight

Cheap hardware solves:

* Capacity problems.
* Latency problems.
* Throughput limits.

It does **not** solve:

* Transaction guarantees.
* Durability semantics.
* Relational query complexity.
* Integrity enforcement.

Redis is a powerful in-memory data store.

A relational database is a guarantee engine with a query engine attached.

Those are fundamentally different design goals.

And hardware does not change design goals.