Most Asked NoSQL Interview Questions and Answers

NoSQL interviews test whether you can choose the right data store for a problem and explain the trade offs honestly. This guide gives you 41 NoSQL interview questions and answers, from basics to scenario questions, for freshers and experienced engineers.

Every answer starts with a short, direct response you can say aloud, followed by a table, a query or a runnable example where it helps. The page treats NoSQL as a set of tools for different jobs, and avoids the claims that NoSQL is always faster, has no transactions or lets you pick any two from CAP.

The guide has six parts: 8 on NoSQL basics, 9 on distributed systems concepts, 9 on key value, document, column and graph stores, 5 on data modelling, 4 on current trends and 6 scenario questions. Use the contents list to jump to your level. If you are preparing for a document database role, read the separate MongoDB page as well.

Key points

• 41 questions in six parts, from basics to scenarios.
• Precise answers on CAP, consistency, replication and sharding.
• Runnable Redis examples with real output.
• Tables comparing database types, SQL against NoSQL and embedding against referencing.
• Scenario questions on choosing a store for real workloads.

In this guide

NoSQL Basics (Freshers)

Start with what NoSQL means, why it exists and how it differs from relational databases. Avoid saying NoSQL is better. The right answer is that it solves different problems.

Q1. What is NoSQL, and why was it created?

NoSQL describes databases that do not use the fixed table and join model of relational systems. They were created to handle very large data volumes, high write rates, flexible or changing structures and horizontal scaling across many cheap servers. The name is read today as not only SQL, because many of them also offer SQL like query languages.

Q2. What are the main types of NoSQL databases?

There are four classic types: key value stores, document databases, wide column stores and graph databases. Time series and vector databases are now often added as further types. Each is built around a data shape and an access pattern, so the choice should start from how the data is read and written.

Q3. What is the difference between SQL and NoSQL databases?

SQL databases store data in tables with a fixed schema, use joins, and offer strong ACID transactions, and they usually scale up on one larger server or through careful replication. NoSQL databases offer flexible schemas and scale out across many nodes, often with relaxed consistency, though many now offer transactions too.

Q4. When would you choose NoSQL over a relational database?

Choose NoSQL when the data does not fit tables well, when the structure changes often, when you need very high write throughput or low latency at scale, or when you must spread data across regions. Stay relational when you need complex joins, strict transactions and reporting across many entities.

What the interviewer is listening for: You choose by the access pattern and the consistency need, not by fashion.

Q5. What is polyglot persistence?

Polyglot persistence means using different data stores in one system, each for the job it does best. For example, a relational database for orders and payments, Redis for sessions and caching, Elasticsearch for search and a graph database for recommendations. It adds operational cost, so use it where the benefit is clear.

Q6. What is a schema less database, and is it really schema less?

Schema less means the database does not force a structure on every record, so documents in one collection can differ. The application still expects a shape, so the schema moves from the database into the code. Most products let you add validation rules, and good teams keep a clear data model.

Q7. What are ACID and BASE?

ACID stands for atomicity, consistency, isolation and durability, the guarantees of a classic transaction. BASE stands for basically available, soft state and eventually consistent, a looser model that favours availability and scale. Neither is a product feature to pick alone, since many databases let you choose per operation.

Q8. Is NoSQL always faster than SQL?

No. Speed depends on the data model, the indexes and the query. A NoSQL store is fast for the access pattern it was designed for, such as a key lookup, and slow or impossible for others, such as ad hoc joins. A well indexed relational database is fast for many workloads.

Distributed Systems Concepts (Intermediate)

This is the most tested part of a NoSQL interview. Be precise about the CAP theorem and consistency.

Q9. What is the CAP theorem?

The CAP theorem says that when a network partition occurs, a distributed data store must choose between consistency, meaning every read sees the latest write, and availability, meaning every request gets a response. Partitions cannot be avoided in practice, so the real choice is between consistency and availability during a partition.

Add that many systems let you tune the trade off per request, so labelling a product CP or AP is only a rough guide.

What the interviewer is listening for: You say the trade off applies during a partition, not all the time, and you avoid the common phrase pick any two.

Q10. What is eventual consistency?

Eventual consistency means that if no new writes arrive, all replicas will in time hold the same value. Reads in the meantime may return older data. It gives high availability and low latency, and it suits cases such as social feeds, where a short delay is acceptable. It does not suit account balances.

Q11. What are the main consistency models?

