NoSQL: The Four Families

Why this matters: "NoSQL" names a rejection, not a design. The four families underneath it are as different from each other as they are from SQL, and picking the wrong one is worse than staying relational.

Key takeaway

NoSQL databases handle diverse data models and excel where you have large volumes of semi-structured or unstructured data, low latency requirements, and flexible schemas. They achieve this largely by relaxing strict consistency restrictions.

What they buy you

Characteristic	What it means
Simple design	Avoids impedance mismatch — a document store saves all of an employee's data in a single document instead of splitting it across joined tables, simplifying coding and debugging
Horizontal scaling	Built to run on clusters; automatically partitions (shards) data across nodes, so scaling out with traffic is straightforward and a failed node can be replaced without disrupting the application
Availability	Replication provides high availability and disaster recovery; node maintenance can often happen without downtime
Flexible schema	Many require no predefined schema — JSON documents in one collection can have different fields, so the data structure evolves dynamically
Cost	Many are open source and designed for clusters of inexpensive commodity servers rather than expensive proprietary hardware

The four data models

Key-value database

Key-value databases store data as key-value pairs, much like a hash table. The key is a unique identifier; the value ranges from a simple scalar to a complex object. They are highly partitionable and allow easy horizontal scaling. Examples: Amazon DynamoDB, Redis, Memcached.

Use case: session-oriented applications. Web applications store user session data — profiles, preferences, shopping carts — keyed by a unique session ID, allowing extremely fast retrieval of user state.

Keys can be composite. In DynamoDB a key may combine two attributes — a partition key plus a sort key — so Product ID + Type addresses an item whose remaining attributes vary per record:

Product ID | Type      | Attributes
-----------+-----------+---------------------------------------
1          | Book ID   | As You Like It, Shakespeare, 1623
2          | Album ID  | 6 Partitas, Bach, Track: Partita No. 1
3          | Movie ID  | The Kid  /  The Lion King

Note the last column: the schema is defined per item. Two rows in the same table hold different attributes entirely.

Document database

Document databases store data as XML, JSON, or BSON. Documents are hierarchical tree structures containing maps, collections, and scalar values, and — unlike relational tables — documents in the same database can have varying structures. Examples: MongoDB, Google Cloud Firestore.

json

{
  "id": 1001,
  "name": "Brown",
  "title": "Mr.",
  "email": "brown@anyEmail.com",
  "cell": "123-465-9999",
  "likes": ["designing", "cycling", "skiing"],
  "businesses": [
    { "name": "Brown Consulting", "role": "Founder" }
  ]
}

Everything about this person — including the nested likes array and businesses collection — lives in one document. In a relational schema that would be three tables and two joins.

Use case: unstructured catalog data. In e-commerce, products have unique attribute sets — a laptop's specs differ entirely from a shirt's. Storing that relationally is inefficient; a document database keeps all attributes of a product together, improving management and read performance. They also suit content management systems such as blogs and video platforms.

Graph database

Graph databases use graph structures: nodes represent entities, edges represent relationships. Because data is stored alongside its relationships, traversal is efficient. Examples: Neo4J, OrientDB, InfiniteGraph.

Each node carries properties (Name, ID, Age); each edge carries a label and its own properties.

Use case: social networks and recommendation engines. They are optimized for querying complex relationships — traversing friend-of-friend connections, detecting patterns in user activity. Also used in fraud detection and knowledge graph construction.

Columnar database

Columnar databases organize data by column rather than by row. This optimizes retrieval of specific fields across large datasets, making it ideal for analytics. Examples: Amazon Redshift, Google BigQuery.

Row-oriented:     [1, Smith, John, 01-01-01] [2, Jones, Herry, 01-02-03] ...
                   read a row -> get every column

Column-oriented:  [1, 2, 3, 4, 5, 6]  [Smith, Jones, Young, ...]  [dates...]
                   read a column -> get that field for every row

Use case: analytics and data warehousing. Computing the average transaction amount over a year is efficient because the database reads only the amount column and ignores customer names entirely. In a row store it would read every byte of every row to get one field.

What NoSQL costs you

Drawback	The detail
Lack of standardization	No standard query language like SQL — each database has its own API and syntax, making applications hard to port between NoSQL systems
Consistency	To achieve high availability and partition tolerance, many sacrifice strong consistency for eventual consistency, and lack strict data-integrity guarantees such as foreign-key constraints

The second point is the one with teeth. Losing foreign-key constraints means referential integrity becomes your application's job — nothing stops an order from referencing a deleted customer except code you wrote and remembered to run everywhere.