Top 50 NoSQL Interview Questions (2026)

NoSQL is a family of databases that don't use the relational table model. The name means 'not only SQL'. Data gets stored in flexible shapes: documents, key-value pairs, wide-column rows, or graph nodes, matching the application instead of forcing it into rows and columns.

Teams use it when they need to scale writes and storage across many machines, handle data that doesn't fit a fixed schema, or evolve the model quickly without heavy migrations. It's a fit for large, fast-changing, or denormalized data, not a blanket replacement for relational databases.

There are four common families. Document stores (MongoDB, Couchbase) keep data as self-contained documents like JSON. Key-value stores (Redis, DynamoDB) map a key to an opaque value for fast lookups. Wide-column stores (Cassandra, HBase) organize data by column families for huge write volumes. Graph databases (Neo4j) store nodes and edges for relationship-heavy queries.

Each fits a different access pattern. The mistake is treating NoSQL as one thing. Naming the four families and one use case each is what the question checks.

A relational database stores data in tables with a fixed schema and links records with foreign keys and joins, giving strong ACID transactions. A NoSQL database uses a flexible model (document, key-value, wide-column, or graph), often relaxes the fixed schema, and is built to scale horizontally across many machines.

The core trade is structure and strict consistency versus flexibility and scale. Relational shines for complex queries across related entities and strict correctness. NoSQL shines for large-scale, denormalized, or fast-changing data with a known access pattern.

A document is a self-contained record stored in a format like JSON or BSON, holding fields, nested objects, and arrays. Unlike a table row, it doesn't have to match a fixed schema, so two documents in the same collection can have different fields.

A collection is a group of documents, roughly like a table but without an enforced structure. The appeal is that a document can hold everything an app reads together (a user plus their addresses and orders) in one place, so a single read returns the whole object.

A collection is a group of documents in a document database, similar to a table in a relational one, except it doesn't enforce a schema across its documents. A document maps loosely to a row, and a field maps to a column.

The key difference: a table forces every row to share the same columns, while a collection lets documents vary. That flexibility is useful when records naturally differ, but it moves the burden of consistency into your application code instead of the database enforcing it.

A key-value store maps a unique key to a value, and the database treats the value as opaque: you look it up by key, and that's the main access pattern. Redis and DynamoDB are common examples. Lookups are fast because there's no query planning or joins, just a direct key access.

You use it for caching, session storage, feature flags, rate limiting, and queues, anywhere you need very fast reads and writes by a known key. The limit is that you generally can't query by the value's contents, only by the key, so it's not a fit for rich ad-hoc queries.

It means the database doesn't force every record to match a predefined structure. You can add a field to one document without altering a table or running a migration, and different documents in the same collection can hold different fields.

Schema-less doesn't mean no structure. Your application still expects certain shapes, so the schema moves from the database into your code and your discipline. Flexible schema is helpful for evolving data, but it makes validation and data quality your responsibility, which is why many teams add schema validation back on top.

You insert a document, find documents by a filter, update fields with an operator, and delete by a filter. In MongoDB the operations are insertOne, find, updateOne, and deleteOne, and queries are expressed as documents that describe what to match.

The mental shift from SQL is that there's no separate query language string. You pass filter and update objects, and updates use operators like $set to change specific fields rather than replacing the whole document.

BSON is a binary-encoded form of JSON that MongoDB uses to store and transfer documents. It keeps JSON's structure (objects, arrays, nested fields) but adds types JSON lacks, like dates, 64-bit integers, decimals, and binary data, and it's designed to be fast to scan and skip through.

So you write and read what looks like JSON, but under the hood it's stored as BSON. The practical wins are richer types (a real date instead of a string) and efficient traversal, since BSON records field lengths that let the engine skip fields quickly.

Most NoSQL databases give every record a unique identifier. In MongoDB it's the _id field, auto-generated as an ObjectId if you don't set one. In key-value and wide-column stores, the key you choose is the primary way you fetch and distribute data.

The difference from relational primary keys is that in distributed NoSQL the key often doubles as the partition key, so it decides both uniqueness and which node the data lives on. That makes key choice a bigger deal than it is in a single-node relational table.

