yoklainterview sim
ProgressHistory

Database Nosql Models Interview Questions

75 verified Database Nosql Models interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

Nosql ModelsDifficulty 1
In a document-oriented NoSQL database, what is the basic unit of data?
  • aA fixed row that must match a predefined table schema
  • bA self-describing document (e.g. JSON/BSON) that can hold nested fields✓
  • cA single value retrieved only by its exact key
  • dA node connected to other nodes by labeled edges
Explanation:Document stores keep data as self-describing documents (JSON/BSON), so each document carries its own structure and can nest fields and arrays. A fixed table row (a) describes the relational model; retrieval only by key (c) is the key-value model; nodes and edges (d) describe a graph database.
Nosql ModelsDifficulty 1
Which workload is a key-value store the most natural fit for?
  • aAd-hoc reporting that filters and aggregates across many attributes
  • bEnforcing foreign keys across several normalized tables
  • cTraversing friend-of-friend relationships across a large social network
  • dStoring user sessions or cache entries looked up by a single id✓
Explanation:A key-value store maps an opaque key to a value and is optimized for fast get/put by key — ideal for sessions and caches. Ad-hoc filtering across many attributes (a) needs richer query support; foreign keys and normalization (b) are relational features; multi-hop relationship traversal (c) is what graph databases target.
Nosql ModelsDifficulty 2
A document database stores this order:
{
  "orderId": "A-100",
  "customer": { "name": "Lee", "city": "Berlin" },
  "items": [
    { "sku": "X1", "qty": 2 },
    { "sku": "X2", "qty": 1 }
  ]
}

Why can a document database keep the customer and items inside the order like this, while a normalized relational design usually would not?
  • aA document holds nested objects and arrays as one self-contained unit, keeping related data together✓
  • bJSON documents may never reference other documents, so all data must always be embedded inline
  • cThe engine transparently splits the nested fields into hidden relational tables behind the scenes
  • dRelational tables can never store more than one related child row for a given parent entity
Explanation:Document databases model an aggregate: one document can embed sub-objects and arrays, so an order carries its customer and line items together and is read in a single lookup. Documents can also reference other documents (b is false), the engine does not secretly normalize them (c), and relational tables can absolutely hold many child rows via a separate table (d).
Nosql ModelsDifficulty 1
Which list correctly names four common categories of NoSQL databases?
  • aRelational, hierarchical, network, and object
  • bPrimary, secondary, clustered, and covering
  • cDocument, key-value, wide-column, and graph✓
  • dOLTP, OLAP, columnar, and in-memory
Explanation:The four widely cited NoSQL families are document, key-value, wide-column, and graph, each with a different data model. Option (a) lists older/relational database models, (b) lists index types, and (d) mixes workload and storage categories rather than NoSQL data models.
Nosql ModelsDifficulty 2
An app must answer questions like 'who are the friends-of-friends of user X, up to 3 hops away?' over a large, highly connected social network. Which NoSQL model fits best?
  • aKey-value store, using the user id as the key
  • bGraph database, modeling users as nodes and friendships as edges✓
  • cWide-column store, with one very wide row per user
  • dDocument store, embedding each user's entire friend tree in one document
Explanation:Multi-hop relationship traversal is exactly what graph databases optimize: nodes and edges let you walk connections without expensive repeated joins. A key-value store (a) can't traverse relationships; a single wide-column row (c) doesn't model arbitrary connections; and embedding the whole friend tree in one document (d) explodes in size and duplicates data badly.
Nosql ModelsDifficulty 2
A team claims 'NoSQL is always faster and better than a relational database, so we should drop SQL entirely.' Why is this reasoning flawed?
  • aNoSQL databases fundamentally cannot scale horizontally, so relational is the only safe default
  • bThere is no real difference; 'SQL' and 'NoSQL' are just two names for the exact same technology
  • cRelational databases always outperform NoSQL in every possible scenario, so migrating to NoSQL is simply never worth the effort
  • dNoSQL trades away features like joins and multi-row ACID for scale or flexibility; the best fit depends on the workload✓
Explanation:NoSQL is not universally superior: different NoSQL models give up things like general-purpose joins or strong multi-record transactions to gain scale or flexibility, so suitability depends on the access patterns. The other options are absolutes — NoSQL can scale horizontally (a is wrong), the two are genuinely different approaches (b), and neither wins in every case (c).

By specialization

MongoDB 450MySQL 450PostgreSQL 450Redis 450

By seniority

Database JuniorDatabase MidDatabase Senior

Other fields

BackendFrontendFullstackDevOps / CloudAI EngineerMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2475-question Database bank.

Start interview