SQL vs NoSQL: Which Database Should You Choose in 2026?

Every engineering team eventually has the SQL vs NoSQL argument. Someone proposes MongoDB because schemas feel slow. Someone else insists Postgres can do everything. A third person mentions DynamoDB because it is what their last startup used. Half the room has strong opinions and half the room has no idea which side they should be on.

In 2026 the debate is different than it was a decade ago. Postgres has JSON columns that match most document database workloads. MongoDB added full multi-document ACID transactions. DynamoDB supports transactions and consistent reads. NewSQL databases like CockroachDB and Spanner deliver relational semantics at horizontal scale. The boundary between "SQL" and "NoSQL" has blurred so much that picking based on label alone is a mistake.

This guide rebuilds the decision from first principles. We will cover where SQL came from (Codd, 1970) and where NoSQL came from (Google Bigtable and Amazon Dynamo papers, 2006-2007), the real differences in data model and consistency, the CAP theorem and what it actually means, the four NoSQL families you should know, when each is the right choice, how the biggest companies use them (Netflix, GitHub, Notion, Twitter), and what NewSQL changes. By the end you will pick based on workload, not vibes.

Relational databases were invented in 1970 when Edgar F. Codd published "A Relational Model of Data for Large Shared Data Banks." Codd's insight was that data should be organized as sets of tuples (rows) in relations (tables) and manipulated using set-theoretic operations (the relational algebra), not navigated through pointers and records the way the hierarchical and network databases of the 1960s did. SQL followed in the mid-1970s at IBM and became an ANSI standard in 1986. Oracle, DB2, Postgres, MySQL, and SQL Server all trace back to this lineage.

For 30 years SQL was uncontested. Then the web happened. By the mid-2000s, Google and Amazon were running workloads that did not fit a single machine. Two papers changed everything: Bigtable (Google, 2006) introduced a distributed wide-column store, and Dynamo (Amazon, 2007) introduced an always-available, eventually-consistent key-value store. These papers inspired a generation of databases that threw out one or more SQL assumptions to gain horizontal scalability: HBase, Cassandra, Riak, CouchDB, MongoDB, Redis, Neo4j, and eventually DynamoDB itself as a managed service.

The term NoSQL was coined in 2009 at a San Francisco meetup. It was never a coherent category. It just meant "not the relational databases you know," and it bundled together wildly different designs. The label stuck anyway. Today NoSQL usually refers to four families: document, key-value, wide-column, and graph.

SQL databases organize data as tables with fixed columns, enforce a schema, support joins across tables, and provide ACID transactions. ACID means Atomicity (a transaction is all-or-nothing), Consistency (data always satisfies constraints), Isolation (concurrent transactions do not interfere), and Durability (committed data survives crashes).

The power of SQL comes from three things. First, the schema forces you to think about your data shape upfront, catching many bugs at write time. Second, joins let you compose data across tables without denormalization, keeping storage lean. Third, the query planner optimizes your declarative query into an efficient execution plan, often better than a human would write.

A typical query:

-- PostgreSQL SELECT u.name, COUNT(o.id) AS order_count, SUM(o.total) AS revenue FROM users u LEFT JOIN orders o ON o.user_id = u.id WHERE u.created_at >= NOW() - INTERVAL '30 days' GROUP BY u.id HAVING COUNT(o.id) > 0 ORDER BY revenue DESC LIMIT 100;

PostgreSQL dominates modern SQL workloads thanks to JSONB, full-text search, PostGIS, logical replication, and generous licensing. MySQL (and MariaDB) still powers GitHub, Shopify, and much of the web. SQLite is the most deployed database on Earth by unit count, embedded in every phone and browser. CockroachDB and Spanner are distributed SQL built for horizontal scale.

Document databases store JSON-like objects with flexible schemas. Each document has a unique key and an arbitrary nested structure. Examples: MongoDB, Firestore, DynamoDB Document, Couchbase. Use when your data is naturally hierarchical (product catalogs, CMS content, user profiles) and your access pattern is "fetch this whole object by id."

