SQL vs NoSQL

Short answer: start with a relational database. PostgreSQL is the right default for the overwhelming majority of applications, including most that people reach for NoSQL to build. Choose NoSQL when you have a specific, identified reason — a data model that genuinely doesn't fit tables, write volume beyond what one primary can handle, or a latency requirement a relational database can't meet.

That recommendation is stronger now than it was a decade ago, because the distinction has eroded from both directions. PostgreSQL has JSONB with indexing, so "we need flexible schemas" no longer requires a document store. And most NoSQL databases have added transactions, secondary indexes, and SQL-like query languages, so the original tradeoffs are much softer.

The honest framing: "SQL vs NoSQL" is a false binary. SQL is a query language; NoSQL is a category containing four fundamentally different kinds of database that have little in common with each other. The real question is which data model fits your access patterns.

TL;DR

Head-to-Head

The Four Kinds of NoSQL

Grouping these together is the main source of confusion. They solve unrelated problems.

A team saying "we're using NoSQL" has told you almost nothing. Redis and Neo4j are both NoSQL and have nothing in common.

Where Relational Wins

Query flexibility you don't have to plan for

This is the single largest practical advantage. In a document or wide-column store, a query like this either requires a pre-built index and denormalization designed in advance, or it isn't possible without exporting to an analytics system. Relational databases let you ask questions you hadn't thought of.

Transactions across entities

ACID transactions spanning arbitrary rows and tables are what let you not write reconciliation code. Many NoSQL stores now offer transactions, and often with meaningful constraints — single partition, single document, or a performance cost sharp enough that you avoid them.

Integrity enforced by the database

Constraints, foreign keys, and types are enforced for every writer — the application, a migration, a script, an analyst with psql. In a schemaless store, integrity is whatever every piece of code that ever writes remembers to enforce, forever. In practice that means a production dataset containing three different shapes of the same document, and code with defensive branches for each.

Flexible schemas, without leaving relational

You get document flexibility for the parts that need it, relational guarantees for the parts that don't, joins between them, and one database to operate. See PostgreSQL JSONB.

Where NoSQL Wins

Horizontal write scaling

A single relational primary accepts all writes. That ceiling is high — a well-tuned PostgreSQL instance on modern hardware handles tens of thousands of writes per second — and it is a ceiling. Past it you need sharding, which is real work and gives up cross-shard joins and transactions.

Cassandra and DynamoDB partition by design. Adding capacity is adding nodes, with no application-level sharding logic. If you are genuinely write-bound at that scale, this is decisive.

The honest caveat: most applications never approach this ceiling. Choosing a distributed store for a write volume you don't have means paying the query-flexibility cost for nothing.

Predictable single-key latency at any scale

For a session store, a user profile lookup, a shopping cart, or a feature flag — always by key, never a scan — a key-value store gives flat latency that doesn't degrade with data volume. Redis does this in microseconds.

Data models that genuinely aren't tabular

Recursive graph traversals, high-dimensional vector search, and full-text relevance ranking are cases where the specialized store is genuinely better. Note that PostgreSQL covers a surprising amount of this too — recursive CTEs, pgvector, and full-text search — well enough that a separate system is often unnecessary at moderate scale.

Massive time-series and append-only workloads

Event logs, IoT telemetry, and metrics with enormous write volume and time-bounded queries suit wide-column stores. Though again: TimescaleDB and ClickHouse handle this well, and ClickHouse speaks SQL.

The Decision Framework

The pattern worth noticing: several of the reasons resolve back to PostgreSQL with an extension, and the rest usually mean adding a specialized store alongside a relational source of truth rather than replacing it.

Polyglot persistence

This is what most mature systems actually look like: one relational database owning the authoritative data, with specialized stores fed from it for specific access patterns. Each additional store costs operational burden and a synchronization problem (CDC is the usual answer), so add them when a need is demonstrated, not preemptively.

Best Practices

Default to PostgreSQL and require justification to deviate

It handles relational, document, time-series, full-text, geospatial, and vector workloads competently. The burden of proof should sit with the alternative, and the justification should include a number.

Reach for JSONB before a document store

If the requirement is "some fields vary by record," that's a jsonb column with a GIN index. You keep joins, transactions, constraints on the structured columns, and one database to run.

Verify the scale claim with arithmetic

"We'll have millions of users" is not a write-throughput number. Compute expected writes per second at your forecast, compare against a benchmark of your candidate schema, and see whether one primary actually falls short. It usually doesn't. See Capacity Planning.

Model access patterns first if you do choose NoSQL

Document and wide-column stores require the queries to be known before the schema is designed — the partition key is the query plan. Getting this wrong means a migration, not an index. Write out every query before designing the key structure.

Use a key-value store as a cache, not as the source of truth

Redis alongside PostgreSQL is one of the most common and effective architectures. Redis as your only database means no durable guarantees on data you can't recreate.

Exhaust vertical scaling before distributing

A single database on a large instance goes remarkably far, and it keeps joins, transactions, and ad-hoc queries. Distributing is a one-way door that changes how you write every query. Sharding is the tool of last resort, not first.

Don't run more databases than you can operate

Every store needs monitoring, backups, tested restores, upgrades, capacity planning, and someone who understands its failure modes. A three-database architecture on a four-person team is usually a mistake.

Common Mistakes

Choosing NoSQL for scale you don't have

Using a document store because the schema is uncertain

Treating Redis as a database

Denormalizing in a relational database "for performance"

Assuming NoSQL means no schema

Adding a specialized store without a sync strategy

FAQ

Is SQL or NoSQL faster?

Neither, in general — it depends entirely on the operation. A single-key lookup in Redis is microseconds and PostgreSQL is a fraction of a millisecond; both are fast enough for almost anything. A five-table join is fast in PostgreSQL and either slow or impossible in a document store. An aggregate over a billion rows favors ClickHouse over both. "Faster" only means something once you name the query.

Can PostgreSQL replace MongoDB?

For most use cases, yes. JSONB gives you nested documents with GIN indexing and rich containment queries, plus joins, transactions, and constraints where you want them. What MongoDB still offers is easier built-in horizontal sharding and a developer experience some teams prefer. If you're choosing today and don't have a sharding requirement, PostgreSQL is the safer pick.

When do I actually need to shard?

When a single primary can no longer absorb your write volume, or your dataset exceeds what one machine can store or keep in cache — and you've already exhausted read replicas, connection pooling, query optimization, and vertical scaling. That threshold is much higher than most teams assume. See Database Sharding.

Do NoSQL databases support ACID now?

Many support transactions with caveats worth reading carefully. MongoDB has multi-document transactions with performance costs; DynamoDB has transactions limited in item count and scope; Cassandra has lightweight transactions using Paxos, which are markedly slower than normal writes. They're real and they're generally not as cheap or as unrestricted as a relational transaction. If transactions across entities are central to your domain, that's an argument for relational.

What about "NewSQL" and distributed SQL?

CockroachDB, Google Spanner, TiDB, and Yugabyte aim to give you SQL, ACID transactions, and horizontal scaling together — genuinely closing much of the gap. The costs are higher write latency (distributed consensus per commit), operational complexity, and less mature ecosystems than PostgreSQL. They're a strong option if you know you need horizontal scale and relational semantics, and overkill otherwise.

Which should I learn first?

SQL, without question. It's a transferable skill across PostgreSQL, MySQL, SQL Server, SQLite, ClickHouse, Trino, Spark, and most data tooling — and it's expected in essentially every backend and data role. NoSQL skills are more per-database and less portable. Learn SQL properly, then learn whichever NoSQL store your work requires.

Related Topics

References