Why NoSQL emerged
In the 2000s, web companies faced data volumes, traffic, and flexibility needs that strained traditional databases. NoSQL systems relaxed parts of the relational model to meet them.
The pressures
Services such as search engines, social networks, and online shops grew to millions of users and petabytes of data. Scaling a single relational server vertically, with bigger hardware, hit limits and costs. Fast-changing applications also wanted flexible schemas, storing new fields without migrations. Companies built new systems tailored to their needs.
Influential papers
Google's Bigtable paper (2006) described a distributed wide-column store, and Amazon's Dynamo paper (2007) described a highly available key-value store using leaderless replication and consistent hashing. These inspired open-source systems such as HBase, Cassandra, and Riak. The label 'NoSQL', later often read as 'not only SQL', became popular around 2009.
Common traits
NoSQL systems commonly scale horizontally across commodity machines, partition and replicate data automatically, offer flexible or schema-less data models, and often relax strong consistency for availability and speed. They typically support simpler queries than SQL, centred on access by key, and push some work, such as joins, into application code.
BASE
In contrast to ACID, many NoSQL systems are described as BASE: basically available, soft state, eventually consistent. The system stays responsive, data may be temporarily inconsistent between replicas, and replicas converge over time. This suits shopping carts, social feeds, and analytics, but not, for example, bank balances.
Data models
The main families are key-value stores, which map keys to opaque values; document stores, which store structured documents such as JSON; wide-column stores, which organise data into rows with flexible, sparse columns grouped into families; and graph databases, which store nodes and relationships. Each makes certain access patterns fast and others awkward.
Schema-on-read
Relational databases enforce schema-on-write: data must match the schema when stored. Many NoSQL systems use schema-on-read: the database accepts varied documents, and the application interprets them when reading. This speeds development and handles heterogeneous data, but shifts validation into code, and old documents in outdated shapes can linger.
Convergence
The divide has narrowed. Relational databases added JSON columns, horizontal scaling options, and replication; PostgreSQL's JSONB type supports indexed queries on documents. Many NoSQL systems added richer query languages, secondary indexes, and even multi-document ACID transactions, as MongoDB did in version 4.0 in 2018. Choosing a database is now about workload fit rather than a SQL-versus-NoSQL battle.
Worked example
A product catalogue where shirts have sizes and colours, laptops have processor and memory specs, and books have authors and ISBNs. A relational design needs many nullable columns, many category tables, or an awkward entity-attribute-value table. A document store keeps each product as one JSON document with exactly its own fields, retrieved with a single lookup, though queries across all products by a rare attribute need indexes planned in advance.
Key takeaways
NoSQL arose from web-scale data, traffic, and the need for flexible schemas. Google's Bigtable (2006) and Amazon's Dynamo (2007) papers were foundational; the term spread around 2009. NoSQL systems scale horizontally, replicate and partition automatically, use flexible models, and often relax consistency. BASE (basically available, soft state, eventually consistent) contrasts with ACID. Families are key-value, document, wide-column, and graph. Schema-on-read moves validation into applications. Relational and NoSQL systems have converged, with JSON in SQL and transactions in NoSQL.
Flashcard
Bigger hardware for one server
Check your understanding
Which workload is the weakest fit for an eventually consistent BASE store?