Strong consistency means every read sees the latest write. Eventual consistency means replicas converge over time. Between them are causal consistency, which preserves cause and effect order, read your writes, where a client sees its own updates, and monotonic reads, where a client never sees older data after newer data.

• Strong: simplest to reason about, most costly.
• Eventual: fastest and most available.
• Causal and session guarantees: practical middle ground.

Q12. What is replication, and what are the common models?

Replication keeps copies of data on several nodes for availability and read scaling. In primary replica replication, one node takes writes and copies them to others. In a multi leader setup, several nodes accept writes and must resolve conflicts. In a leaderless design, such as Cassandra, any replica can take a write and quorums decide success.

Q13. What is sharding, and how does it differ from replication?

Sharding splits the data across nodes so that each holds a part, which scales storage and write throughput. Replication copies the same data to several nodes, which gives fault tolerance and read scaling. Real systems use both: each shard is replicated. The shard key decides where a record goes, so it must be chosen with care.

Q14. What makes a good shard key?

A good shard key has high cardinality, spreads writes evenly and matches the most common query, so most queries hit one shard. A key that increases steadily, such as a timestamp or sequence number, sends all new writes to one shard and creates a hot spot. A hashed key spreads load but loses range queries.

Q15. What is consistent hashing?

Consistent hashing places both nodes and keys on a ring, and each key belongs to the next node clockwise. When a node joins or leaves, only the keys next to it move, not the whole dataset. Systems such as Cassandra and DynamoDB use it, often with virtual nodes to even out the load.

Q16. What is a quorum, and how does it give tunable consistency?

With N replicas, a write waits for W acknowledgements and a read contacts R replicas. If R plus W is greater than N, every read overlaps with the latest write, so reads are strongly consistent. Lower values give faster but weaker reads. Cassandra lets you set this per query with levels such as ONE and QUORUM.

N = 3

for W, R in [(1, 1), (2, 2), (3, 1), (1, 3)]:
    print(f"W={W} R={R} overlap guaranteed: {R + W > N}")

W=1 R=1 overlap guaranteed: False
W=2 R=2 overlap guaranteed: True
W=3 R=1 overlap guaranteed: True
W=1 R=3 overlap guaranteed: True

Only the combinations where R plus W exceeds 3 guarantee that a read sees the latest write.

Q17. How do distributed databases detect and resolve write conflicts?

Common methods are last write wins using timestamps, which is simple but can drop updates, vector clocks that track causal history so a conflict is detected and passed to the application, and conflict free replicated data types that merge automatically. Choose by how costly a lost update is.

Key Value, Document, Column and Graph Stores in Practice (Intermediate)

For each type, know a typical product, the data model and one command or query. The runnable examples below use a Redis compatible test server, so the outputs are real.

Q18. What is a key value store, and what is Redis used for?

A key value store keeps data as a unique key mapped to a value and is the simplest NoSQL model, with very fast reads and writes. Redis is an in memory key value store with data structures such as strings, hashes, lists, sets and sorted sets. It is used for caching, sessions, counters, queues and leaderboards.

import fakeredis

r = fakeredis.FakeRedis(decode_responses=True)

r.set("session:42", "user_17")
r.incr("page_views")
r.incr("page_views")

print(r.get("session:42"))
print(r.get("page_views"))

user_17
2

The counter shows that Redis can update a value atomically. Two increments give a value of 2.

Q19. How do Redis data types map to real needs?

Use strings for simple values and counters, hashes for objects with fields, lists for queues, sets for unique items and sorted sets for rankings. Choosing the right type avoids moving data to the application. A leaderboard, for example, is a sorted set with the score as the rank value.

import fakeredis

r = fakeredis.FakeRedis(decode_responses=True)

r.hset("user:1", mapping={"name": "Asha", "city": "Pune"})
print(r.hgetall("user:1"))

r.zadd("leaders", {"asha": 120, "ravi": 95, "meena": 130})
print(r.zrevrange("leaders", 0, 1, withscores=True))

{'name': 'Asha', 'city': 'Pune'}
[('meena', 130.0), ('asha', 120.0)]

Q20. How do you expire cached data in Redis?

Set a time to live on a key with EXPIRE or with an option on SET, and Redis removes the key after that time. It is how a cache stays fresh and how sessions time out. A memory limit with an eviction policy such as least recently used decides what to drop when memory is full.

import fakeredis

r = fakeredis.FakeRedis(decode_responses=True)

