NoSQL & Trade-offs

The CAP theorem, BASE, and when to reach for a non-relational database

Why

NoSQL databases exist because relational databases make trade-offs that don't suit every use case — rigid schemas, expensive joins at scale, difficulty sharding. Understanding the CAP theorem and the different NoSQL data models lets you make deliberate technology choices rather than defaulting to Postgres for everything or blindly reaching for MongoDB.

Intuition

The CAP theorem states that a distributed system can guarantee at most two of: Consistency (every read sees the latest write), Availability (every request gets a response), and Partition tolerance (the system works despite network splits). Since network partitions are a reality, the real choice is C vs A: be consistent but potentially unavailable during a partition, or always available but potentially stale.

Relational databases prioritize Consistency. Many NoSQL databases prioritize Availability, embracing BASE: Basically Available, Soft state, Eventually consistent.

Explanation

NoSQL data models

Document (MongoDB, Firestore)

JSON-like documents, flexible schema. Good for hierarchical data that's read together. Avoid when documents need to reference each other frequently — no native joins.

Key-Value (Redis, DynamoDB)

Simplest model — get/set by key. Extremely fast. Redis: in-memory with rich data types (list, set, sorted set). DynamoDB: persistent, massively scalable. Use for caching, sessions, leaderboards.

Wide-column (Cassandra, HBase)

Rows with many sparse columns, partitioned by key. Optimised for write-heavy, time-series, and IoT workloads. Query patterns must be known at schema design time — model around access patterns, not entities.

Graph (Neo4j, Amazon Neptune)

Nodes and edges with properties. Natural for highly connected data: social networks, recommendation engines, fraud detection. Traversals that would require many joins in SQL are native and fast.

When to use SQL vs NoSQL

Reach for SQL when

Data has clear relationships. ACID transactions matter (financial, inventory). Schema is stable. Ad-hoc querying and reporting are needed. In practice: most applications should start here.

Reach for NoSQL when

Schema is highly variable or evolving fast. Write throughput exceeds what a single relational DB can handle. Access pattern is simple and known (key lookup, time-series). Horizontal scale is a hard requirement from the start.

← Previous Practice interview questions →