Questions: NoSQL Database Concepts

Question 1

An engineer argues: 'We should switch our user database to MongoDB because NoSQL is faster than PostgreSQL.' What is wrong with this reasoning?

• A. MongoDB is actually slower than PostgreSQL for all common operations
• B. NoSQL is not inherently faster than relational databases — each is optimized for different access patterns; performance depends entirely on whether the workload matches the system's strengths
• C. MongoDB requires significantly more hardware, making it slower and more expensive in practice
• D. The engineer is correct — NoSQL systems consistently outperform relational databases at any meaningful scale

Answer: (B)

NoSQL vs. relational is a tradeoff, not a ranking. NoSQL systems are optimized for specific access patterns — document lookups by ID, key-value retrieval, column-range scans — and can be dramatically faster for those. For workloads with complex joins, multi-table transactions, or ad-hoc queries, a relational database may outperform any NoSQL alternative. 'NoSQL is faster' is a dangerous oversimplification that ignores the fundamental principle: match the database to the workload.

Question 2

What distinguishes BASE semantics from ACID semantics in terms of the core engineering tradeoff?

• A. BASE systems avoid transactions entirely, while ACID systems require all operations to be wrapped in explicit transactions
• B. BASE systems sacrifice immediate consistency across replicas — allowing briefly stale reads — in exchange for availability and partition tolerance; ACID systems ensure all readers immediately see committed writes
• C. BASE is a newer standard that improves upon ACID by removing unnecessary constraints on small datasets
• D. BASE governs read operations while ACID governs write operations in distributed systems

Answer: (B)

The core BASE tradeoff is availability vs. consistency. ACID systems require that after a write commits, every reader anywhere immediately sees the new value — which in a distributed system means waiting for network round-trips to all replicas before acknowledging the write. BASE systems accept that replicas may briefly diverge (soft state) and converge asynchronously (eventually consistent), allowing writes to be acknowledged quickly. This is an engineering choice driven by the CAP theorem, not a quality reduction.

Question 3

In a NoSQL system with eventual consistency, data is not permanently incorrect — replicas may briefly diverge after a write but will converge to the same value given enough time without new updates.

• T. True
• F. False

Answer: True

True. 'Eventually consistent' is frequently misunderstood as meaning 'sometimes wrong.' It means that after a write, all replicas will converge to the same value — but convergence is asynchronous and may take milliseconds to seconds, not permanently. During the convergence window, a reader might see a slightly stale value. This is acceptable for many use cases (social media feeds, shopping carts) but not for others (bank balances, inventory counts where overselling is catastrophic).

Question 4

The term 'NoSQL' means these databases cannot use SQL or SQL-like query languages.

• T. True
• F. False

Answer: False

False. 'NoSQL' means 'not only SQL' — it signals that relational databases are not the only tool, not that SQL is prohibited. Many NoSQL systems support SQL-like query languages: Cassandra has CQL (Cassandra Query Language), Google BigQuery uses standard SQL, and various others provide SQL interfaces. The name is a historical artifact from the early days of the movement and is widely acknowledged as misleading.

Question 5

When would you choose a relational database over a NoSQL database? What characteristics of your data and workload should drive this decision?

Model answer: Choose a relational database when your data has complex relationships requiring multi-table joins, when you need ACID transactions (especially multi-row or multi-table writes that must be atomic), when your schema is stable and well-defined, and when your queries are unpredictable or ad-hoc. NoSQL is the better fit when you need to scale writes horizontally across many servers, your data is naturally hierarchical or variable in structure, your access patterns are highly predictable (lookup by key, fetch a document), and you can tolerate eventual consistency. The decision should be driven by workload shape, not by any assumption that one type is universally superior.

This is the core practical insight: there is no universally better database — only databases better suited to specific workloads. Many production systems use both, a pattern called polyglot persistence: relational databases for transactional data requiring ACID guarantees, key-value stores for caching, column-family stores for event logs, etc. The skill is matching the storage model to the data model and access pattern.