r.set("otp:9876", "445566", ex=300)
ttl = r.ttl("otp:9876")
print("expires within 300 seconds:", 0 < ttl <= 300)

r.persist("otp:9876")
print("after persist:", r.ttl("otp:9876"))

expires within 300 seconds: True
after persist: -1

Q21. What is a document database?

A document database stores each record as a self describing document, usually JSON or a binary form of it, that can hold nested objects and arrays. It suits data that is read as a whole, such as product catalogues, user profiles and content. MongoDB is the best known example, and has its own interview page.

Embedding related data in one document removes joins and makes reading one object a single lookup.

Q22. What is a wide column store, and how does Cassandra model data?

A wide column store organises data into tables of rows with a partition key and optional clustering columns, and rows can hold very many columns. In Cassandra, the partition key decides which node stores the row, and clustering columns sort rows inside a partition. You design the table around the query, not around the entities.

CREATE TABLE readings_by_sensor (
    sensor_id   text,
    reading_ts  timestamp,
    value       double,
    PRIMARY KEY ((sensor_id), reading_ts)
) WITH CLUSTERING ORDER BY (reading_ts DESC);

SELECT * FROM readings_by_sensor WHERE sensor_id = 's1' LIMIT 10;

Q23. Why does Cassandra write so fast?

Cassandra writes each update to a commit log and an in memory table, called the memtable, and acknowledges the write. It flushes memtables to immutable files on disk, called SSTables, and merges them later by compaction. Writes are sequential, with no read before write, so they are very fast.

Q24. What is a graph database, and when do you need one?

A graph database stores nodes and the relationships between them as first class data, so queries that follow many links, such as friends of friends or a path between accounts, stay fast. Use it for recommendations, fraud rings, network analysis and knowledge graphs. Neo4j is the best known, and uses the Cypher language.

MATCH (a:Person {name: "Asha"})-[:FRIEND]->(:Person)-[:FRIEND]->(fof:Person)
WHERE fof <> a
RETURN DISTINCT fof.name

Q25. What is Amazon DynamoDB, and how does its key design work?

DynamoDB is a fully managed key value and document database on AWS with single digit millisecond latency at scale. Each table needs a partition key, and optionally a sort key. Queries are efficient only when they use the key, so you design keys and secondary indexes from the access patterns, often keeping many entity types in one table.

Q26. What is HBase, and how does it relate to Hadoop?

HBase is a wide column store modelled on Google Bigtable that runs on top of HDFS. It gives random, real time read and write access to very large tables, which HDFS alone does not. Rows are sorted by row key, so key design controls both performance and range scans.

Data Modelling in NoSQL (Experienced)

A good NoSQL model starts from the queries. Interviewers use these questions to see whether you design that way.

Q27. How is NoSQL data modelling different from relational modelling?

In relational design you normalise the entities first and write queries later, joining as needed. In NoSQL you list the queries first and shape the data to answer them in one read, which often means denormalising and storing copies. You trade extra storage and update effort for fast, predictable reads.

Q28. When do you embed data and when do you reference it?

Embed when the child data is read with the parent, is small and bounded, and belongs to one parent, such as the addresses of a user. Reference when the data is large, grows without limit, is shared by many parents or changes independently, such as the orders of a customer.

Q29. What is denormalisation, and what are its risks?

Denormalisation stores the same data in more than one place so a query needs no join. The risks are extra storage and a copy going out of date, so you must update every copy, ideally through events or a transaction. Use it for data that is read much more than it is written.

Q30. How do you model many to many relationships in NoSQL?

Store an array of references on one or both sides, or create a separate link collection or table, depending on size and how you query. In a graph database it is a native relationship. In a key value or wide column store, maintain a second table keyed the other way for the reverse lookup.

Q31. What are secondary indexes in NoSQL, and what do they cost?

A secondary index lets you query by a field other than the primary key. In a distributed store, each index adds write cost and storage, and some, such as local indexes in Cassandra, must query many nodes. Add an index for an access pattern that matters, and prefer a table designed for that query where possible.

Current Trends (All Levels)

These topics separate candidates who read the news from those who only memorised definitions.

Q32. What is NewSQL?

NewSQL describes distributed databases that keep SQL and ACID transactions while scaling out like NoSQL. Examples include CockroachDB, TiDB and Google Spanner. They suit applications that need relational guarantees and global scale. They are newer, and operating them still needs care.

Q33. What are vector databases, and how do they relate to NoSQL?

