EDITED
"Should we use SQL or NoSQL?" is one of the most common architecture questions we get from clients, and it doesn't have a universal answer — because the two models were built to solve genuinely different problems, not to be a "modern vs old" choice.
SQL: structure and relationships
Relational databases (PostgreSQL, MySQL) organize data into tables with a fixed schema, and are built around relationships between tables — a customer has many orders, an order has many line items. They enforce data integrity through constraints, and support complex queries that join across multiple tables in a single, consistent operation.
SQL tends to fit best when:
Your data has clear, stable relationships (e-commerce orders, accounting, inventory).
Data integrity and consistency matter a lot — you genuinely cannot afford a half-completed transaction.
You need complex queries across multiple related entities.
NoSQL: flexibility and scale
NoSQL is an umbrella term covering several different models — document stores (MongoDB), key-value stores (Redis), wide-column stores, and graph databases — but the common thread is a more flexible schema and, for many of them, an easier path to horizontal scaling across many servers.
NoSQL (especially document stores) tends to fit best when:
Your data's shape varies between records or evolves quickly (content management, product catalogs with wildly different attributes per category).
You need to scale horizontally across many servers more easily than most relational setups allow.
Your access patterns are mostly "fetch this whole document," rather than complex multi-table joins.
What we actually use, and why
For this site's blog and portfolio content, we use MongoDB — the content is document-shaped (a post is naturally one self-contained object with a flexible set of fields), and there's no need for complex relational joins across many tables. For a client's e-commerce order and inventory system, we'd lean relational, precisely because that data is deeply relational and consistency genuinely matters.
The right database follows the shape of your data and your access patterns — not the other way around, and definitely not just whichever one is trending.
It's rarely all-or-nothing
Plenty of real systems use both: a relational database for core transactional data, alongside a document store or key-value cache for a specific use case that fits it better (session storage, search indexes, flexible content). Choosing per-need, rather than picking one database technology for an entire system, is often the right call.