SQL vs NoSQL: The Same Data Stored Two Ways, Explained

Anyone about to start a first project gets pulled between two camps. One insists "NoSQL is faster" and more modern. The other insists "SQL is the standard": safer, and everyone uses it anyway. Search for whether your first project should use SQL or NoSQL and the answers online tend to split exactly along that line. You finish reading both and still cannot decide, because neither camp puts real data on the table.

So today Superdev Academy will do exactly that. We take one small dataset, a single user with two orders, and store it twice: once as SQL tables and once as a NoSQL document. Then we look at where the differences actually come from, and how to choose for your own project.

In short: SQL stores data in tables with a schema declared up front and reassembles it with JOIN, while a NoSQL document database keeps data that is read together in one document, with a more flexible schema.

The same data, stored two ways

The scenario is deliberately tiny. A user named Mint has placed two orders: a Keyboard and a Mouse. Each order has its own ID and total.

Option 1: SQL (a relational database). The data is split into separate tables linked by a Foreign Key, a column that points to a row in another table. The users table holds people, the orders table holds orders, and each order carries a user_id saying whose it is.

CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);
CREATE TABLE orders (
  id INTEGER PRIMARY KEY,
  user_id INTEGER NOT NULL REFERENCES users(id),
  item TEXT,
  total INTEGER
);
INSERT INTO users VALUES (1, 'Mint');
INSERT INTO orders VALUES (101, 1, 'Keyboard', 1290), (102, 1, 'Mouse', 590);

SELECT u.name, o.item, o.total
FROM users u JOIN orders o ON o.user_id = u.id;

We ran this ourselves with sqlite3 version 3.43.2. The result is two rows, and the name Mint appears in both, because a JOIN (combining two tables on a matching condition) reassembles data that was stored apart into a single view at read time.

name  item      total
----  --------  -----
Mint  Keyboard  1290
Mint  Mouse     590

Option 2: a NoSQL document database (such as MongoDB). Everything about Mint lives in one nested document, with the orders embedded as an array inside it. It looks just like the JSON you may have seen before.

{
  "_id": 1,
  "name": "Mint",
  "orders": [
    { "orderId": 101, "item": "Keyboard", "total": 1290 },
    { "orderId": 102, "item": "Mouse", "total": 590 }
  ]
}

If the curly and square brackets still look unfamiliar, that is completely fine. Our beginner's guide to JSON covers the basics, and you can come straight back here afterwards.

Same data. Different shape.

SQL gives you tables + JOIN. NoSQL gives you one nested document. Every other difference in this article flows from that single point.

Schema: agree up front, or adjust later

A schema is the structure that says which fields each piece of data must have. In SQL you declare it before anything else, in CREATE TABLE. Every row in orders always has the same columns, and adding a new field means changing the table.

The upside of that strictness showed up the moment we tried to insert an order for user 99, who does not exist. The database refused immediately with FOREIGN KEY constraint failed and saved nothing. Orphaned data like that simply cannot get in. One detail worth knowing: SQLite ships with foreign key checks switched off by default, so you have to run PRAGMA foreign_keys = ON; first, which we did for this test.

On the MongoDB side, MongoDB's documentation explains that documents in the same collection (a group of documents, roughly what a table is in SQL) do not need to share the same set of fields, and the same field can even hold different data types in different documents. Put simply, if some orders suddenly need a "coupon" field, you add it to those documents without touching any structure.

Flexibility does not mean you stop thinking about structure. It moves that responsibility out of the database and into your code.

JOIN versus embedding

To find out what Mint ordered, SQL has to JOIN two tables, while the document model reads one document and has everything. MongoDB's data modeling guide states the principle directly: data that is accessed together should be stored together. It adds that embedding lets you avoid complex joins across multiple collections.

Embedding has a cost, though. Imagine Mint has placed several thousand orders: that one document keeps growing. Or imagine a report asking "how many Keyboards did we sell across all customers?" Orders buried inside each user's document are harder to pull out than rows in a single orders table that already holds every order in one place.

MongoDB does not force you to embed, either. Its documentation says relationships can be modeled by embedding or by referencing, and the $lookup stage performs a left outer join to another collection in the same database. So the useful question is not "which one can JOIN?" It is "how does my application read this data most of the time?"

