SQL vs NoSQL

Quick verdict

SQL databases, also called relational databases, organise data into tables of rows and columns with a schema declared in advance. Relationships are expressed with keys and enforced with constraints such as foreign keys, data is queried with SQL, and changes run inside ACID transactions. PostgreSQL, MySQL, MariaDB, SQL Server, Oracle AI Database and SQLite are all relational.

NoSQL ("not only SQL") is not one product or one model. AWS describes NoSQL databases as purpose-built for specific data models and lists key-value, document, graph, in-memory, search, wide-column and time-series databases among them. What they share is that they do not use the relational table model as their primary structure, and most are designed to spread data across many servers by a key.

Because the families differ so much, "SQL vs NoSQL" is really a set of trade-offs: structure against flexibility, general queries against queries designed in advance, and strict consistency against availability and scale-out. The lines have also blurred: relational engines store and index JSON, several NoSQL databases offer ACID transactions and SQL-like languages, and distributed SQL databases scale relational data across nodes. This page covers the broad choice; the linked comparisons go into specific products.

Side by side

Key differences

NoSQL is a family: the main types and what each fits

Comparing "SQL" with "NoSQL" only makes sense once you know which NoSQL family you mean. The definitions below follow AWS's descriptions of NoSQL database types; the product examples are illustrations, not recommendations.

• Document databases store JSON-like documents that, in AWS's words, are flexible, semi-structured and hierarchical. Typical uses are catalogues, user profiles and content management. Examples: MongoDB, Cloud Firestore, Amazon DocumentDB. See MongoDB vs PostgreSQL, MongoDB vs MySQL and Firebase vs PostgreSQL.
• Key-value stores keep a collection of key-value pairs in which the key is the unique identifier; they partition easily and suit sessions, carts, gaming and high request rates. Examples: Redis and Valkey (in memory), Amazon DynamoDB (key-value and document). See Redis vs MongoDB, Redis vs PostgreSQL, DynamoDB vs MongoDB and DynamoDB vs PostgreSQL.
• Wide-column stores group rows by a partition key and are designed for large, write-heavy data spread across data centres, with tables designed around queries. Examples: Apache Cassandra and Amazon Keyspaces. See Cassandra vs MongoDB.
• Graph databases store entities as nodes and relationships as edges, for highly connected data such as social networks, recommendations, fraud detection and knowledge graphs. Examples: Neo4j and Amazon Neptune.
• Time-series databases store and analyse large volumes of time-stamped events such as metrics and sensor readings. Examples: InfluxDB 3 and Amazon Timestream. TimescaleDB, maintained by Tiger Data, takes another route: it is a PostgreSQL extension, so time-series data stays in a relational database queried with SQL.

AWS also lists in-memory stores (for example Amazon ElastiCache and MemoryDB) and search engines (Amazon OpenSearch Service) as purpose-built types. Column-oriented analytical databases such as ClickHouse are sometimes grouped with NoSQL, but they are queried with SQL and solve a different problem; see ClickHouse vs MongoDB and Data Warehouse vs Database.

Consistency: ACID, BASE and what vendors actually document

ACID stands for atomicity, consistency, isolation and durability. AWS describes ACID databases as prioritising consistency over availability: if any step of a transaction fails, the whole transaction fails. BASE stands for basically available, soft state and eventually consistent; AWS describes it as prioritising availability, so users may temporarily read inconsistent data until concurrent updates complete. AWS sums up the traditional split as relational databases following ACID and NoSQL databases following BASE, and gives DynamoDB as a BASE example.

That split is now a simplification, so check what each product documents:

• Relational databases run every statement in a transaction. PostgreSQL, for example, uses multiversion concurrency control so that reads do not block writes, and offers serializable isolation.
• MongoDB makes single-document writes atomic and supports multi-document ACID transactions on replica sets (from 4.0) and sharded clusters (from 4.2); its default write concern is w: "majority".
• DynamoDB reads are eventually consistent by default; strongly consistent reads are available on tables and local secondary indexes but not on global secondary indexes. Transactions cover up to 100 items and 4 MB.
• Cassandra uses tunable consistency: each request chooses a consistency level (for example ONE or QUORUM). It has lightweight transactions for conditional writes but no general multi-row transactions.
• Redis Cluster, by Redis's own documentation, does not guarantee strong consistency and can lose acknowledged writes during failover, because replication is asynchronous.
• Cloud Firestore replicates synchronously and Google documents that reads return the latest version of the data; its transactions are atomic and use optimistic concurrency.

In our assessment, the useful question is not "ACID or BASE?" but "which operations in my application must be atomic and immediately consistent, and does this product guarantee that for those operations, at what cost?". A payments ledger and a social feed answer that very differently.

Scaling: up and out

Relational databases traditionally scale up (a larger server) and add read replicas for read traffic. Writes go to one primary, which keeps transactions and joins simple. Spreading one database's writes across many nodes needs extra components: PostgreSQL relies on extensions such as Citus for that, and distributed SQL databases such as CockroachDB are built for it; see CockroachDB vs PostgreSQL and CockroachDB vs MySQL.

Most NoSQL families scale out by design: data is partitioned by a key (a shard key in MongoDB, a partition key in Cassandra and DynamoDB, a hash slot in Redis Cluster) and each node holds a share. The price is that the key becomes central to the design. Queries that include it go to one partition; queries that do not may have to visit every node or need a secondary index or another copy of the data. MongoDB, for example, documents that queries without the shard key are broadcast to all shards. Graph databases are the exception among the families: they are usually chosen for traversal, not for partitioning.

