openskills.info
Course Preview

NoSQL Fundamentals

NoSQL is a family of database approaches that store and query data using models such as documents, key-value pairs, wide columns, and graphs. You choose a model from the operations and relationships your application needs, not from the NoSQL label alone.

itDatabases and data storage

Don't Panic: NoSQL Fundamentals

NoSQL is a family name for databases that put something other than relational tables and joins at the center of the design. That is the useful part of the label. The unhelpful part is that it sounds like one thing in a trench coat. It is not one query language, one consistency promise, or one excuse to stop thinking about data.

The problem is familiar. Some applications usually load one bounded order with its delivery address and line items. Others know a key and need a typed value. Some must serve known queries across distributed nodes. Others need to follow connections, such as a chain of permissions. A relational database remains a good answer for many systems. These other models exist when a different request shape is the one doing the heavy lifting.

Start with the access pattern, meaning a required read, write, or traversal. Then ask what its natural unit is. A document keeps named fields, nested objects, and arrays together. A key-value store makes direct lookup central. A wide-column design works from the query toward a partitioned table. A graph makes nodes and relationships first-class so paths can be the question instead of an accident.

The surprise is that a flexible schema has not escaped schema work. It has merely moved the paperwork to a different desk. You still need boundaries, ownership, duplication rules, indexes, partitions, and recovery. A partition key, the value that places data in a distributed system, deserves particular suspicion. Many possible values do not help if one value receives most of the traffic. Then a cluster has acquired many machines and one very busy problem.

NoSQL also does not come with a universal badge reading consistent, transactional, or safe to forget about backups. Products differ. Replication keeps copies, which is useful. It does not undo a replicated mistake, which is considerably less festive. Check what writes are atomic, when readers can see a write, how concurrent updates behave, and how restore is tested in the product you actually operate.

Read the Intro when you need the full comparison and the reasons each model fits. Use Slides for the compact decision flow. Keep the Cheatsheet nearby when turning a workload into model and partition questions. The Practice reference gives you a way to compare one workload across the four models, and the Exercise asks you to make the tradeoffs explicit. The Reference tab then takes you to product documentation, where the guarantees stop being family gossip and become engineering facts.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources