What is the difference between SQL and NoSQL databases?

SQL databases store data in tables with a fixed schema and relationships between them; NoSQL databases store flexible documents or key-value pairs with no enforced structure. The trade-off is guarantees and consistency versus flexibility and certain kinds of scale. SQL (Postgres, MySQL, SQLite): - Data lives in tables with defined columns and types. A row must match the schema. - Relationships are first-class: a user has many orders, an order has many items, and the database enforces that an order can't reference a user who doesn't exist. - Powerful querying — joins let you answer complex questions across tables in one query. - Transactions with strong guarantees: several changes either all succeed or all fail. Essential for money, inventory, bookings. - Cost: you must design the schema up front, and changing it later requires migrations. NoSQL (MongoDB, DynamoDB, Firestore, Redis): - Data lives as documents (JSON-like) or key-value pairs. Different records can have different fields. - No enforced schema, so you can change shape freely as requirements shift. - Horizontal scaling across many servers is generally easier and was the original motivation. - Cost: no joins (you either duplicate data or make multiple queries), weaker consistency guarantees by default, and the flexibility means your application code becomes responsible for data integrity — which in practice means bugs where half your documents have `email` and half have `emailAddress`. How to actually choose, and the honest default: **for most projects, use Postgres.** The 'NoSQL scales, SQL doesn't' framing is roughly a decade out of date — modern Postgres handles very large workloads, supports JSON columns when you genuinely need flexible fields, and gives you relational integrity for free. Most applications have relational data (users, orders, comments, permissions), and discovering that after choosing a document store is a painful migration. Choose NoSQL when you have a specific reason: - Genuinely schema-less or wildly varying data (event logs, IoT readings, user-generated content of unpredictable shape). - Extreme write throughput or scale where horizontal sharding is the design constraint. - Caching or ephemeral data — Redis for sessions and caches is an excellent fit and complements a SQL database rather than replacing it. - Real-time sync features where something like Firestore does the hard part for you. The question to ask about your own project: does my data have relationships I'd want the database to enforce? If yes — which is most of the time — SQL. The flexibility of NoSQL is a real benefit early and a real liability once several developers and a year of accumulated data are involved.