Scale-out is a requirement for fewer applications than the debate suggests. In our view a single well-indexed relational server with replicas carries a large share of business applications, and managed services remove much of the operational burden for both kinds.

Schema flexibility

A relational table declares every column and type, and the database rejects writes that do not fit. Changing the structure means a migration (ALTER TABLE), which is safe and explicit but needs planning on large tables. MongoDB's documentation, by contrast, states that documents in one collection need not have the same fields and that a field's type can differ between documents; validation with $jsonSchema is optional. Firestore describes itself as schemaless.

"Schemaless" usually means the schema moves into application code: every reader must cope with old and new shapes. Relational engines have also narrowed the gap. PostgreSQL's jsonb, MySQL's JSON and SQL Server 2025's native json type let you keep a strict core with flexible attributes beside it. The modelling side of this choice, embedding against referencing and normalisation against duplication, is covered in Relational vs Document Database, and relational design in database normalization.

Query languages: one standard against many

SQL is an ISO standard, and while every engine has its own dialect, the core (SELECT, joins, GROUP BY, transactions) carries across products, tools and skills. NoSQL query interfaces are product-specific, even when they look like SQL. The same "orders for customer 1" request in four families:

-- SQL (PostgreSQL, MySQL, SQL Server)
SELECT order_id, order_date, status
FROM   orders
WHERE  customer_id = 1;

// MongoDB Query API (mongosh)
db.orders.find({ customer_id: 1 }, { order_date: 1, status: 1 })

-- Cassandra CQL: the table is designed for this query,
-- with customer_id as its partition key
SELECT order_id, order_date, status
FROM   orders_by_customer
WHERE  customer_id = 1;

// Neo4j Cypher: follow PLACED relationships from the customer node
MATCH (c:Customer {id: 1})-[:PLACED]->(o:Order)
RETURN o.id, o.orderDate, o.status;

CQL looks like SQL but has no joins, and its filters must follow the primary key or an index, which is why Cassandra tables are modelled per query. DynamoDB offers PartiQL, a SQL-compatible language, over its key-value model. Neo4j's current manual covers Cypher 25. InfluxDB 3 Core supports both SQL and InfluxQL, and Redis is driven by commands such as GET and HGETALL. For the SQL side, the site's SQL joins guide shows what relational queries can combine.

When each fits, and using both

Relational databases fit systems of record: orders, accounts, inventory, bookings, anything where relationships and correctness matter and where people will ask questions you did not plan for. A NoSQL family fits when its model matches a dominant access pattern: a document store for aggregates read whole, a key-value store for caching and sessions, a wide-column store for very high write volume across regions, a graph database for multi-hop relationship queries, a time-series database for metrics.

Using several stores in one system (often called polyglot persistence) is common: a relational database as the system of record, Redis as a cache, a search engine for full-text search, and a warehouse for analytics. Each extra store adds operations work and a copy of data to keep in sync, so add one when a clear workload justifies it. The article relational database vs NoSQL covers the same ground in a longer, tutorial style.

Pricing and licensing

This is a paradigm comparison, so there is no single price; what differs is licensing and billing models. On the SQL side, PostgreSQL (PostgreSQL Licence), MySQL Community (GPLv2) and SQLite (public domain) have no licence fee, while SQL Server and Oracle AI Database are commercial products with free editions that carry limits. Managed relational services are mostly billed by instance or vCore hours plus storage.

On the NoSQL side, licences vary widely and some are not OSI-approved open source: MongoDB Community Server is under the SSPL v1.0; Redis 8 is offered under RSALv2, SSPLv1 or AGPLv3; Apache Cassandra is under the Apache License 2.0; Neo4j Community Edition is GPL v3 with a commercial Enterprise Edition; InfluxDB 3 Core is MIT or Apache 2.0 at the user's choice. Serverless NoSQL services often bill per request rather than per server. As one dated example, Amazon DynamoDB on-demand lists USD 0.625 per million write request units and USD 0.125 per million read request units in US East (checked October 2026), plus storage. Cloud Firestore bills per document read, write and delete, including documents and index entries read to satisfy a query. Request-based billing makes cost depend directly on access patterns, so model your expected traffic before committing.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• Large analytical queries over history and many sources: use a data warehouse or columnar engine; see Data Warehouse vs Database.
• Relational data that must scale writes across regions: a distributed SQL database keeps SQL and transactions; see CockroachDB vs PostgreSQL.
• A local, single-user or embedded app: an in-process database such as SQLite avoids running a server; see SQLite vs PostgreSQL.

Final recommendation

Frequently asked questions

Sources

• AWS: What is NoSQL?
• AWS: The difference between ACID and BASE databases
• MongoDB manual: Transactions
• MongoDB manual: Data modeling
• MongoDB manual: Sharding
• Apache Cassandra documentation: Dynamo (replication and consistency)
• Redis documentation: Scale with Redis Cluster
• Redis licences
• Amazon DynamoDB Developer Guide: Read consistency
• Amazon DynamoDB on-demand pricing
• Cloud Firestore: Understand reads and writes at scale
• Neo4j Cypher manual
• Neo4j licensing
• InfluxDB 3 Core documentation
• TimescaleDB (GitHub repository)
• PostgreSQL documentation: Concurrency control (MVCC)
• PostgreSQL documentation: JSON types

Checked October 2026.

How we research comparisons: our editorial method.