SQL vs NoSQL

The problem

Adda survived the university spike. The load balancer spreads traffic, the cache soaks up the hot posts, the CDN serves images from the edge. But under all of it is the same little SQLite file Ria started with under her desk, and it is groaning. Users, posts, replies, likes, follows — the data has shape now, and that shape matters.

So Ria hires Shuvo, a data engineer, and Shuvo's first question over chai is the one Ria has been dodging for months: "Which database are we actually building on?" Ria reaches for the answer everyone repeats — "SQL is old, NoSQL scales" — and Shuvo stops her. Pick this on vibes, and six months from now it is the one thing you cannot easily undo. This lesson is about making that fork on purpose, by looking at the shape of Adda's data and how it reads it, not at which database is trendy.

A first attempt

The naive move is to pick by scale: "Adda might get big, so NoSQL." But scale is rarely your first problem — your first problem is modeling, and Shuvo proves it with a throwaway example on the whiteboard: an e-commerce order.

Say you store an order as a relational schema. An order has a customer, line items, a shipping address, and payment status. In a relational store that is four tables tied by foreign keys. To render one order page you join them:

SELECT o.id, c.name, i.sku, i.qty
FROM   orders o
JOIN   customers c ON c.id = o.customer_id
JOIN   line_items i ON i.order_id = o.id
WHERE  o.id = 4711;

That is clean and correct. But every read touches multiple tables, and at very high volume across many machines those joins become expensive — a distributed join can fan out to every shard. Meanwhile the document view stores the whole order as one JSON blob and reads it in a single lookup — fast, but now the customer's name is copied into every order, and changing it means rewriting many documents.

Neither is "better," Shuvo says. They optimize for opposite things — and Adda's real question is which opposite fits its reads.

The insight

Pick the model that matches your access pattern, not your data in the abstract.

If you read data by following relationships in many directions ("all posts by this user," "all users in Dhaka," "top posters this week"), a relational store's joins and ad-hoc queries pay off. If you almost always read one self-contained thing by its id ("give me this user's profile," "this post"), a document or key-value store hands it to you in one hop and scales horizontally without join pain.

The other half of the choice is schema-on-write vs schema-on-read. SQL validates structure when you write (every row must fit the columns). NoSQL often defers structure to when you read (each document can differ). Rigidity is a feature when data must stay consistent; flexibility is a feature when the shape is still moving — and Adda's feature set is still very much moving.

How it works

Concrete numbers

A single-key lookup in a well-tuned key-value store returns in well under 1 ms and a single node handles 100k+ reads/second. A 4-table join on an indexed relational database is often 1–10 ms — fine until you shard, where a cross-shard join can balloon to hundreds of ms because it waits on the slowest node.

Storage tells the same story in reverse. Denormalizing the display name into 10 million posts wastes space and turns a one-row name change into a 10-million-document rewrite. Normalizing keeps it as one row but costs a join on every read. You are trading write cost for read cost — and Shuvo wants Adda to trade with its eyes open.

When to use it

Practice

Recap

• Choose by access pattern and data shape, not by which database is fashionable.
• SQL trades flexibility and easy scale for joins, transactions, and ad-hoc queries; NoSQL makes the opposite trade.
• Schema-on-write validates early; schema-on-read stays flexible but pushes the burden onto readers.