SQL vs NoSQL: choosing a database without the folklore

"SQL or NoSQL?" is usually asked as if it were a matter of taste or scale. It is neither. It is a question about how your data is shaped and how you will read it.

Start from the questions you will ask

Before comparing products, write down the ten most important questions the application must answer. "Show this customer's orders with line items and current stock." "Total revenue by region last quarter." "Find every document mentioning this phrase."

Those questions decide the store far more reliably than any benchmark.

Why relational is the sensible default

A relational database such as PostgreSQL gives you things that are expensive to rebuild later:

• Joins and constraints. Foreign keys, unique constraints and check constraints make whole classes of bugs impossible rather than merely unlikely.
• Transactions. Moving money between two accounts, or reserving stock while creating an order, either all happens or none of it does.
• Flexible queries. Requirements change. A relational model lets you ask questions you did not plan for, without redesigning storage.
• A mature ecosystem. Tooling, hiring, backups, replication and monitoring are well understood.

Modern PostgreSQL also handles semi-structured data well through JSON columns, so "we need flexible fields" is rarely a reason to leave.

Where NoSQL genuinely earns its place

• Document stores (MongoDB and similar) fit data that is naturally read and written as one self-contained unit, with varied shape between records and few cross-document relationships. A content system with very different block types per page is a reasonable example.
• Key-value stores (Redis) fit caching, sessions, rate limiting, queues and leaderboards, where speed and simple access by key matter more than querying.
• Search engines (Elasticsearch and similar) fit full-text search, relevance ranking and faceted filtering, which relational databases do poorly at scale.
• Wide-column and time-series stores fit very high write volumes of append-only data, such as telemetry.

Notice that most of these are additions to a primary relational store, not replacements for it.

The expensive mistake

The common failure is choosing a document database because the first screens look like documents, then discovering six months later that the product needs reporting, relationships between entities and consistent updates across them. The team ends up reimplementing joins and transactions in application code, badly, and migrating later under pressure.

A related mistake is the opposite: forcing high-volume event data or free-text search into relational tables because "we already have a database". That works until it does not.

A practical way to decide

1. Default to PostgreSQL for the system of record.
2. Add Redis when you have a caching or ephemeral-state problem you can name.
3. Add a search engine when users need real search, not just filters.
4. Reach for a document or time-series store only when you can point to a specific access pattern the relational model handles poorly — and be able to say what you lose.

Every additional datastore is something to back up, secure, monitor, upgrade and keep consistent with the others. The best database architecture is usually the one with the fewest moving parts that still answers your questions.

What to take away

Choose by access pattern, not by fashion. Prefer the boring default until a concrete problem argues otherwise, and treat a second datastore as a cost you are paying for a specific benefit.