Asha follows Ravi. Now ask: who follows Ravi?
The more a shape fits the reads you expect, the faster they are, and the more an unexpected one costs.
Is NoSQL faster?
Bad: “NoSQL is faster”
Miss its key design and a query scans every node.
Good: Precomputed access path
Data kept in one query’s shape and partition. A PostgreSQL primary-key lookup is one probe too.
NoSQL’s bargain: give up joins, get partitioning by key
Add nodes to add writes. A query for user_id = u1 asks one node; city = Pune asks all four and waits for the slowest.
Six months in, product wants “orders per restaurant, by hour”.
The bill
PostgreSQL: add an index. Query-first store: a new table, a backfill, every write path changed, and a window where they disagree.
Start relational. Earn each extra store with a specific trigger
- A number: 11,600 append-only writes/s → wide-column
- An access pattern: free riders within 3 km → Redis geo
- A shape: varied attributes, read whole → document or
jsonb
Food delivery: one source of truth, a store per access pattern
Copies flow out of PostgreSQL via CDC and never write back. The price is five systems to run, and copies that lag.
SQL gained JSON, graph queries and vector indexes. NoSQL gained SQL-like languages and transactions.
What still differs
The default shape: relational starts normalized and flexible; NoSQL starts denormalized and partitioned, with transactions only within limits.
Remember
Start relational for the system of record. Add a store only when a number, access pattern or shape demands it.