// MongoDB document { "_id": ObjectId("6f3a...") , "email": "ada@example.com", "name": "Ada Lovelace", "addresses": [ { "label": "home", "city": "London" }, { "label": "work", "city": "Cambridge" } ], "tags": ["beta", "priority"] }

Key-value stores are the simplest: a key maps to a value that is opaque to the database. Examples: Redis (in-memory, famously fast), DynamoDB (core mode), Memcached, etcd, Cloudflare Workers KV. Use for caching, session storage, rate limiting, leaderboards, and any workload defined by "get/set by key."

Wide-column stores (Bigtable-style) organize data as rows keyed by a primary key, with columns grouped into column families. Columns can be added dynamically; each row can have different columns. Examples: Apache Cassandra, Google Bigtable, ScyllaDB, HBase. Use for write-heavy time-series or event data at massive scale (IoT, metrics, message history). Netflix famously uses Cassandra for view history.

Graph databases treat relationships as first-class citizens, modeling data as nodes and edges. Examples: Neo4j, Amazon Neptune, ArangoDB, Dgraph. Use when queries traverse many hops (social networks, fraud detection, recommendation engines, knowledge graphs).

BASE (Basically Available, Soft state, Eventually consistent) is the NoSQL counterpoint to ACID. Instead of strict consistency at all times, BASE systems accept that data on different nodes may disagree briefly after a write, as long as they converge. This tradeoff buys availability and partition tolerance.

The CAP theorem, proven by Gilbert and Lynch in 2002, states that a distributed data store can provide at most two of three guarantees during a network partition: Consistency (every read sees the most recent write), Availability (every request gets a response), and Partition tolerance (the system works despite network splits). Since partitions are a fact of life in distributed systems, the real choice is CP (consistency over availability) or AP (availability over consistency).

Examples:

- CP systems: HBase, MongoDB (with majority writes), etcd, ZooKeeper. A network partition means some nodes stop accepting writes to preserve consistency. - AP systems: Cassandra, DynamoDB (default), Riak, Couchbase. A partition means nodes keep serving requests but may return slightly stale data. - Single-node or non-partitioned: Postgres, MySQL (primary), Redis standalone. CAP does not apply the same way; you get CA during normal operation but trade availability for consistency if the primary fails.

CAP is often oversimplified. In practice, latency and tunable consistency matter more. Cassandra and DynamoDB let you pick per-query consistency (strong, eventual, bounded). Postgres has synchronous replicas that give you strong consistency across regions at the cost of write latency. The modern reality is not "pick two of three" but "tune per workload."

PACELC extends CAP: even without partitions (Else), you choose between Latency and Consistency. This is actually the more useful framing for day-to-day decisions.

Choose SQL when your data has meaningful relationships and queries cross them. When you need multi-row, multi-table transactions. When reporting and ad-hoc analytics matter. When schema enforcement catches bugs. When you will not outgrow a single writer anytime soon.

Concrete fits:

- Financial systems, billing, ledgers. Strong transactions are non-negotiable. - CRUD apps where the data model is naturally relational (users, orders, products, invoices). - Reporting, dashboards, business intelligence. SQL's analytical power is unmatched. - Data with strong constraints (foreign keys, unique constraints, check constraints). - Geospatial workloads with PostGIS. - Search-adjacent workloads with Postgres full-text or MySQL fulltext indexes. - JSON workloads that also need relational context. Postgres JSONB gives you 90% of document database features while keeping joins and transactions.

Real production use:

- GitHub runs on MySQL (Vitess-sharded) for everything except large binary storage. - Shopify runs on MySQL, heavily sharded. - Notion runs on PostgreSQL (sharded manually) for blocks, users, and permissions. - Stripe runs a distributed MongoDB for core data but uses Postgres for analytics and reporting. - Almost every Y Combinator SaaS startup in the last five years started on Postgres and stayed there.

