When should you use a relational database?
Use a relational DB by default unless you have a strong reason not to.
✅ Use a relational DB when:
1️⃣ You need strong consistency & correctness
- Financial transactions
- Orders, payments, balances
- Inventory, quotas, limits
Why
- ACID transactions
- Referential integrity
- Constraints enforced by the DB
If incorrect data is unacceptable → SQL DB
2️⃣ Your data has clear relationships
- Users → Orders → OrderItems
- Accounts → Transactions
- Products → Categories
Why
- Foreign keys
- JOINs
- Normalization
Relational model fits real-world business domains naturally.
3️⃣ You need complex queries
- Multi-table joins
- Aggregations
- Window functions
- Subqueries
Why
- SQL is extremely expressive
- Optimizer handles execution complexity
4️⃣ You need transactions spanning multiple entities
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
Why
- Atomicity guarantees
- Easy rollback on failure
5️⃣ You want data integrity enforced centrally
- NOT NULL
- UNIQUE
- CHECK
- FOREIGN KEY
Why
- Business rules live in the DB, not scattered across services
6️⃣ You want predictable long-term evolution
- Schema migrations
- Backward compatibility
- Auditing
Why
- Strong tooling (Flyway, Liquibase)
- Mature ecosystem
When should you not use a relational DB?
❌ Avoid relational DBs when:
1️⃣ You need massive horizontal write scalability
- Millions of writes/sec
- Global distribution
- Event ingestion
Better fit
- Cassandra
- DynamoDB
- Kafka + storage
Why
- Joins & transactions limit horizontal scaling
2️⃣ Your schema is highly dynamic or unknown
- User-defined fields
- Rapidly changing payloads
Better fit
- Document DBs (MongoDB)
⚠️ But beware: flexibility today → chaos tomorrow.
3️⃣ Your access pattern is key-based only
getById(key)
put(key, value)
Better fit
- Redis
- DynamoDB
Using Postgres here is overkill.
4️⃣ You’re doing analytics, not transactions
- Reports
- Aggregations over billions of rows
- BI dashboards
Better fit
- ClickHouse
- BigQuery
- Snowflake
OLTP ≠ OLAP.
5️⃣ You need full-text search
- Relevance ranking
- Fuzzy matching
- Tokenization
Better fit
- Elasticsearch / OpenSearch
Postgres can do search — but it’s not its core strength.
6️⃣ You accept eventual consistency
- Social feeds
- Counters
- Metrics
Better fit
- NoSQL systems
Decision table (interview gold)
| Requirement | Best choice |
|---|---|
| Strong consistency | Relational DB |
| Complex joins | Relational DB |
| High write throughput | NoSQL |
| Flexible schema | Document DB |
| Analytics | Columnar DB |
| Caching | In-memory DB |
One-sentence senior answer (perfect)
Use a relational database when data correctness, relationships, and complex queries matter; avoid it when scale, flexibility, or specialized access patterns are more important than strong consistency.
Final interviewer tip 🎯
If unsure — start with PostgreSQL.
Most startups and even large systems move away from SQL too early and regret it.