Is it true that NoSQL has no ACID?

This belief is still everywhere. ACID is the set of properties that makes sure a transaction, a group of writes that must all succeed or all fail together, never leaves data half-done. The classic example is a bank transfer: money leaves one account and must arrive in the other. If the second step fails, the first must be undone too.

SQL databases such as PostgreSQL and SQLite treat transactions as a basic feature (to see transaction handling in real code, read JS2GO EP.45 on transactions and ACID in Go vs JavaScript). For MongoDB, the MongoDB transactions documentation states that an operation on a single document is atomic, and MongoDB introduced multi-document ACID transactions in version 4.0, which became generally available in June 2018 for replica sets.

The interesting part is MongoDB's own warning: a multi-document transaction usually costs more performance than a single-document write, and it should not replace good schema design. That is exactly why the example above embeds the orders inside the user document. Updating the user together with their orders becomes a single-document write, with no transaction needed.

So "NoSQL has no ACID" is wrong. The accurate version is that each database is designed differently, and you should read the documentation of the one you plan to use.

NoSQL is more than MongoDB

NoSQL is an umbrella term for databases that do not store data as relational tables. MongoDB's NoSQL explainer groups them into four main types:

• Document: stores JSON-like documents, like Mint's example. MongoDB is one.

• Key-value: stores pairs of a unique key and a value, commonly used for caching and session management. Redis is a well-known example, and JS2GO EP.44 shows connection code for it in both JavaScript and Go.

• Wide-column: uses tables, rows and columns, but each row can have its own set of columns. Apache Cassandra is an example.

• Graph: stores nodes and edges, suited to data where the relationships are the point, such as a network of friends. Neo4j is the name most people know.

So when someone compares "SQL vs NoSQL", they are usually comparing SQL with a document database like MongoDB, which is only one of the four types.

Can't PostgreSQL with JSONB do both?

Honestly, yes, and plenty of teams work this way. The PostgreSQL documentation explains that the jsonb type stores JSON in a decomposed binary format, is significantly faster to process than plain-text json, and supports indexing, including GIN indexes. The docs also recommend that most applications store JSON as jsonb rather than json.

That means you can keep your core data, users and orders, in tables with foreign keys guarding against orphaned rows, and store the parts whose shape varies, such as product details that differ by category, in a single jsonb column.

JSONB does not turn PostgreSQL into MongoDB, though. If almost all of your data is document-shaped and your team wants to work with a document model end to end, a document database is still a sensible choice. The point is that the line between SQL and NoSQL is far less sharp than it used to be.

SQL vs NoSQL: when to use which

Choose by the shape of your data and how you read it, not by hype. Ask yourself three questions:

• Is the data heavily related? If users, orders, products and stock all reference each other and you need reports across many angles, SQL fits the job more directly.

• Do you mostly read it in one piece? If your main screen pulls one bundle of data at once, like a profile page with everything about one person, a document fits well.

• Does the shape change often? If records genuinely have different fields, the flexibility of documents, or a JSONB column, will help.

If you are just starting and cannot answer yet, we suggest learning SQL first, because tables, keys and JOINs carry over almost everywhere. Try writing your first SQL query, then move on to the basic SQL every web developer should know. Once you understand what splitting data into tables solves, you will see for yourself where embedding in a document helps, and what it trades away.

Summary: what is the difference between SQL and NoSQL?

The core difference is the shape of your data. SQL stores it in tables with a schema declared up front, splitting data across tables and reassembling it with JOIN. A NoSQL document database like MongoDB keeps data that is read together in one document, with a more flexible schema. Both sides offer ACID transactions, and PostgreSQL can store JSON through JSONB, so the dividing line is not about which one is more modern.

Take the project you are about to build, write out two or three sample records the way we did with Mint, once as tables and once as a document, and ask how your most-used screen needs to read them. That answer will be clearer than another ten comparison articles.

Follow more articles and tips for people starting out as programmers on our channels.

Facebook: Superdev Academy Thailand — https://www.facebook.com/superdev.academy.th

YouTube: Superdev Academy Channel — https://www.youtube.com/@SuperdevAcademy

Instagram: @superdevacademy — https://www.instagram.com/superdevacademy/

TikTok: @superdevacademy — https://www.tiktok.com/@superdevacademy?lang=th-TH