Redis vs PostgreSQL vs Kafka: Choosing the Right Tool for the Job
Three technologies. Three fundamentally different jobs. How I think about choosing PostgreSQL, Redis, and Kafka when designing distributed backend systems.
Core Insight
- PostgreSQL → “What is true?” (source of truth)
- Redis → “What do I need quickly?” (performance layer)
- Kafka → “What happened?” (event stream)
- Never treat them as interchangeable databases
A common architectural mistake is asking:
“Should I use Redis, PostgreSQL, or Kafka?”That question is incomplete. These technologies are not direct replacements for one another. They solve different classes of problems.
A better question is:
What problem am I solving, what guarantees do I need, and what kind of data am I dealing with?1. Start With the Problem, Not the Technology
Before choosing a database, cache, or message broker, I ask:
Select your architectural requirement to see the recommended tool in real time:
- Is this authoritative business data?
- Does it need transactions?
- Does it need extremely fast temporary access?
- Do multiple services need to react to the change?
- Should the data survive application restarts?
- Do consumers need to process events independently?
- Do I need ordering or replay?
2. PostgreSQL: The Source of Truth
I generally think of PostgreSQL as the system that answers:
What is the current authoritative state of the business?These entities require strong consistency and durable storage. If the application restarts, Redis disappears, or Kafka is temporarily unavailable, the enrollment must still exist. That is why PostgreSQL belongs at the center of many transactional systems.
3. PostgreSQL and Transactions
One of PostgreSQL’s biggest advantages is transactional correctness. Consider cohort enrollment with capacity = 30 and available seats = 1:
The database is enforcing the critical state transition. This is fundamentally different from caching or event streaming.
4. PostgreSQL Is More Than a CRUD Database
5. Redis: Optimize Access to State
Redis answers a different question:
How can I access frequently needed data extremely quickly?6. Redis Should Not Automatically Become Your Database
Because Redis is fast, it can be tempting to store everything there. Ask:
A safer pattern is: PostgreSQL as Source of Truth, Redis as Performance Layer.
7. The Cache-Aside Pattern
const cached = await redis.get(key); if (cached) return JSON.parse(cached); const data = await repository.find(...); await redis.set(key, JSON.stringify(data), 'EX', 300); return data;
8. Redis Is Also Useful for Rate Limiting
A Redis counter can track request activity for limits such as 100 requests / minute:
9. Kafka: Moving Events Through the System
Kafka answers:
How can systems communicate through durable streams of events?10. Kafka Is Not a Database Replacement
Kafka stores messages durably, but that does not mean it should become your primary business database. PostgreSQL answers “Is this student enrolled?” Kafka answers “What happened and who should react?”
11. State vs Events
12. Example: Student Enrollment
13. Another Example: Certificate Generation
14–15. What Happens If Redis or Kafka Goes Down?
16. Don’t Create Distributed Coupling by Accident
17. Consistency vs Performance vs Decoupling
| Concern | PostgreSQL | Redis | Kafka |
|---|---|---|---|
| Durable business state | Primary | Secondary / Optional | Event log durability |
| Primary Strength | ACID Transactions & Consistency | Sub-millisecond Speed | High Throughput Event Streaming |
| Key Use Case | Source of Truth Data | Caching & Rate Limiting | Decoupled Asynchronous Processing |
| Failure Impact | High (Service Downtime) | Medium (Latency Spikes) | Medium (Delayed Processing) |