The same data, stored four different ways. Compare documents, key-value pairs, wide columns and graphs against the relational original — and see what each model makes easy and what it makes painful.
Document databases store records as documents, often with nested fields. Key-value stores retrieve values by a key. Wide-column systems organize data into column families for distributed workloads. Graph databases represent entities and relationships for traversal.
These models make different operations convenient; none is best for every workload. Some products combine multiple models or support SQL-like queries, transactions, and schemas. “NoSQL” does not mean that a database has no query language or no structure.
A flexible storage format can make new fields easier to add, but the application still needs to agree on required fields, types, and meanings. Without validation, records written by different versions of a service may disagree in ways that break readers.
Document models can embed related values to make common reads efficient, but duplication and unbounded growth complicate updates. Graph models support relationship traversal, but a relational database can also represent relationships. See document models and rows and key-value and graph models.
Write down the queries, update patterns, consistency expectations, growth, and operational skills required. Compare those needs against a relational design before choosing a specialized store. A multi-database architecture also needs clear ownership of each fact and a way to handle partial failure across stores.
For an order history page, ask whether the application needs whole order documents, joins to shared product records, or several query patterns across customers and dates. A document layout may simplify fetching a bounded order with its lines; a relational design may make cross-order analysis and foreign-key constraints easier. A graph store is relevant when traversing relationships is central, not just because records refer to each other. Compare realistic reads, writes, consistency, and operational cost using the same example data.
When an application writes the same fact to a relational database and a cache or search index, those writes are not automatically one atomic transaction. A crash between them can leave the copies inconsistent. Decide which store is authoritative, how changes are propagated, how consumers detect lag, and how a failed update is retried. The operational cost of synchronizing two models can outweigh the query benefit. Start with one system when it meets the workload, then add another only for a measured need.
About to run: press Add field to one record. Before it does — what happens to the readout?
Committing to an answer first is the point — the reveal runs the experiment on the visualisation above and reads the real value back, so nothing here is scripted.
Say the answer out loud before you reveal it — recalling it is what makes it stick, and rereading it is not.
What does this module say about “Several families, not one model”?
What does this module say about “Schema flexibility still needs a contract”?
What does this module say about “Choose from access and consistency needs”?
Compare document, key-value, wide-column and graph databases and see which relational guarantee each one drops to gain something else.