Choose relational when you need strong transactional guarantees across multiple records (money moving between accounts), complex ad-hoc queries that join many related entities, or a schema you want the database itself to enforce strictly. Relational systems are built for exactly these cases, and decades of tooling make them hard to beat there.

NoSQL is a fit when the access pattern is known and you're optimizing for scale, flexible shapes, or high write volume. Being willing to say 'a relational database is the right choice here' is a strong signal; reflexively picking NoSQL for everything is a red flag.

MongoDB is a general-purpose document database that stores data as flexible BSON documents in collections. It gives you rich queries, secondary indexes, an aggregation framework, and built-in replication and sharding, so it works for a wide range of applications rather than one narrow use case.

The problem it solves is storing data that maps naturally to objects in your code without flattening it into tables and joins. You keep related data together in one document, evolve the shape as the app changes, and scale out by sharding when you outgrow a single machine.

A read-heavy workload benefits from caching, read replicas, and indexes, and many databases handle it well. A write-heavy workload is harder: you need a design that spreads writes across nodes without a single bottleneck, which is where wide-column stores like Cassandra earn their keep.

Knowing your ratio guides the choice. If you're taking huge volumes of writes (sensor data, event logs, clickstreams), a NoSQL store built for write scale fits. If you're mostly reading with occasional writes, the model matters less and caching does a lot of the work.