If you are a team of under 50 engineers without a clear reason to pick something else, Postgres is the default.

Choose NoSQL when your scale, shape, or access pattern demands it. The four strongest signals are: (1) your working set will not fit on a single large machine, (2) your data is naturally denormalized and accessed by one key, (3) you need extreme write throughput, or (4) your schema truly evolves per record.

Concrete fits:

- Redis for caching, rate limiting, session storage, pub/sub, and leaderboards. Sub-millisecond reads and writes. - DynamoDB for serverless apps with predictable key-based access patterns and massive scale (Amazon's own shopping cart is the canonical example). - Cassandra or ScyllaDB for time-series, event logs, and write-heavy workloads at petabyte scale. Netflix stores all viewing history in Cassandra. - MongoDB for content-heavy apps with flexible schemas, where each document is a natural aggregate. The New York Times runs its CMS on MongoDB. - Firestore or DynamoDB for mobile and serverless apps where you want the database client to run in the browser or phone. - Neo4j for social graphs, fraud rings, and recommendation engines. LinkedIn and Adobe use graph databases at scale. - Elasticsearch or OpenSearch for full-text search and log analytics (technically document/search, not pure NoSQL, but in the same family).

Real production use:

- Twitter's home timeline uses Redis for the fan-out cache, with MySQL (Manhattan) for durable storage. - Instagram uses Cassandra for feeds, Postgres for user data. - Uber uses a mix: Postgres and MySQL for transactional, Cassandra for ride history, Redis for surge pricing. - Slack uses MySQL (Vitess) for messages and Solr for search.

No major product uses a single database type. The question is not SQL or NoSQL; it is which database for which workload.

Vertical scaling means buying a bigger machine. Postgres on a modern 128-core instance with 4 TB RAM can handle tens of thousands of transactions per second. For most companies, that is forever.

Horizontal scaling means adding more machines. SQL has traditionally been harder to scale horizontally because transactions across shards are expensive. NoSQL was built for it.

SQL scaling tactics:

- Read replicas. The first and best escape hatch. Route reads to replicas, writes to the primary. Postgres, MySQL, Aurora, and every managed service support this. - Partitioning within a single database. Split large tables by range or hash. Postgres declarative partitioning, MySQL partitions. - Sharding across databases. Split data by tenant or hash across independent Postgres or MySQL instances. Used by GitHub (Vitess), Shopify, Figma, Notion. Operationally hard; adopt when you must. - Distributed SQL. CockroachDB, Spanner, Yugabyte. Native horizontal scaling with SQL semantics.

NoSQL scaling is mostly automatic. DynamoDB, Cassandra, and MongoDB shard by primary key and rebalance transparently. The price is that cross-partition transactions and queries are expensive or impossible. Design your keys carefully upfront; refactoring a Cassandra primary key means rewriting your data.

Performance comparison (ballpark):

- Postgres on a large node: 50k-100k simple reads/sec, 10k-30k writes/sec. - Redis: 1M+ operations/sec per node, sub-ms latency. - DynamoDB: virtually unlimited, 10ms p99, auto-scales. - Cassandra: 100k+ writes/sec per node, scales linearly. - MongoDB: 30k-50k ops/sec per shard.

Numbers are rough and depend on hardware, query shape, and indexing. Measure your own workload before deciding.

The same business question, "give me the 10 most recent orders for user 42," looks different in each system.

SQL (Postgres):

SELECT id, total, created_at FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 10;

MongoDB:

db.orders .find({ user_id: 42 }) .sort({ created_at: -1 }) .limit(10);

DynamoDB (designed with a composite key of user_id + created_at):

{ "TableName": "orders", "KeyConditionExpression": "user_id = :u", "ExpressionAttributeValues": { ":u": 42 }, "ScanIndexForward": false, "Limit": 10 }

Cassandra (same composite key concept):

SELECT id, total, created_at FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 10;

The single-user case looks similar. The difference appears when you want cross-entity queries. "Top 10 users by total revenue this month with their latest order" is one line of SQL and a multi-stage pipeline or denormalized table in any NoSQL system. When analytics and reporting matter, SQL is almost always less code.

When working with document or JSON data, our [JSON Formatter](/json-formatter) helps visualize nested structures, and the [CSV to JSON Converter](/csv-json-converter) helps when migrating between tabular and document representations.

One of the biggest 2018-2024 shifts was NoSQL databases adding transactions. MongoDB 4.0 (2018) introduced multi-document ACID transactions within a replica set; 4.2 extended them to sharded clusters. DynamoDB added TransactWriteItems and TransactGetItems in 2018. Firestore has supported them since launch. Even Cassandra has lightweight transactions (paxos-based) for single-partition compare-and-set.

The tradeoffs are real. NoSQL transactions are typically slower than single-document operations and have narrower scope than traditional SQL. But the existence of them means you can no longer argue "NoSQL can't do transactions." The question is whether you need them often enough to justify the mode.

NewSQL is the other direction: SQL databases that scale horizontally. CockroachDB (inspired by Spanner), Google Spanner, YugabyteDB, and TiDB offer relational semantics, ACID transactions, SQL queries, and horizontal scaling in one package. They are harder to operate than Postgres and more expensive, but they solve a real pain point for teams that have outgrown a single primary and do not want to shard manually.

Multi-model databases (ArangoDB, FaunaDB, Couchbase) support multiple paradigms in one engine: document plus graph plus key-value. They reduce operational surface area but are rarely best-in-class at any one model.

The takeaway: the SQL vs NoSQL dichotomy is dissolving. Pick based on consistency needs, scale, query patterns, and operational comfort - not the label on the box.

Here is the complete side-by-side.

Data model — SQL: tables with fixed schema • NoSQL document: JSON objects • NoSQL KV: opaque values by key • NoSQL column: rows with column families • NoSQL graph: nodes and edges

Schema — SQL: strict, enforced • NoSQL document: flexible, optional validation • NoSQL KV: none • NoSQL column: flexible per row • NoSQL graph: labels per node type

Query language — SQL: SQL (ANSI standard) • MongoDB: MQL • DynamoDB: PartiQL or native API • Cassandra: CQL (SQL-like subset) • Neo4j: Cypher

Transactions — SQL: full ACID • Mongo: multi-document since 4.0 • DynamoDB: up to 100 items • Cassandra: lightweight, single-partition • Neo4j: full ACID

Joins — SQL: yes, core • Mongo: $lookup (limited) • DynamoDB: no • Cassandra: no • Neo4j: implicit via traversal

Consistency — SQL: strong • Mongo: tunable • DynamoDB: eventual or strong per read • Cassandra: tunable per query • Neo4j: strong

Horizontal scaling — SQL: hard (sharding, NewSQL) • Mongo: native • DynamoDB: automatic • Cassandra: linear, native • Neo4j: read replicas, Fabric for sharding

Best for — SQL: relational, transactional, reporting • Mongo: flexible documents • DynamoDB: serverless key-value at scale • Cassandra: write-heavy time-series • Neo4j: highly connected data

Typical latency — SQL: 1-10ms • Mongo: 1-10ms • DynamoDB: single-digit ms • Cassandra: single-digit ms • Neo4j: 1-20ms

Max practical scale — SQL: TB-PB with sharding • Mongo: PB • DynamoDB: effectively unlimited • Cassandra: PB+ • Neo4j: billions of nodes

Learning curve — SQL: moderate (SQL itself) • Mongo: easy • DynamoDB: steep (data modeling) • Cassandra: steep • Neo4j: moderate

Operational cost — SQL: low to moderate • Mongo: moderate • DynamoDB: pay per request • Cassandra: high (ops heavy) • Neo4j: moderate

Open-source options — SQL: Postgres, MySQL, SQLite, MariaDB • Mongo: MongoDB CE, FerretDB • KV: Redis, KeyDB, etcd • Column: Cassandra, ScyllaDB • Graph: Neo4j CE, JanusGraph

Managed services — SQL: RDS, Aurora, Cloud SQL, Supabase, Neon • Mongo: Atlas • KV: ElastiCache, Upstash, Memorystore • DynamoDB: AWS native • Cassandra: Astra, Keyspaces • Graph: Neptune, Neo4j Aura

Ecosystem maturity — SQL: 50+ years, enormous • NoSQL: 15+ years, strong and growing

Is SQL faster than NoSQL?

Neither is universally faster. Redis serves 1M ops/sec; Postgres serves tens of thousands of complex queries per second. For simple key-based reads, NoSQL often wins. For complex joins and aggregations, SQL wins. Pick based on your query patterns.

Can Postgres replace MongoDB?

For many workloads, yes. JSONB gives you schemaless documents, GIN indexes make them queryable, and you keep transactions and joins. Teams at Heap, Intercom, and GitLab have migrated from MongoDB to Postgres. MongoDB still wins when you need horizontal auto-sharding or a document-first API.

Should a startup use SQL or NoSQL?

Start with Postgres. It handles relational, JSON, full-text, and geospatial workloads. Move specific hot paths to Redis for caching or DynamoDB for scale when you can measure the bottleneck. Do not prematurely distribute.

Does NoSQL mean no schema?

No. NoSQL means flexible schema. Schema still exists in your application code; you just do not enforce it at the database level. Many NoSQL systems (MongoDB, DynamoDB) support optional schema validation.

What is the difference between Cassandra and DynamoDB?

Both are wide-column/key-value hybrids built for scale. Cassandra is open-source and self-hosted (or managed via DataStax Astra). DynamoDB is AWS-managed and serverless with per-request billing. Cassandra gives you more tuning knobs; DynamoDB gives you less ops.

What is NewSQL?

Distributed SQL databases that provide ACID transactions and SQL queries at horizontal scale. Examples: Google Spanner, CockroachDB, YugabyteDB, TiDB. Use when you need Postgres-like semantics but cannot fit on a single machine.

How do I migrate from SQL to NoSQL (or vice versa)?

Map your access patterns, not your schema. Design the NoSQL data model around how you query. Run dual writes through an abstraction layer, backfill historical data, switch reads, then retire the old system. Our [JSON Formatter](/json-formatter) and [CSV to JSON Converter](/csv-json-converter) are useful for inspecting and reshaping data during migrations.

Does CAP theorem still matter?

Yes conceptually, but PACELC is more useful for day-to-day. Even without partitions you choose latency vs consistency. Most modern databases let you tune that per query.

The honest answer to SQL vs NoSQL in 2026 is: start with Postgres unless you have a specific reason not to. It is free, battle-tested, handles relational, JSON, search, and geospatial, and scales further than 95% of companies ever need. Add Redis for caching the moment a query appears more than a few thousand times per second. Add a specialized store (DynamoDB, Cassandra, Elasticsearch, Neo4j) when you have a concrete workload that does not fit. Never adopt a database because it is trendy; adopt it because your workload demands it.

The teams that get this right treat databases as tools, not identities. They pick per workload, keep their data portable, and migrate when measurements say so. The teams that get it wrong pick based on a conference talk and then fight the database for five years.

When working with data during development - exploring API responses, reshaping exports, converting between formats - our [JSON Formatter](/json-formatter) and [CSV to JSON Converter](/csv-json-converter) save time no matter which database you land on.

Format and explore JSON documents with the [JSON Formatter](/json-formatter). Convert between tabular and document formats with the [CSV to JSON Converter](/csv-json-converter). Test database-backed APIs with the API Client.