NoSQL gets misunderstood constantly. Developers reach for it to avoid schemas, only to discover that schemaless data is harder to query and debug than well-modeled relational data. In 2026, the right framing is: NoSQL is five distinct data models, each optimal for a specific access pattern. Here is how to learn each one without cargo-culting.
What changed in 2026
- MongoDB 8 ships built-in queryable encryption and vector search — the document model is now a genuine multi-model store for embeddings, time series, and operational data in one cluster.
- DynamoDB zero-ETL integrations are standard — real-time sync to Redshift and OpenSearch without managing pipelines.
- Redis 8 is post-acquisition stable — the Redis Commons license concerns from 2024 resolved; Valkey (the Linux Foundation fork) and Redis 8 OSS both gained production adoption.
- Cassandra 5 brought vector search and improved UDFs; wide-column stores are back in consideration for ML feature stores.
- "NewSQL" and "NoSQL" blurred further — CockroachDB, Spanner, and PlanetScale offer SQL + horizontal scale, removing the main reason to pick NoSQL for scale alone.
The five NoSQL models
| Model |
Best for |
Examples |
| Document |
Flexible schemas, nested objects, content |
MongoDB, Firestore, Cosmos DB |
| Key-value |
Cache, sessions, leaderboards, counters |
Redis, DynamoDB (single-table) |
| Wide-column |
Write-heavy time series, sparse columns |
Cassandra, Bigtable, ScyllaDB |
| Graph |
Relationship traversal, social, fraud |
Neo4j, Neptune, Dgraph |
| Time-series |
Metrics, IoT, financial ticks |
InfluxDB, TimescaleDB, QuestDB |
Learning path
- Understand the CAP theorem — not to memorize, but to understand why NoSQL systems make the tradeoffs they do.
- Start with MongoDB — it has the most beginner resources and the document model is intuitive.
- Add Redis — session stores and caching are in every production app; Redis is unavoidable.
- Learn DynamoDB single-table design — the most important shift from SQL thinking; access patterns drive schema.
- Pick one specialized model based on your work: Cassandra for IoT/time-series, Neo4j for graphs, InfluxDB for metrics.
MongoDB: document model basics
// Insert a document — no schema required
await db.collection("orders").insertOne({
userId: "u_123",
items: [{ sku: "A1", qty: 2 }, { sku: "B4", qty: 1 }],
total: 49.99,
createdAt: new Date(),
});
// Query with projection — only return needed fields
const order = await db.collection("orders").findOne(
{ userId: "u_123" },
{ projection: { total: 1, createdAt: 1 } }
);
// Create an index on userId for fast lookups
await db.collection("orders").createIndex({ userId: 1 });
Redis: key-value and beyond
import redis
r = redis.Redis(host="localhost", port=6379, decode_responses=True)
# Key-value cache with TTL
r.set("session:abc123", '{"userId": "u_1", "role": "admin"}', ex=3600)
# Sorted set — leaderboard
r.zadd("scores", {"alice": 9500, "bob": 8800, "carol": 9100})
top3 = r.zrevrange("scores", 0, 2, withscores=True)
# [('alice', 9500.0), ('carol', 9100.0), ('bob', 8800.0)]
# Atomic counter — no race condition
r.incr("page:views:/blog/nosql")
DynamoDB single-table design: the key concept
Traditional SQL: one table per entity
users, orders, products, reviews
DynamoDB single-table: all entities in one table
PK | SK | data...
USER#u123 | PROFILE | {name, email}
USER#u123 | ORDER#ord456 | {total, status}
USER#u123 | ORDER#ord789 | {total, status}
PRODUCT#p001 | META | {name, price}
Your access pattern drives the key design. Decide the queries first; design the keys around them.
NoSQL vs SQL — when to actually pick NoSQL
| Situation |
Choice |
| Flexible, evolving schema |
Document DB |
| Sub-millisecond cache/counter |
Key-value (Redis) |
| 100k+ writes/second, time-ordered |
Wide-column (Cassandra) |
| Social graph traversal, 3+ hops |
Graph (Neo4j) |
| Metrics, sensor data, retention |
Time-series (InfluxDB) |
| Complex queries, joins, transactions |
Postgres (stay relational) |
| Unknown access patterns |
Postgres (pivot later) |
How to pick the right NoSQL store
- List your top 5 query patterns before choosing a database. The store must serve them efficiently.
- Prototype with the access patterns, not with "what can I store." Insert realistic data and run your actual queries.
- Check operational cost — managed DynamoDB is pay-per-request; self-hosted Cassandra needs ops expertise.
- Evaluate the client ecosystem — MongoDB and Redis have the best drivers in every language.
- Test failure modes — what happens when a node goes down? What is your consistency model?
Common mistakes
Schema-on-read as an excuse for no schema. "Flexible schema" means your application is responsible for validation. Without schema enforcement at the app layer, you accumulate corrupt data that breaks queries six months later.
Ignoring index design. MongoDB without indexes does collection scans; DynamoDB without the right GSI requires full table scans. Index design is 80% of NoSQL performance.
Premature NoSQL. Most applications under 10M rows and with normalized data are faster to build, query, and debug in Postgres.
Embedding everything in one document. Deeply nested 5-level documents are hard to query and update atomically. Normalize when relationships are many-to-many.
Not setting TTLs on ephemeral data. Redis memory and DynamoDB costs blow up when nobody sets expiry on session/cache keys.
What to skip
- Learning Cassandra as a first NoSQL — its data model is the most counter-intuitive; start with MongoDB.
- CouchDB — largely superseded by PouchDB for offline-first and CouchDB use-cases shifted to Firestore.
- Running multi-region Cassandra clusters on your first project — extreme complexity for beginners; use a managed service.
FAQ
Is NoSQL faster than SQL?
Not inherently. NoSQL stores are optimized for specific access patterns; outside those patterns they can be slower than Postgres. MongoDB full-collection scans are far slower than a Postgres index scan.
Do NoSQL databases support transactions?
Yes, in 2026. MongoDB, DynamoDB, and Cassandra all support multi-document/multi-row ACID transactions. The performance cost is real — design to avoid transactions in hot paths.
Should I learn MongoDB or DynamoDB first?
MongoDB for general learning — better documentation, free Atlas tier, richer query language. DynamoDB when you are building on AWS and need serverless pay-per-request scaling.
Can I mix SQL and NoSQL in one app?
Yes and it is common — Postgres for transactional data, Redis for cache/sessions, Elasticsearch for full-text search. The challenge is keeping them in sync.
Where to go next