Choosing a database should be simple. But it never is.
You start with:
“Should I use PostgreSQL or MongoDB?”
And 2 hours later you’re reading about:
- CAP theorem
- distributed consistency
- indexing strategies
- scaling limits
And still… no decision.
The real problem
Most advice online looks like this:
- “Use SQL for structured data”
- “Use NoSQL for flexibility”
- “Use Redis for caching”
That’s not helpful.
Because real systems don’t fail due to definitions —
they fail due to wrong tradeoffs.
Where systems actually break
From experience, database decisions usually fail at:
- 🔥 Scale → write throughput collapses
- ⚡ Latency → p99 spikes under load
- 💸 Cost → infra becomes unsustainable
- 🧩 Complexity → debugging becomes painful
The problem isn’t choosing a database.
It’s understanding:
what will break later
So I built something for this
I created a simple tool that helps you choose a database based on:
- your use case
- scale requirements
- consistency needs
- system constraints
👉 Try it here:
https://whatdbshouldiuse.com
What it actually does
Instead of saying:
“Use MongoDB”
It tries to answer:
“Why would MongoDB fail for your use case?”
And then suggests:
- better alternatives
- combinations (e.g., PostgreSQL + Redis)
- architecture patterns
Example
If you’re building a chat app:
You might get something like:
- PostgreSQL → good for consistency
- Redis → great for real-time messaging
- Cassandra → useful for massive scale
But also:
- where each breaks
- when to switch
- what hybrid architecture looks like
What I’m trying to build
Not just a “database picker”
But a:
decision system for backend architecture
Would love feedback
- Does this actually help?
- What use cases should I add?
- What’s confusing?
👉 https://whatdbshouldiuse.com
If you’ve ever struggled with choosing the right database, I’d love to hear your thought process.
Top comments (0)