SQL vs NoSQL

Basic System Design

≈ 2 min read

This is not a choice between “old” and “new”

The terms SQL and NoSQL describe different storage families and data models. SQL databases are usually built around the relational model and the SQL language. NoSQL groups several different approaches: key-value, document, wide-column, and others.

So the right question is not “which is better?” but which model matches the system's data and operations.

When the relational model is natural

A relational database is convenient when data has a clear structure, entities have relationships, and the integrity of several changes matters as one unit.

users  -> orders -> order_items
   \         |
    \        v
     +---- payments

SQL makes it possible to filter, aggregate, and join data flexibly. This is especially valuable when you cannot list every future query shape in advance.

When a specialized NoSQL model is useful

A NoSQL store is often chosen when data access is simple and predictable, data is naturally stored as aggregates, or a model optimized for a specific workload is needed.

For example, a key-value store is convenient for access by key, a document database for objects with nested structure, and a wide-column approach can fit large distributed datasets with known read patterns.

Scaling does not split the world in two

You should not assume that SQL “does not scale” while NoSQL automatically solves any large workload. Modern relational databases use replication, partitioning, and distributed variants, and NoSQL systems also have limits and their own trade-offs.

The difference is primarily in the data model, supported operations, guarantees, and operational complexity. Scale is only one part of the requirements.

NoSQL does not mean no schema. Even if a database does not require a rigid table schema, the application still needs to understand the structure of documents, keys, and fields and evolve it safely over time.

One system can use both approaches

You do not have to choose one database type for the whole product. Orders can live in a relational database, user sessions in a key-value store, and large files in object storage. This separation is called polyglot persistence.

It is useful only when the advantages of multiple stores justify the extra complexity of operations and data coordination.

Back Next