Databases

SQL vs NoSQL databases

DatabasesData modellingDecision guide

Short answer

Choose SQL by default when relationships, constraints, and transactions matter. Choose NoSQL when the access pattern is known, the data can be modelled around it, and horizontal scale or flexible shape is the dominant constraint; “NoSQL” is not a substitute for designing consistency.

Written and reviewed by Sahil Srivastav

What each one actually is

SQL databases store related data in tables with a declared schema and expose joins, constraints, and transactions. PostgreSQL and MySQL are typical choices: the database can enforce uniqueness and foreign keys rather than trusting every caller.

NoSQL describes several families, not one design: document, key-value, wide-column, and graph stores make different trade-offs. Most favour denormalised records and a small set of predictable access paths over arbitrary joins.

The boundary is not “structured versus unstructured”. Both can store structured data. It is whether the database should resolve relationships and invariants for you, or whether the application owns that work to gain a different scaling or latency profile.

Side by side

	SQL databases	NoSQL databases
Relationships	Joins and foreign keys are first-class	Usually denormalise or join in application code
Transactions	Multi-row ACID transactions are standard	Often atomic per item; multi-item scope varies
Schema changes	Explicit migrations and constraints	Flexible records, but validation still belongs somewhere
Query shape	Ad hoc filtering and aggregation are strong	Fastest when queries match the designed key/index
Consistency	Strong transactional semantics are familiar	May offer tunable or eventual consistency
Scaling model	Vertical scale plus replicas and partitioning	Many products start with horizontal distribution
Operational failure	Lock contention and slow plans need control	Hot keys, fan-out, and partition skew need control
Reporting	Aggregations and joins stay close to data	Often needs materialised views or a separate warehouse

Choose SQL databases when

Payments, inventory, or permissions need database-enforced invariants
The domain has many-to-many relationships or reporting queries you cannot predict
A team wants one authoritative store and well-understood backups and migrations
Correctness under concurrent writes matters more than schema flexibility

Choose NoSQL databases when

The primary access keys and document shape are known in advance
A very large workload needs partitioning by tenant, key, or time from the start
Records vary substantially and aggregate transactions are not required
A product can tolerate or explicitly model eventual consistency

The trade-off in detail

Denormalisation moves cost from reads to writes. When a customer name is copied into a thousand documents, a rename becomes a consistency problem; a SQL join would have kept one source of truth. If you choose a document store, write down which copy is authoritative and how repairs run.

A NoSQL service can still have strict transactions, and a SQL database can still be distributed. Product labels hide the actual contract, so inspect transaction scope, read guarantees, partition behaviour, and failover rather than assuming from the category.

The most expensive migration is choosing NoSQL to avoid learning relational modelling, then rebuilding joins, uniqueness, and reporting in application code. Conversely, forcing every event and high-volume key lookup into a single relational schema can create operational pressure that a purpose-built store would avoid.

Things that are commonly said and are wrong

“NoSQL has no schema.” It has an implicit schema in readers, indexes, validators, and old records; it is simply less centrally declared.
“SQL cannot scale horizontally.” Read replicas, partitioning, sharding, and distributed SQL all exist, with coordination costs that must be measured.
“ACID means slow and eventual means fast.” Latency depends on indexes, contention, topology, and workload; consistency is a contract, not a speed setting.

Decide it in a real repository

Choosing correctly on a whiteboard and enforcing the choice in code are different skills. Gronex ships broken backend repositories whose tests assert the invariant, not the happy path.

FAQ

Should a new application start with SQL?

Usually yes. SQL gives relationships, constraints, transactions, and flexible queries while the domain is still changing. Move a measured hot path to another store when its access pattern and scaling need justify the added operational model.

Can SQL and NoSQL be used together?

Yes. Keep ownership clear: for example, SQL can be authoritative for orders while a document or key-value store serves a read model. An asynchronous projection needs replay, lag monitoring, and a repair path.

Is JSON in PostgreSQL the same as NoSQL?

No. JSON columns add flexible values inside a relational engine; you still have SQL transactions, indexes, and relational tables around them. It can be a useful compromise when only part of the shape varies.