SQL vs NoSQL
Two different ways to think about data. Neither wins. They are built for different jobs.
SQL. Tables with a fixed shape
SQL databases are also called relational databases. They organize data into tables with set columns. Every row has the same shape. The shape is enforced by a schema.
A users table has columns like id, email, and created_at. Every row fills in those columns. Adding a new column means running a schema change.
Tables can have relationships to each other. An orders table can point at users.id. You can run queries that join tables together. "Give me every order from users in California."
Common SQL databases are PostgreSQL, MySQL, SQL Server, and Oracle. They all speak SQL, which stands for Structured Query Language. It is a 50 year old standard that has aged well.
SQL's big power. Transactions
SQL databases support what people call ACID transactions. The short version is this. You can group several writes together so that either all of them happen, or none of them do.
Picture moving $100 from Alice to Bob. There are two writes. Take money from Alice. Give it to Bob. With a transaction, the database guarantees both writes succeed together or both fail together. There is no halfway state where Alice loses money but Bob never gets it.
This matters a lot anywhere data correctness counts. Banking. Online orders. Inventory. Anything you would be embarrassed to corrupt. SQL is built for this. Most NoSQL stores are not, or only support it with caveats.
NoSQL. Many shapes for many jobs
NoSQL stands for "not only SQL." It is a family of databases that gave up some of SQL's strictness to specialize for certain jobs. There is no one NoSQL. There are several kinds.
Document stores like MongoDB and DynamoDB hold JSON-like objects. Every document can have a different shape. Good for content with messy structure. A "Post" might have likes, replies, attachments, and polls all on the same record.
Key-value stores like Redis are just get and set by key. Very fast. Good for sessions, caches, and simple lookups.
Column stores like Cassandra and BigQuery are built for huge analytical queries that scan many rows but few columns. Good for time series, logs, and analytics.
Graph databases like Neo4j are built for following relationships. "Friends of friends" type queries. Good for social networks and recommendations.
Why NoSQL exists
Most NoSQL databases were born in the 2000s and 2010s. Google, Amazon, and Facebook needed to scale to petabytes and millions of writes per second. The SQL databases of that era struggled.
NoSQL traded features for scale. It dropped joins and transactions. It gained easy horizontal scaling and high write speed. Many NoSQL databases are built to be split across hundreds of machines by default.
Today, SQL has caught up a lot. Modern Postgres scales to terabytes. It supports JSON columns. Distributed SQL options like CockroachDB and Yugabyte exist. And NoSQL has added back features it once dropped. MongoDB has transactions. DynamoDB has ACID support.
The choice is less about scale today. It is more about the shape of your data.
How to choose
Pick SQL when your data has clear relationships, like orders to users or posts to comments. When you need transactions, like money, inventory, or anything that has to be correct. When you do not yet know all the queries you will need. Joins let you answer questions you have not thought of yet. When you are building most apps. SQL is the safe default.
Pick NoSQL when your records have very different shapes and you do not want to fight schemas. When you have huge write volume and need to shard from day one. When you have a specific access pattern. Key-value for cache-style lookups. Columnar for time series. Graph for heavy relationship work.
Many real systems use both. SQL for the core transactional data. NoSQL for caching, sessions, and analytics.
The interview answer for "SQL or NoSQL" is almost always "SQL by default. NoSQL where it specifically helps."