What is NoSQL?
NoSQL covers databases that drop the relational table model for something else: document stores like MongoDB, key-value stores like Redis, and wide-column stores like Cassandra. Each trades some of SQL's guarantees for a different strength, usually scale or flexibility.
Why it matters
Choosing the data store is an architectural decision that is painful to reverse. The honest senior answer is usually "start with Postgres," but you need to know when a document or key-value store genuinely fits, and be able to defend the choice. Cargo-culting NoSQL for a relational problem causes years of pain.
What to learn
- Document stores: flexible schemas and embedded data
- Key-value stores: simple, fast lookups by key
- Wide-column and when extreme write scale matters
- The CAP theorem in practical terms
- Eventual consistency and what it means for reads
- Why "schemaless" still needs a schema in your head
- Defaulting to relational unless you have a reason not to
Common pitfall
Reaching for a document database to "avoid schemas," then reinventing joins and constraints in application code badly. If your data is relational — entities with relationships you query across — a relational database will serve you better. Pick NoSQL for a specific access pattern, not to skip data modeling.
Resources
Primary (free):
- MongoDB — What is NoSQL? · docs
- Cloudflare — CAP theorem · docs
- PostgreSQL — JSON types · docs
Practice
Take a feature you would normally model relationally — say a product catalog with categories — and sketch how it would look in a document store and in Postgres. List the queries each makes easy and hard. Done when you can argue, with reasons, which store you would pick and why.
Outcomes
- Describe the document, key-value, and wide-column models.
- Explain eventual consistency and the CAP trade-off plainly.
- Decide when a NoSQL store genuinely beats relational.
- Defend "start with Postgres" as a sane default.