A vector database stores embeddings, which are lists of numbers that capture the meaning of text or images, and finds the nearest ones to a query vector. They power semantic search and retrieval for AI answers. Dedicated products exist, and many document, search and relational databases now add vector search as a feature.

Q34. Do NoSQL databases support transactions now?

Many do, within limits. MongoDB supports multi document ACID transactions on replica sets since version 4.0 and on sharded clusters since 4.2. DynamoDB offers transactions across items. Cassandra offers lightweight transactions on a single partition. Check the scope and the cost, since transactions across shards are slower.

Q35. What is the difference between a data lake, a data warehouse and a NoSQL database?

A data warehouse stores cleaned, structured data for reporting. A data lake stores raw data of any form cheaply for later processing. A NoSQL database serves live applications with fast reads and writes. They answer different needs, and one architecture often uses all three.

Scenario Questions (Experienced)

State the access pattern and the consistency need before you name a product.

Q36. Which database would you choose for a shopping cart, and why?

A shopping cart is read and written by user key, needs low latency, and can tolerate short term inconsistency, so a key value or document store fits, such as DynamoDB or Redis with persistence. Store the cart as one item keyed by the user or session, set an expiry for abandoned carts, and write the order itself to a transactional database.

What the interviewer is listening for: You name the access pattern, and you keep the order record in a transactional store.

Q37. Which database suits an application that stores billions of sensor readings?

Choose a store built for append heavy, time ordered data, such as Cassandra or a time series database. Partition by sensor and a time bucket so no partition grows without limit, cluster rows by time, apply time to live for old data and aggregate older data into summaries. Test the write rate with realistic load.

Q38. One shard in your cluster is far busier than the others. What do you do?

Check the shard key distribution and the traffic by key to find a hot key or a skewed range. Fix it by choosing a better key, adding a hash or salt to spread the hot key, splitting the hot range, or caching the hot items. Plan any resharding carefully, since moving data is costly.

Q39. Users sometimes see old data after updating their profile. How do you fix it?

The read is probably served by a lagging replica. Route a user own reads to the primary for a short time after a write, which gives read your writes behaviour, or use a read concern or consistency level such as quorum for that query. Accept eventual consistency where a delay does not matter.

Q40. You must migrate a relational database to NoSQL. How do you plan it?

First list the queries and check that they fit the new model. Model the data around them, migrate a copy and run both systems in parallel, comparing results. Move reads, then writes, in small steps with a rollback plan. Keep relational data where joins and transactions matter, as a migration is not always the best answer.

Q41. You need strong consistency across regions with a NoSQL store. What are the options?

Strongly consistent reads across regions cost latency, because writes must be confirmed in more than one region. Options are a single primary region with failover, a database with global consensus such as Spanner or a NewSQL system, or tuned quorum settings at some cost in speed. Decide whether each operation truly needs it.

Common questions about NoSQL interviews

What topics should I prepare for a NoSQL interview?

Prepare the four database types, the CAP theorem, consistency models, replication, sharding and data modelling from the queries. Then learn one product in each family in depth, such as Redis, MongoDB and Cassandra. Be ready for scenario questions where you must choose a store and justify it.

Which NoSQL database should I learn first?

Start with MongoDB for the document model and Redis for key value work, because both are widely used and easy to run locally. Add Cassandra or DynamoDB to understand distributed design. Choose according to the jobs you want and check what your target employers use.

Is NoSQL replacing SQL?

No. Most companies use both. Relational databases remain the default for transactional data and reporting, and NoSQL stores serve cases that need flexible data, scale or very low latency. Learning to choose between them is the skill interviewers look for.

Do I need to know SQL for a NoSQL role?

Yes. Interviewers expect SQL fluency, since many NoSQL systems offer SQL like languages and you will move data between systems. Knowing the relational model also helps you explain trade offs clearly.

How can I practise NoSQL at home?

Run Redis and MongoDB in containers, model a small shop in each, and write the queries your design needs. Then run a three node Cassandra cluster or use a free managed tier, and test what happens when you stop a node. Note the results, because interviewers ask about experience.

A four week plan to prepare

Use this plan if you have about a month before your interview.

Practise with a trainer

If you want to practise these questions with a trainer and work on hands on projects, you can book a free demo class for the Prwatech Big Data course. It covers NoSQL databases, distributed data processing and hands on projects.

Contact the learning team for current batch dates and fees.

Written by Mithun Ray, data engineering trainer at Prwatech. Reviewed by Avishekh Verma. Last updated October,2026.