SQL vs NoSQL for beginners: picking the right kind of database

Zoya Mirza walks into SeatJaldi’s new Baner office on Monday and picks up a marker before her laptop. Meera has hired her, a calm senior backend engineer, to lead the tech team.

Arjun proudly says all the real data lives in one database, in SQL tables. Zoya writes one line per screen on the whiteboard: “What do you read, what do you write, how often?”

The answers do not match. Seat holds, already in the session store since lesson 9, change constantly and vanish within minutes. Payments stay for years and must add up to the rupee. Stadiums and concert halls share one venue table full of empty columns.

Arjun gets nervous. “A friend says SQL does not scale. Should we move everything to NoSQL?” Zoya asks him to list what every screen reads and writes. “The answer is not SQL or NoSQL,” she says. “Each choice is a trade-off.” So what is it?

SQL databases keep data in tables with fixed columns, joins and transactions. NoSQL databases relax some of that for flexible shapes or simple, fast access. A join matches rows from two tables by a shared id.

SeatJaldi’s bookings table is one: every row has the same columns. Databases that are not relational share one family name.

Every database has a shape for its data.

Most relational databases reject a write that does not fit the schema. Many NoSQL stores let records differ, so your code keeps the shape instead.

What just happened? Each myth judged a database by its label; each fact judged it by the data.

Keep one line in your head: choose the store from how the data is read and written, not from fashion. Ask:

• What do you read, and by which id or range?
• What do you write, and how often?
• What must you join or add up exactly?

You have seen this on a shopping app: a phone’s page shows battery, a shirt’s page shows fabric. Each product keeps its own fields.

You log in, close the tab, and are still logged in minutes later, but not a day later. Your session sat under one key that expired.

A social app says “3 friends also bought this”. It follows links from you to your friends, one hop at a time.

There are four common kinds: key-value, document, wide-column and graph. Each is a part of Rekha’s shop. The hook board is the simplest: give it a tag number and it hands back what hangs there.

SeatJaldi already has one: the Redis from lesson 12. The folder is next, where a stadium sheet lists gates and a concert-hall sheet lists balconies.

MongoDB is a well-known document store. Rekha’s ledger is the third kind: open one day’s page, then read its entries in order.

The last kind is the pin board: Rekha follows one customer to their friends, then to the friends’ friends.

Use NoSQL when your data has a simple or flexible shape and is read and written in one known way. Stay with SQL when you need joins, totals and transactions.

No. Holds would be happier, but payments would lose their joins and all-or-nothing writes. Each feature asks a different question of its data. Rekha would never total her sales from loose sheets.

Engineers first write down the queries, the questions the app asks the database. Then they pick the store to fit. When data outgrows one machine, both families split it.

Something has to decide which part each record lives in.

DynamoDB hashes the partition key’s value to pick the part, so its guide asks for a key with many distinct values. MongoDB also spreads data by a chosen key. A query with the key goes only to the parts holding it; one without it must ask every part.

Relational databases can spread out too, with more care, even across parts of the world.

Some relational databases spread one set of tables across several regions.

One managed distributed SQL database now claims strong consistency across regions. Do not assume SQL cannot span regions.

The central trade-off is joins against copies. Copy the venue name into every booking row and “My bookings” needs no join. Rename the venue and every copy must change. Rekha knows this: she writes a customer’s name on every special-order sheet, so a renamed customer means fixing them all.

What just happened? One key per hold: match 42, seat A12. NX means “only if nobody holds it”, so the second SET answers nil, meaning nothing was set. EX 600 expires the key after 600 seconds, or 10 minutes. Until then GET returns user-812.

This join pairs each of user 812’s bookings with its match title in one query. A key-value store cannot join; your code must fetch each match by its key and stitch the results together.

1. 1

   Pick an app

   A tiffin service in Nagpur: kitchen menus, paid orders, and the rider’s location every few seconds.

2. 2

   Write its top three queries

   One line each: what is read or written, by which key, how often.

3. 3

   Name a store for each

   Relational, key-value, document, wide-column or graph, with one reason from the access pattern.

4. 4

   Check your answer

   Menu: varied fields, so a document store. Order: exact and all or nothing, so SQL. Location: only the latest is read, so key-value. You pass if every reason says how the data is read or written.

Back in Baner, the answer is no: holds, payments and venues need different stores. Bookings and payments stay in SQL, where joins and transactions guard every rupee. Seat holds and sessions stay in Redis, where lesson 9 put them. Venue details go into a document store.

It is Rekha’s shop again: the register for money, the hook board for holds, the folder for venues. “Wait, so the answer was the access pattern,” Arjun says. Nothing moved because it was fashionable.

Then Zoya taps the board. “We are heading for 6 states. What happens at 10x?” At ten times the reads, even “My bookings” and the match pages would crush the one SQL server. Can the database be copied?