Skip to content

CONCEPT Cited by 1 source

NoSQL database

A NoSQL database is a non-relational datastore — it does not require data to be laid out in fixed-schema tables joined via foreign keys and accessed through SQL. The umbrella covers document stores (MongoDB), key-value stores (DynamoDB, Redis), wide-column stores (Bigtable / Cassandra), and graph stores. The common denominator is schema flexibility and horizontal scalability rather than any single storage model.

Historical framing (MongoDB's Web-2.0 origin story)

MongoDB frames the NoSQL movement as a response to Web 2.0 application demands that rigid relational schemas (Oracle / SQL Server) struggled with: rapidly iterating application shapes, high-throughput user-generated content, and browser ↔ backend communication increasingly done in JSON. Developer productivity + schema flexibility + massive horizontal scale became the primary design axis, not ACID transactions on normalized tables (Source: sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse).

CAP positioning (the commonly-assumed default)

Most early NoSQL databases were built on an eventually consistent model, prioritising Availability + Partition tolerance (AP) under the CAP theorem. This was the default assumption about NoSQL in the market for ~10 years and is the root of the widely-held perception that NoSQL = loose consistency.

MongoDB explicitly identifies itself as an exception to that default — designed as Consistency + Partition tolerance (CP) from the start, but often miscategorised:

"MongoDB was an exception, designed to prioritize Consistency and Partition Tolerance (CP). But, in a market dominated by AP systems, MongoDB was often lumped in with the rest, leading to the imprecise label of having 'light consistency.'" — MongoDB (Source: sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse)

This is the historical-framing analogue to the more mechanism-level tunable read/write concerns MongoDB later shipped.

NoSQL ≠ anti-ACID (later correction)

The other NoSQL-default assumption — "no multi-record transactions" — was also specifically reversed: MongoDB shipped multi-document ACID transactions in 2018 (MongoDB 4.0), later extended to sharded clusters. The article names this as "arguably the single most important development in its [MongoDB's] history" because it let one database span both the "page view count" workload (loose) and the "order checkout value" workload (ACID), instead of forcing the two-database split.

Why the categorisation matters

Because NoSQL = eventual-consistency was the default assumption, mature NoSQL databases that do offer strong consistency + ACID transactions (MongoDB post-4.0, Spanner, FoundationDB) still fight that perception for enterprise adoption. MongoDB's 2025 manifesto on adoption — 70% of the Fortune 500, 7 of the 10 largest banks, 14 of the 15 largest healthcare companies, 9 of the 10 largest manufacturers — is pitched as the empirical refutation of the historical categorisation (Source: sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse).

Seen in

  • sources/2025-09-25-mongodb-from-niche-nosql-to-enterprise-powerhouse — canonical MongoDB-side articulation of the "NoSQL was always broader than eventual-consistency" framing: MongoDB's own positioning as CP-not-AP, the perception cost of being lumped with AP peers, and the 2018 multi-document ACID milestone that closed the biggest transactional-workload gap.
Last updated · 200 distilled / 1,178 read