[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"academy-blogs-en-1-1-all-sql-vs-nosql-differences-all--*":3,"academy-blog-faqs-rglvgihv2qq5ufe-en":92,"academy-blog-translations-rglvgihv2qq5ufe":117},{"data":4,"page":91,"perPage":91,"totalItems":91,"totalPages":91},[5],{"alt":6,"collectionId":7,"collectionName":8,"content":9,"cover_image":10,"cover_image_l_url":11,"cover_image_m_url":12,"cover_image_path":13,"cover_image_s_url":14,"created":15,"created_by":16,"expand":17,"id":84,"keywords":85,"locale":54,"published_at":86,"scheduled_at":71,"school_blog":80,"short_description":87,"status":78,"title":88,"updated":89,"updated_by":90,"slug":81,"views":83},"Top-down photo of a wooden desk with a neat wooden card-index drawer of identical blank cards beside a loose stack of varied blank folders and envelopes, with an info card: SQL, tables + JOIN; NoSQL, one nested document; choose by the shape of your data","sclblg987654321","school_blog_translations","\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2>The same data, stored two ways\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>\u003Cstrong>Option 1: SQL (a relational database).\u003C\u002Fstrong> The data is split into separate tables linked by a Foreign Key, a column that points to a row in another table. The \u003Ccode>users\u003C\u002Fcode> table holds people, the \u003Ccode>orders\u003C\u002Fcode> table holds orders, and each order carries a \u003Ccode>user_id\u003C\u002Fcode> saying whose it is.\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-sql\">CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL);\nCREATE TABLE orders (\n  id INTEGER PRIMARY KEY,\n  user_id INTEGER NOT NULL REFERENCES users(id),\n  item TEXT,\n  total INTEGER\n);\nINSERT INTO users VALUES (1, 'Mint');\nINSERT INTO orders VALUES (101, 1, 'Keyboard', 1290), (102, 1, 'Mouse', 590);\n\nSELECT u.name, o.item, o.total\nFROM users u JOIN orders o ON o.user_id = u.id;\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>We ran this ourselves with \u003Ccode>sqlite3\u003C\u002Fcode> 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.\u003C\u002Fp>\u003Cpre>\u003Ccode>name  item      total\n----  --------  -----\nMint  Keyboard  1290\nMint  Mouse     590\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>\u003Cstrong>Option 2: a NoSQL document database (such as MongoDB).\u003C\u002Fstrong> 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.\u003C\u002Fp>\u003Cpre>\u003Ccode class=\"language-json\">{\n  \"_id\": 1,\n  \"name\": \"Mint\",\n  \"orders\": [\n    { \"orderId\": 101, \"item\": \"Keyboard\", \"total\": 1290 },\n    { \"orderId\": 102, \"item\": \"Mouse\", \"total\": 590 }\n  ]\n}\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>If the curly and square brackets still look unfamiliar, that is completely fine. Our \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fen\u002Fblogs\u002Fwhat-is-json-beginners-guide\">beginner's guide to JSON\u003C\u002Fa> covers the basics, and you can come straight back here afterwards.\u003C\u002Fp>\u003Cp>Same data. Different shape.\u003C\u002Fp>\u003Cp>SQL gives you tables + JOIN. NoSQL gives you one nested document. Every other difference in this article flows from that single point.\u003C\u002Fp>\u003Ch2>Schema: agree up front, or adjust later\u003C\u002Fh2>\u003Cp>A schema is the structure that says which fields each piece of data must have. In SQL you declare it before anything else, in \u003Ccode>CREATE TABLE\u003C\u002Fcode>. Every row in \u003Ccode>orders\u003C\u002Fcode> always has the same columns, and adding a new field means changing the table.\u003C\u002Fp>\u003Cp>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 \u003Ccode>FOREIGN KEY constraint failed\u003C\u002Fcode> 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 \u003Ccode>PRAGMA foreign_keys = ON;\u003C\u002Fcode> first, which we did for this test.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cblockquote>\u003Cp>Flexibility does not mean you stop thinking about structure. It moves that responsibility out of the database and into your code.\u003C\u002Fp>\u003C\u002Fblockquote>\u003Ch2>JOIN versus embedding\u003C\u002Fh2>\u003Cp>To find out what Mint ordered, SQL has to JOIN two tables, while the document model reads one document and has everything. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.mongodb.com\u002Fdocs\u002Fmanual\u002Fdata-modeling\u002F\">MongoDB's data modeling guide\u003C\u002Fa> 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.\u003C\u002Fp>\u003Cp>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 \u003Ccode>orders\u003C\u002Fcode> table that already holds every order in one place.\u003C\u002Fp>\u003Cp>MongoDB does not force you to embed, either. Its documentation says relationships can be modeled by embedding or by referencing, and the \u003Ccode>$lookup\u003C\u002Fcode> 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?\"\u003C\u002Fp>\u003Ch2>Is it true that NoSQL has no ACID?\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>SQL databases such as PostgreSQL and SQLite treat transactions as a basic feature (to see transaction handling in real code, read \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fen\u002Fblogs\u002Fjs2go-ep45-transaction-acid-go-vs-javascript-en\">JS2GO EP.45 on transactions and ACID in Go vs JavaScript\u003C\u002Fa>). For MongoDB, the \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.mongodb.com\u002Fdocs\u002Fmanual\u002Fcore\u002Ftransactions\u002F\">MongoDB transactions documentation\u003C\u002Fa> 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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2>NoSQL is more than MongoDB\u003C\u002Fh2>\u003Cp>NoSQL is an umbrella term for databases that do not store data as relational tables. \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.mongodb.com\u002Fresources\u002Fbasics\u002Fdatabases\u002Fnosql-explained\">MongoDB's NoSQL explainer\u003C\u002Fa> groups them into four main types:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>Document:\u003C\u002Fstrong> stores JSON-like documents, like Mint's example. MongoDB is one.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Key-value:\u003C\u002Fstrong> stores pairs of a unique key and a value, commonly used for caching and session management. Redis is a well-known example, and \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fen\u002Fblogs\u002Fjs2go-ep44-database-connection-sql-nosql-javascript-go\">JS2GO EP.44\u003C\u002Fa> shows connection code for it in both JavaScript and Go.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Wide-column:\u003C\u002Fstrong> uses tables, rows and columns, but each row can have its own set of columns. Apache Cassandra is an example.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Graph:\u003C\u002Fstrong> 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.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>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.\u003C\u002Fp>\u003Ch2>Can't PostgreSQL with JSONB do both?\u003C\u002Fh2>\u003Cp>Honestly, yes, and plenty of teams work this way. The \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.postgresql.org\u002Fdocs\u002Fcurrent\u002Fdatatype-json.html\">PostgreSQL documentation\u003C\u002Fa> explains that the \u003Ccode>jsonb\u003C\u002Fcode> type stores JSON in a decomposed binary format, is significantly faster to process than plain-text \u003Ccode>json\u003C\u002Fcode>, and supports indexing, including GIN indexes. The docs also recommend that most applications store JSON as \u003Ccode>jsonb\u003C\u002Fcode> rather than \u003Ccode>json\u003C\u002Fcode>.\u003C\u002Fp>\u003Cp>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 \u003Ccode>jsonb\u003C\u002Fcode> column.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Ch2>SQL vs NoSQL: when to use which\u003C\u002Fh2>\u003Cp>Choose by the shape of your data and how you read it, not by hype. Ask yourself three questions:\u003C\u002Fp>\u003Cul>\u003Cli>\u003Cp>\u003Cstrong>Is the data heavily related?\u003C\u002Fstrong> If users, orders, products and stock all reference each other and you need reports across many angles, SQL fits the job more directly.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Do you mostly read it in one piece?\u003C\u002Fstrong> If your main screen pulls one bundle of data at once, like a profile page with everything about one person, a document fits well.\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Cstrong>Does the shape change often?\u003C\u002Fstrong> If records genuinely have different fields, the flexibility of documents, or a JSONB column, will help.\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>\u003Cp>If you are just starting and cannot answer yet, we suggest learning SQL first, because tables, keys and JOINs carry over almost everywhere. Try \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fen\u002Fblogs\u002Fwrite-your-first-sql-query-beginners\">writing your first SQL query\u003C\u002Fa>, then move on to \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.superdevacademy.com\u002Fen\u002Fblogs\u002Fbasic-sql-for-web-developers\">the basic SQL every web developer should know\u003C\u002Fa>. 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.\u003C\u002Fp>\u003Cdiv data-type=\"horizontalRule\">\u003Chr>\u003C\u002Fdiv>\u003Ch2>Summary: what is the difference between SQL and NoSQL?\u003C\u002Fh2>\u003Cp>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.\u003C\u002Fp>\u003Cp>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.\u003C\u002Fp>\u003Cp>Follow more articles and tips for people starting out as programmers on our channels.\u003C\u002Fp>\u003Cp>Facebook: \u003Cstrong>Superdev Academy Thailand\u003C\u002Fstrong> — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.facebook.com\u002Fsuperdev.academy.th\">https:\u002F\u002Fwww.facebook.com\u002Fsuperdev.academy.th\u003C\u002Fa>\u003C\u002Fp>\u003Cp>YouTube: \u003Cstrong>Superdev Academy Channel\u003C\u002Fstrong> — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.youtube.com\u002F@SuperdevAcademy\">https:\u002F\u002Fwww.youtube.com\u002F@SuperdevAcademy\u003C\u002Fa>\u003C\u002Fp>\u003Cp>Instagram: \u003Cstrong>@superdevacademy\u003C\u002Fstrong> — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.instagram.com\u002Fsuperdevacademy\u002F\">https:\u002F\u002Fwww.instagram.com\u002Fsuperdevacademy\u002F\u003C\u002Fa>\u003C\u002Fp>\u003Cp>TikTok: \u003Cstrong>@superdevacademy\u003C\u002Fstrong> — \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fwww.tiktok.com\u002F@superdevacademy?lang=th-TH\">https:\u002F\u002Fwww.tiktok.com\u002F@superdevacademy?lang=th-TH\u003C\u002Fa>\u003C\u002Fp>","cover_cover_i5m8d2763i.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002Fql94fet64m5zyyj\u002Fl\u002Fcover_cover_i5m8d2763i.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002Fql94fet64m5zyyj\u002Fm\u002Fcover_cover_i5m8d2763i.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002Fql94fet64m5zyyj\u002Fcover_cover_i5m8d2763i.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclblg987654321\u002Fql94fet64m5zyyj\u002Fs\u002Fcover_cover_i5m8d2763i.webp","2026-09-30 06:15:04.257Z","wfztm6bp9384v3u",{"keywords":18,"locale":48,"school_blog":58},[19,25,29,33,36,40,44],{"collectionId":20,"collectionName":21,"created":22,"created_by":16,"id":23,"name":24,"updated":22,"updated_by":16},"sclkey987654321","school_keywords","2026-09-30 06:14:10.917Z","lq5grf5q484evo3","SQL vs NoSQL",{"collectionId":20,"collectionName":21,"created":26,"created_by":16,"id":27,"name":28,"updated":26,"updated_by":16},"2026-09-30 06:15:04.249Z","oxrrzah2erqlmvb","difference between sql and nosql",{"collectionId":20,"collectionName":21,"created":30,"created_by":16,"id":31,"name":32,"updated":30,"updated_by":16},"2026-09-30 06:15:04.250Z","hdiof2ji37yrk1q","sql vs nosql when to use",{"collectionId":20,"collectionName":21,"created":30,"created_by":16,"id":34,"name":35,"updated":30,"updated_by":16},"fa3dml5m2fiww2n","nosql database types",{"collectionId":20,"collectionName":21,"created":37,"created_by":16,"id":38,"name":39,"updated":37,"updated_by":16},"2026-09-30 06:15:04.251Z","siev663reu3u5sc","is mongodb nosql",{"collectionId":20,"collectionName":21,"created":41,"created_by":16,"id":42,"name":43,"updated":41,"updated_by":16},"2026-09-30 06:15:04.252Z","mmuth6h5mjlffbw","mongodb transactions",{"collectionId":20,"collectionName":21,"created":45,"created_by":16,"id":46,"name":47,"updated":45,"updated_by":16},"2026-09-30 06:15:04.253Z","6f96b77gifkrem3","postgresql jsonb vs mongodb",{"code":49,"collectionId":50,"collectionName":51,"created":52,"flag":53,"id":54,"is_default":55,"label":56,"updated":57},"en","pbc_1989393366","locales","2026-01-22 11:00:02.726Z","twemoji:flag-united-states","qv9c1llfov2d88z",false,"English","2026-04-10 15:42:46.825Z",{"category":59,"collectionId":60,"collectionName":61,"created":62,"expand":63,"id":80,"slug":81,"updated":82,"views":83},"spm4l1k5bgmhmmt","pbc_2105096300","school_blogs","2026-09-30 06:14:10.925Z",{"category":64},{"blogIds":65,"collectionId":66,"collectionName":67,"created":68,"created_by":69,"id":59,"image":70,"image_alt":71,"image_path":72,"image_s_url":73,"label":74,"name":75,"priority":76,"publish_at":77,"scheduled_at":71,"status":78,"updated":79,"updated_by":69},[],"sclcatblg987654321","school_category_blogs","2026-03-04 08:31:18.590Z","76qprkevbgfdps8","50hyjr6os45_ayazwr5gq7_tqzz9l5y5w.webp","","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclcatblg987654321\u002Fspm4l1k5bgmhmmt\u002F50hyjr6os45_ayazwr5gq7_tqzz9l5y5w.webp","https:\u002F\u002Ftwsme-r2.tumwebsme.com\u002Fsclcatblg987654321\u002Fspm4l1k5bgmhmmt\u002Fs\u002F50hyjr6os45_ayazwr5gq7_tqzz9l5y5w.webp",{"en":75,"th":75},"Knowledge",0,"2026-03-18 02:25:41.222Z","published","2026-08-18 14:49:11.737Z","rglvgihv2qq5ufe","sql-vs-nosql-differences","2026-10-23 08:04:17.376Z",102,"ql94fet64m5zyyj",[23,27,31,34,38,42,46],"2026-10-23 05:00:00.000Z","SQL vs NoSQL with one dataset: a user and two orders stored as tables + JOIN and as one MongoDB document, plus schema, ACID transactions and PostgreSQL JSONB.","SQL vs NoSQL: The Same Data Stored Two Ways, Explained","2026-10-23 05:00:01.108Z","ebkf8ra4nd55ual",1,[93,97,101,105,109,113],{"answer":94,"id":95,"question":96},"NoSQL is an umbrella term for databases that do not store data as relational tables the way SQL databases do. MongoDB's own explainer groups NoSQL into 4 main types: document, key-value, wide-column and graph. The type people usually mean is the document database, such as MongoDB, which keeps data that is read together in one JSON-like document instead of splitting it across tables combined with JOIN.","0jdgs7h4yzdtzmt","What is NoSQL, and how is it different from a table-based database?",{"answer":98,"id":99,"question":100},"MongoDB is a NoSQL document database, not a SQL database. Each record is stored as a JSON-like document, and documents in the same collection do not need to share the same set of fields. When related data lives in another collection, MongoDB's $lookup aggregation stage performs a left outer join to a collection in the same database.","42r4k68s7f05ch0","What is MongoDB, and is it SQL or NoSQL?",{"answer":102,"id":103,"question":104},"Document-style NoSQL suits applications that mostly read data as one piece and whose records have varying fields, such as a profile page that loads everything about one user at once. Key-value stores such as Redis are commonly used for caching and session management. When data is heavily related across many tables and needs reports from many angles, a SQL database usually fits better.","bnx2gdci6yvd3cq","What kinds of work is NoSQL best suited for?",{"answer":106,"id":107,"question":108},"Yes. A write to a single document in MongoDB is already atomic, and MongoDB added multi-document ACID transactions in version 4.0, which became generally available in June 2018 for replica sets. MongoDB's documentation still warns that multi-document transactions usually cost more performance than single-document writes and should not replace good schema design.","pehedebl6cn7e71","Does MongoDB support ACID transactions?",{"answer":110,"id":111,"question":112},"MySQL is a SQL database that stores data in tables defined by a schema up front and uses JOIN to combine data from several tables. MongoDB is a NoSQL document database that keeps data read together in one document with a more flexible schema. For one user with two orders, MySQL splits them into users and orders tables, while MongoDB embeds the orders as an array inside the user document.","jisk1y6sdxftzh3","What is the difference between MongoDB and MySQL?",{"answer":114,"id":115,"question":116},"In many cases, yes. PostgreSQL's jsonb type stores JSON in a decomposed binary format, is significantly faster to process than plain-text json, and supports GIN indexes. That lets you keep core data in tables with foreign keys and store variable-shaped data as jsonb in the same database. If almost all of your data is document-shaped, using MongoDB directly is still a reasonable choice.","p8nbgyzt2o4f120","Can PostgreSQL with JSONB replace MongoDB?",{"th":81,"en":81}]