NoSQL
A category of database management systems that do not use the traditional relational model.
Detailed Explanation
NoSQL databases (like MongoDB, Cassandra, or Redis) are designed for distributed data, massive scale, and flexible schemas. They can store data as documents, key-value pairs, wide-column stores, or graphs. They are often chosen for real-time applications, big data, and scenarios where the data structure is constantly evolving.
Quick Summary
NoSQL is an umbrella for non-relational databases, document, key-value, wide-column, graph, optimized for different shapes of data and scale. The right choice depends on access patterns, not on "avoiding SQL."
Key Takeaways
- Four main families: document (MongoDB, Couchbase), key-value (Redis, DynamoDB), wide-column (Cassandra, ScyllaDB), graph (Neo4j, Neptune).
- Schema flexibility helps early product iteration but creates data integrity debt at scale.
- Most NoSQL stores trade some consistency for availability and horizontal scalability (CAP theorem).
- Modern relational databases (PostgreSQL with JSONB) handle many "NoSQL" use cases natively.
- Choose by access pattern: "how will I query this?", not by hype.
When to use it
- Document stores for catalog data, user profiles, content with variable shape.
- Key-value for caches, sessions, rate-limit counters, real-time leaderboards.
- Wide-column for very high write throughput and time-series data (Cassandra, ScyllaDB).
- Graph databases for highly connected data, social networks, recommendation engines, fraud detection.
Common Mistakes
- Choosing NoSQL because "SQL won't scale," then needing joins anyway and reimplementing them poorly.
- Ignoring schema validation entirely; documents drift until queries fail in subtle ways.
- Using a document store for highly relational data and ending up with denormalized chaos.
- Skipping backups and disaster recovery; managed NoSQL is not automatically durable in the way users expect.
NoSQL, Frequently Asked
SQL or NoSQL for a new app?
Default to PostgreSQL. It handles structured data, JSON, full-text search, and even vector similarity now. Pick NoSQL only when you have a clear access pattern that benefits from it (massive write throughput, simple key lookups, graph traversals).
Can NoSQL do ACID transactions?
Many modern ones can within a single document or partition (MongoDB, DynamoDB). Cross-document or cross-partition transactions are limited or expensive. If you need strong transactional guarantees across many entities, relational is still the path of least pain.