SQL vs NoSQL · Product Fluency

SQL vs NoSQL · 3 min

Situation

“Should we switch to NoSQL to scale?”

A product has slow order reports. Someone proposes a new database category. Before discussing migration, ask which queries are slow, how much data they examine, and what the business needs to remain consistent.

A category label does not diagnose an inefficient query or prove the need for a different architecture.

Mental model

Different work favors different storage patterns.

Relational systems commonly support tables, joins, constraints, and transactions queried with SQL. NoSQL covers several families, including document, key-value, and graph databases.

These are broad categories with overlapping capabilities. Relational databases can scale and store flexible data; some NoSQL systems support transactions. Evaluate the actual system, not a slogan.

Example

Orders and session lookups have different needs.

Orders, payments, and refunds often require clear relationships and careful consistency. A session lookup may primarily need a fast read by a known key with an expiry time.

An activity feed may prioritize high write volume and a predictable reading pattern. One product can use several storage systems, but each addition creates operational and synchronization work.

Failure case

Optimizing writes while forgetting reads.

A flexible document shape can make new data easy to write. If the product later needs cross-customer reporting, the team may need new indexes, transformations, or a separate analysis pipeline.

Ask how the data will be queried, updated, deleted, and audited over time. Flexibility in one operation can move complexity to another.

PM question

What must be true when the user acts?

Does a user need to see a write immediately? Can a report lag by an hour? Must two changes succeed together? What volume and response time are expected?

These requirements help engineers evaluate storage choices. Also ask whether indexing or query changes can solve the current problem before funding a migration.

Remember this

Describe the workload before choosing a category.

A PM contributes access patterns, consistency needs, growth assumptions, and acceptable delays. Engineering translates those constraints into an appropriate storage design.