Featured image of post Why Cheap Hardware Won't Make Redis Replace a Core Database

Why Cheap Hardware Won't Make Redis Replace a Core Database

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.

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.

Made with laziness love 🦥

Subscribe to My Newsletter