Embedding stores related data inside the same document (a user's addresses as an array in the user document). Referencing stores the related data separately and keeps an id that points to it, similar to a foreign key. Embedding gives one fast read; referencing avoids duplication.

The rule of thumb: embed data that's read together and doesn't grow without bound; reference data that's large, shared across many parents, or grows unboundedly. Getting this call right is the heart of document modeling.

Eventual consistency means that after a write, replicas may briefly hold different values, but given enough time and no new conflicting writes, they all converge to the same value. You trade an immediate guarantee that every read sees the latest write for higher availability and lower latency.

In practice a read right after a write might return stale data from a replica that hasn't caught up yet. Many NoSQL systems default to this because it lets them stay available during network trouble, but they often let you request stronger consistency per operation when you need it.

ACID (atomicity, consistency, isolation, durability) is the guarantee relational databases give: a transaction fully happens or fully doesn't, and data stays valid and durable. BASE (basically available, soft state, eventually consistent) describes the looser model many NoSQL systems take: stay available, tolerate temporary inconsistency, and converge over time.

The trade is strict correctness versus availability and scale. ACID keeps every read exact but is harder to scale across many nodes. BASE accepts brief staleness to stay up and spread load. Many systems now sit in between, offering tunable guarantees, so the honest answer is that it's a spectrum, not a strict either-or.

No. A document database stores JSON-like documents, but it adds the machinery a plain file can't: secondary indexes so you query fields without scanning everything, an query engine for filters and aggregations, atomic updates to individual documents, and built-in replication and sharding for durability and scale.

So the data looks like JSON, but you get database features on top: fast indexed queries, concurrency control, and horizontal scaling. Treating it as 'just JSON in a file' misses why you'd pick it over writing files yourself, which is exactly what this question is probing.

The CAP theorem says a distributed data store can guarantee at most two of consistency, availability, and partition tolerance at the same time. Since network partitions are a fact of life in any distributed system, partition tolerance isn't optional, so the real choice during a partition is between consistency and availability.

A CP system (like MongoDB with strong reads, or HBase) keeps data consistent by refusing some requests during a partition. An AP system (like Cassandra or DynamoDB in their default modes) stays available by serving possibly-stale data. The practical answer is that you pick C or A per situation based on whether stale reads or unavailability hurts your app more.

Some NoSQL databases let you tune consistency per operation instead of picking one setting forever. You set how many replicas must acknowledge a write (W) and how many must respond to a read (R). If reads and writes overlap on enough replicas, you get strong consistency; if not, you get faster but possibly stale reads.

The quorum rule is that when the read replicas plus the write replicas exceed the total replicas (R + W > N), at least one replica in the read set has the latest write, so reads see it. Lowering R and W boosts speed and availability; raising them boosts consistency. Tuning this per query is how you balance the two.

An index is a separate data structure (usually a B-tree) that maps field values to the documents that contain them, so a query can jump straight to matches instead of scanning every document. Without a matching index, the database does a full collection scan, which gets slow as the collection grows.

The cost is real: every index takes storage and must be updated on every write, so indexes slow down inserts and updates. The discipline is to index the fields your queries actually filter and sort on, and no more. Too few indexes means slow reads; too many means slow writes and wasted space.

A compound index covers multiple fields in a defined order, so it can serve queries that filter on a prefix of those fields. An index on { status, createdAt } helps queries filtering by status, or by status and createdAt together, but not queries filtering by createdAt alone.

Order matters because the index is sorted by the first field, then the second within that, and so on, like a phone book sorted by last name then first name. This is the prefix rule: a query must use a leading subset of the index fields to benefit. Getting the order right, usually equality fields first then range or sort fields, is what makes a compound index effective.

An aggregation pipeline runs data through a sequence of stages, each transforming the documents that flow into it: filter, group, sort, reshape, join. It's how you do analytics and reporting inside the database, the NoSQL answer to GROUP BY and computed queries in SQL.

You use it when a plain find isn't enough: counting orders per customer, computing running totals, joining a lookup, or bucketing values. Each stage does one job, and putting a match stage early to shrink the data before heavier stages is the main performance lever.

Replication keeps copies of data on multiple nodes for durability and availability. In a primary-secondary model (MongoDB replica sets), one node takes writes and replicates to secondaries that serve reads and can be promoted if the primary fails. In a peer-to-peer model (Cassandra), every node can accept writes and they replicate among each other with no single primary.

The trade is where writes go. Primary-secondary is simpler to reason about but the primary is a write bottleneck and a failover point. Peer-to-peer removes the single write node so it scales writes and survives node loss, at the cost of conflict handling and eventual consistency being the norm.

Sharding splits a dataset across multiple nodes so no single machine holds it all, letting you scale storage and throughput horizontally. Each shard holds a subset of the data, chosen by a shard key. A router or coordinator sends each query to the shard or shards that hold the relevant data.

The database decides placement from the shard key using either range partitioning (contiguous key ranges per shard) or hash partitioning (hash the key to pick a shard). Hashing spreads writes evenly and avoids hot ranges; range partitioning keeps nearby keys together for range scans but risks hotspots. The shard-key choice is the single most important sharding decision.

A good shard key spreads reads and writes evenly across shards and keeps data that's queried together on the same shard. High cardinality (many distinct values) and a value that matches your common query filter are the traits to look for.

A bad key creates hotspots. A monotonically increasing key like a timestamp sends every new write to the same shard, so one node gets hammered while others sit idle. A low-cardinality key (a boolean) can't spread data at all. The failure mode is uneven load that no amount of adding nodes fixes, because the key funnels traffic to one place.

Denormalization duplicates data so a read gets everything in one shot without joins. The upside is fast reads and a data shape that matches your access pattern. The downside is that duplicated data must be kept in sync: when the source changes, you update every copy, so writes get more complex and there's a window where copies disagree.

The call comes down to your read-to-write ratio and how tolerant you are of brief staleness. For read-heavy data that changes rarely (a product name shown on many orders), denormalizing pays off. For data that changes often and must stay exact everywhere, the update cost can outweigh the read speed.

Many do now, though it varies. A single-document write in MongoDB is atomic by default, and MongoDB added multi-document ACID transactions in later versions. Other systems support lightweight transactions or conditional writes (Cassandra, DynamoDB) but not full cross-node ACID cheaply.

The honest framing is that NoSQL transactions exist but carry a cost, especially across shards, and the design intent is usually to avoid needing them by keeping related data in one document. So you can use a transaction when you must, but leaning on single-document atomicity through good modeling is the idiomatic path.

A TTL (time-to-live) index automatically deletes documents once they pass a set age, and many key-value stores let you set an expiry per key so it self-removes. The database handles the cleanup on its own in the background, so you don't have to run a scheduled delete job or remember to prune old data yourself.

It's useful for data that's only valid for a while: sessions, cache entries, one-time tokens, and time-boxed logs. Setting an expiry keeps the dataset from growing without bound and removes stale data automatically, which is both a storage and a correctness win.

A wide-column store groups data into column families (tables), and each row is identified by a partition key that decides which node holds it, plus optional clustering columns that sort data within the partition. Rows in the same table can have different columns, and a single partition can hold many rows sorted by the clustering key.

The mental model is 'query-first': you design the table around the exact queries you'll run, because you can only efficiently query by the partition key and clustering order. There are no ad-hoc joins, so if you need a new query pattern, you often create a new table with a different key, duplicating data on purpose.

A graph database wins when relationships are the main thing you query: social networks, recommendation engines, fraud rings, permission hierarchies, and anything where you traverse connections many hops deep. Nodes hold entities, edges hold relationships, and traversing an edge is a cheap, direct operation.

In a relational database, a deep 'friends of friends of friends' query means many expensive joins that get slower with depth. In a graph database, that traversal stays fast because following edges doesn't require joining tables. If your queries are mostly about how things connect, a graph model fits; if they're about aggregating attributes, it usually doesn't.

You have two options: embed the many side as an array inside the one document, or keep the many side in a separate collection with a reference back to the parent. Embed when the child list is bounded and read with the parent (a blog post and its handful of tags). Reference when the list is large or unbounded (a user and their millions of events).

The deciding factors are how big the child set can grow, whether the children are read on their own, and how often they change. A document has a size limit (16MB in MongoDB), so an unbounded array will eventually break, which is the concrete reason large one-to-many relationships get referenced instead of embedded.

You ask the database to explain the query. In MongoDB, explain("executionStats") shows the plan: whether it used an index scan (IXSCAN) or a full collection scan (COLLSCAN), how many documents it examined versus returned, and how long it took. A big gap between examined and returned counts means the query is scanning too much.

The workflow is: run explain, look for a collection scan on a slow query, add or adjust an index to cover the filter and sort, then re-run explain to confirm it now uses the index and examines far fewer documents. It's how you turn a guess about performance into a measurement.

Relational modeling normalizes first: split data into tables with no duplication, then join at read time. NoSQL modeling flips it. You start from the queries the app runs, then shape the data so each common query is a single fast read, which usually means denormalizing and grouping fields that are read together.

So the process is query-first: list the access patterns, cluster the fields each read needs, embed or reference accordingly, then choose keys and indexes to serve the top queries. You accept some duplication in exchange for reads that don't join across nodes. Modeling by entities and normalizing, the relational instinct, is the most common way NoSQL schemas go wrong.

Skip-and-limit pagination (skip N, take M) is simple but slow at depth, because the database still walks past all the skipped documents, so page 1000 gets expensive. The scalable pattern is cursor or keyset pagination: sort by an indexed field and remember the last value seen, then fetch the next page as 'where sort field is greater than the last value'.

Keyset pagination stays fast at any depth because it seeks straight into the index instead of counting past skipped rows, and it stays stable when new data is inserted. The catch is you can't jump to an arbitrary page number, only next and previous, which is usually fine for infinite-scroll and API feeds.

PACELC extends CAP by describing behavior when there's no partition. It reads: if there's a Partition (P), trade Availability (A) against Consistency (C), Else (E) when running normally, trade Latency (L) against Consistency (C). CAP only talks about the partition case; PACELC captures the everyday trade too.

That matters because most of the time there's no partition, yet you still pay for consistency in latency: waiting for more replicas to acknowledge a write is slower. A system like Cassandra is PA/EL (chooses availability and low latency), while a strongly consistent store is PC/EC. PACELC is the more honest model because it names the cost you pay during normal operation, not just during failures.

At the strong end is linearizability: every read sees the most recent write, as if there were one copy. Below that, sequential and causal consistency preserve some ordering (causal guarantees that related operations are seen in order) without the full cost of linearizability. Read-your-writes and monotonic-reads are session guarantees that keep a single client's view sane.

At the weak end is eventual consistency: replicas converge over time with no ordering promise between clients. The engineering point is that you rarely need full linearizability everywhere. Causal or session consistency often gives users a coherent experience at much lower cost, and picking the weakest model that still satisfies the requirement is the strong move.

In a leaderless store like Cassandra or Dynamo-style systems, a write goes to all replicas but succeeds once W of them acknowledge, and a read waits for R responses. With R + W > N you get overlap so reads see the latest write. This lets the system stay available even when some replicas are down, as long as a quorum responds.

Hinted handoff covers a temporarily-down replica: a healthy node accepts the write on its behalf and stores a hint, then replays it when the down node returns. Read repair and anti-entropy (Merkle-tree comparison) fix divergence in the background. Together these are how an AP system stays available during failures and still converges afterward.

When any node can accept writes, two clients can update the same key concurrently and you need a rule to reconcile them. The simplest is last-write-wins using a timestamp, but it silently drops one update, which can lose data. Vector clocks (or version vectors) instead detect that two writes were concurrent and let you keep both versions for the application to merge.

The stronger approach is CRDTs (conflict-free replicated data types): data structures like counters and sets designed so concurrent updates merge deterministically without coordination. The right choice depends on the data: last-write-wins is fine for a cache value, but a shopping cart or a collaborative document needs vector clocks or CRDTs so no update is lost.

Design around your queries, not your entities. List the exact read and write patterns first, then shape documents so the common query is a single indexed read. This usually means denormalizing and embedding what's read together, and referencing what's large, shared, or unbounded.

At scale you also watch three things: document size (keep it well under the limit and avoid unbounded arrays), write amplification (denormalized copies that fan out on update), and the shard key (it must match your dominant query and spread load). The senior habit is to prototype the heavy queries against realistic data and run explain before committing to a model, because a schema that reads great at small scale can fall apart when arrays grow and one shard goes hot.

A hot partition is one shard or partition taking a disproportionate share of traffic while others sit idle, so adding nodes doesn't help because the load funnels to one place. It comes from a shard key with skewed access: a monotonic key, a low-cardinality key, or a single popular value (a celebrity account, a mega-tenant).

The fixes depend on the cause. For a monotonic key, hash it or add a random or bucketed prefix to spread writes. For a single hot value, split it across synthetic sub-keys (write sharding) and fan reads back together. For a hot tenant, isolate it onto its own partition or shard. The prevention is choosing a high-cardinality key aligned with the access pattern up front, since re-sharding live data is painful.

Polyglot persistence means using different databases for different jobs in the same system: a document store for the product catalog, Redis for sessions and caching, a wide-column store for the event firehose, a search engine for full-text, maybe a graph for recommendations. Each part gets a database suited to its access pattern.

It's worth it when a single database genuinely can't serve every pattern well and the workloads are large enough to justify the operational cost. The cost is real: more systems to run, monitor, back up, and keep in sync, plus consistency challenges when data spans stores. For a small app, one flexible database is usually the right call. Reach for polyglot when specific workloads clearly outgrow a single engine.

Event sourcing stores an append-only log of events as the source of truth instead of just the current state, and NoSQL append-friendly stores (wide-column, or a document store with immutable event documents) fit the write side well because you're appending a high volume of small immutable records keyed by aggregate.

CQRS (command query responsibility segregation) splits the write model from read models, and NoSQL shines for the read side: you project events into denormalized documents shaped exactly for each query, so reads are single fast lookups. The trade is eventual consistency between the event log and the projections, plus the complexity of rebuilding projections. It fits high-throughput, audit-heavy domains, not simple CRUD apps.

Because documents are flexible, you don't run one big ALTER. Two patterns dominate. Lazy migration writes new documents in the new shape and upgrades old ones on read (migrate-on-read), so the change rolls out gradually with no downtime, and your code handles both shapes during the transition. Bulk background migration runs a job that rewrites documents in batches, with the app tolerating both shapes until it finishes.

The rule mirrors zero-downtime relational migrations: keep the app compatible with old and new shapes at every step, add a schema version field so code knows which shape it's reading, and never make a breaking change in a single deploy while old code still runs. Test the migration on a copy first, and make each step reversible.

the basics that are famously missed: never expose the database to the public internet, require authentication (many NoSQL databases historically shipped with it off), and enforce least-privilege roles so each service reaches only what it needs comes first. Encrypt data in transit with TLS and at rest, and keep credentials in a secrets manager, not in code.

Then guard against injection: NoSQL query injection is real when user input is passed straight into a query object, so validate and type-check inputs and use parameterized query builders. Add network isolation (private subnets, IP allowlists), audit logging of access, and regular patching. The infamous incidents are internet-exposed clusters with no auth, so closing that gap is the first priority.

Replication is not a backup: it copies bad writes and deletes to every replica, so you still need point-in-time backups to recover from a bad deploy, a buggy migration, or human error. Use the database's snapshot mechanism plus an oplog or change-log so you can restore to a specific moment, and store backups in a separate location or account from the live cluster.

For a distributed store, a consistent backup across shards is the hard part: you either coordinate snapshots or accept a per-shard-consistent backup and reconcile. Define RTO and RPO from the business need, automate backups, and, most importantly, rehearse restores regularly, because an untested backup is a guess, and distributed restores fail in ways you only find by practicing.

Watch the signals that predict trouble: per-node and per-partition load to catch hotspots, replication lag so you know how stale secondaries are, and read and write latency percentiles (p99, not just averages) because tail latency is where users feel pain. Track disk usage and compaction activity, since a full disk or a compaction storm takes nodes down.

Add query-level visibility: slow-query logs, scanned-versus-returned ratios to catch missing indexes, and connection-pool saturation. For a distributed store, cluster health (nodes up, gossip state, quorum availability) is the top-level signal. The goal is to see a hot partition or growing replication lag before it becomes an outage, not after.

The classic mistake is picking a document or key-value store for data that's highly relational and queried in many ad-hoc ways. Once the app needs joins across many entities, aggregate reports over arbitrary dimensions, and strict multi-record transactions, a document model forces you to either denormalize heavily (and fight update fan-out) or reinvent joins in application code, both worse than a relational database would have been.

Another is choosing NoSQL 'for scale' at small scale where a single relational instance would have handled the load for years, paying the modeling and consistency costs for a scale you never reach. The honest lesson is that the access pattern and consistency needs drive the choice, not the trend, and picking NoSQL by default is how teams end up rebuilding joins by hand.

Many NoSQL stores (Cassandra, HBase, RocksDB-backed engines) use an LSM tree. A write goes to an in-memory table (memtable) and an append-only commit log, so writes are fast sequential operations, not in-place updates. When the memtable fills, it's flushed to an immutable on-disk file (SSTable). Reads may have to check the memtable plus several SSTables, using Bloom filters to skip files that can't contain the key.

Because data spreads across many immutable files, compaction runs in the background to merge SSTables, drop tombstones (deletion markers), and keep reads efficient. This is why LSM stores are write-optimized (sequential appends) but reads can touch multiple files, and why compaction tuning and tombstone buildup are real operational concerns. Contrast with B-tree stores that update in place, favoring reads over write throughput.

In an LSM-based store, a delete doesn't erase data immediately. It writes a tombstone, a marker that says 'this key is deleted', because the actual data sits in immutable files that can't be edited in place. The real removal happens later during compaction, once the tombstone has propagated to all replicas and a grace period has passed.

The problem is tombstone buildup. If you delete a lot, or repeatedly write and delete in the same partition, reads have to scan through piles of tombstones to figure out what's still live, which slows queries and can even fail them past a threshold. The fixes are avoiding delete-heavy access patterns, using TTLs so expiry is handled cleanly, and modeling so you rarely delete from a hot partition.

Clarify first: expected read-to-write ratio (URL shorteners are extremely read-heavy), scale, and latency target. The core need is a fast lookup from short code to long URL at huge volume, which is a key-value access pattern. A key-value or wide-column store keyed by the short code fits, with a cache (Redis) in front so the hottest links resolve from memory in sub-millisecond time.

Model the short code as the primary and partition key so lookups hit one partition and load spreads evenly (hash the code to avoid hotspots). Store the long URL, creation time, and an optional expiry with a TTL. Generate codes to be uniformly distributed (base62 of a counter, or a hash) so no single partition goes hot. For analytics (click counts), keep that on a separate write path or an append-only counter so it doesn't slow the redirect. The structure that scores is clarify, pick the model from the access pattern, choose a partition key that spreads load, add caching, and separate the hot read path from analytics.