NoSQL Taxonomy

Four Families, Four Philosophies

Saying "NoSQL" tells you almost nothing about how a database actually works. It is like saying "not a car" when someone asks what vehicle you drive. It could be a motorcycle, a bus, a helicopter, or a bicycle. NoSQL is an umbrella term covering at least four fundamentally different data models, each optimized for different access patterns.

The four families are: key-value stores, document databases, wide-column stores, and graph databases. Picking the right family means understanding your data shape and how you will query it.

Key-Value Stores

Key-value stores are hash tables at scale. You give the database a key, it returns a value. You cannot query by value contents. You cannot filter or sort. You can only get, set, and delete by key. This constraint is the source of their power. With no secondary indexes, no joins, and no query parsing, operations complete in microseconds.

Redis is the most widely used key-value store. It holds data in memory, supports data structures beyond simple strings (lists, sets, sorted sets, hashes), and provides sub-millisecond latency. DynamoDB is Amazon's managed key-value and document store, built for horizontal scalability with single-digit millisecond reads at any scale.

Use when: Session storage, caching, rate limiting, leaderboards, feature flags. Any workload where the access pattern is "I know the key, give me the value."

Avoid when: You need to search by attributes within the value, or you need relationships between records.

Document Databases

Document databases sit between key-value simplicity and relational richness. Each document is a self-contained unit. A user document might contain the user's name, address (nested object), order history (array of objects), and preferences (nested map). You can query any of these fields.

MongoDB is the dominant document database. It supports rich queries, aggregation pipelines, secondary indexes, and multi-document ACID transactions. Couchbase and Amazon DocumentDB are other options in this space.

The document model works well when your data naturally forms aggregates. An e-commerce product is a good example: the product name, description, images, variants, and reviews form a logical unit that gets read and written together. Storing this as a single document avoids the five-table join you would need in a relational database.

Use when: Content management, product catalogs, user profiles with variable fields, event logging.

Avoid when: You need complex joins across document types or strict referential integrity between collections.

Wide-Column Stores

Wide-column stores were inspired by Google's Bigtable paper (2006). The data model looks like a table, but it is fundamentally different from relational tables. There is no fixed schema. Each row can have millions of columns. Columns are grouped into families, and the database stores each family contiguously on disk.

Apache Cassandra is the most prominent wide-column store. It provides linear write scalability: adding a node to the cluster increases write throughput proportionally. Cassandra partitions data by a hash of the partition key and sorts data within each partition by the clustering columns. This makes time-ordered queries within a partition very fast.

HBase (built on Hadoop) and ScyllaDB (a Cassandra-compatible database written in C++) are other notable wide-column stores.

Use when: Time-series data (IoT sensor readings, event logs), messaging at scale, write-heavy workloads with known query patterns.

Avoid when: You need ad-hoc queries, complex aggregations, or do not know your access patterns at design time.

Graph Databases

Relational databases can model graphs using join tables, but traversing deep relationships becomes exponentially expensive. A three-hop query (friends of friends of friends) requires three self-joins, each of which scans the entire relationship table. Graph databases use index-free adjacency: each node directly references its neighbors, so traversal cost is proportional to the local neighborhood size, not the total graph size.

Neo4j is the leading graph database. It uses the Cypher query language, which reads like a visual pattern: MATCH (a)-[:FOLLOWS]->(b)-[:FOLLOWS]->(c) RETURN c. Amazon Neptune and TigerGraph are other graph databases used at scale.

Use when: Social networks, recommendation engines, fraud detection, knowledge graphs, dependency mapping.

Avoid when: Your data has few relationships, or your queries are primarily simple lookups and range scans.

Data Model Comparison

Comparison Table

Radar Comparison

The radar chart below compares the four NoSQL families across five dimensions, scored on a relative scale of 1 (weakest) to 5 (strongest). These are directional, not absolute. Your mileage will vary depending on the specific product, configuration, and workload.

Key-value stores score the highest on speed and scalability but the lowest on query flexibility. Graph databases are the inverse: rich queries but harder to scale horizontally. Document and wide-column databases sit in different middle grounds. This is why polyglot persistence exists. No single family wins on every axis.

Choosing the Right Family

The decision tree above is a starting point, not a prescription. Many workloads could fit multiple families. When in doubt, start with the simplest option that meets your access pattern requirements. You can always add specialized databases later through polyglot persistence.

Systems Thinking Lens

Each NoSQL family creates a different constraint on your system. Key-value stores constrain your query patterns but free you from schema management. Graph databases free your query patterns but constrain your scaling options. These are balancing loops. The freedom you gain on one axis is paid for on another.

The leverage point is access pattern analysis. Before choosing a database family, write down your ten most important queries. If you cannot do that, you are not ready to choose. The database family should emerge from the access patterns, not the other way around. Too many teams pick a database because it is trendy, then spend months fighting its constraints.

Further Reading

• Fay Chang et al., Bigtable: A Distributed Storage System for Structured Data (Google, 2006). The paper that inspired wide-column stores including HBase and Cassandra.
• MongoDB Documentation, Data Modeling Introduction. Official guide to document modeling patterns in MongoDB.
• Neo4j Documentation, What is a Graph Database?. Clear introduction to graph data modeling and the property graph model.
• ScyllaDB, NoSQL Database Comparison. Detailed comparison across NoSQL families with performance characteristics.
• Redis Documentation, Data Types. Goes beyond simple key-value to show Redis's rich data structure support.