NoSQL database types for data engineering interviews

Why DE interviews ask about NoSQL

If you sit a data engineering loop at Stripe, Uber, or DoorDash, expect a 20-30 minute block on NoSQL trade-offs — not deep ops on any single engine, but a coherent map of when key-value, document, wide-column, graph, and time-series stores each pull their weight. Interviewers want you to justify a storage pick against a workload, not recite vendor feature lists.

The trap candidates fall into is treating NoSQL as one thing. "We'd use NoSQL because the schema is flexible" gets you politely walked to the door. The five families have nothing in common architecturally — Redis and Neo4j are about as similar as a hash map and a graph traversal library.

Senior DE rounds drill into CAP positioning, tunable consistency, and operational cost at scale. You won't be asked to memorize Cassandra's gossip protocol — you'll be asked which trade-offs you accept when you write CONSISTENCY QUORUM instead of CONSISTENCY ONE.

Key-value: Redis and DynamoDB

The simplest model in the family: every record is key → value, and the only fast operation is "fetch the value for this key." Range scans either don't exist or come with painful caveats. The pay-off is sub-millisecond reads when the working set fits in memory, which is why every serious web stack runs Redis somewhere.

Redis is in-memory, single-threaded per shard, and astonishingly versatile despite the minimal data model. The typical hats it wears:

- Cache layer in front of Postgres or MySQL
- Session store with TTL eviction
- Rate limiter via INCR + EXPIRE
- Pub/Sub for fan-out notifications
- Streams as a lightweight queue
- Sorted sets for leaderboards and time-bucketed counters

DynamoDB is AWS's managed key-value/document hybrid. It's the boring-but-correct pick when you need single-digit-millisecond latency, predictable cost per request, and no ops team. The two access patterns are GetItem by primary key and Query within a partition by sort key — design your table around those, not around your domain model.

Document: MongoDB

A document database stores schema-flexible JSON-like records — nested arrays, embedded sub-objects, the works. The pitch is "no migrations": you add a field by writing a document with that field, no ALTER TABLE required. The reality is "no migrations, until you need them," at which point you write a one-off backfill script and pray nothing else writes during the run.

MongoDB dominates this category. Worth knowing for interviews:

• Aggregation framework with $match, $group, $lookup, $project stages
• Indexes including compound, multikey, text search, and geospatial
• Multi-document transactions since 4.0 inside a replica set, distributed since 4.2
• Sharding via a shard key — choose it carefully or you'll be migrating data in 18 months

Document databases shine for semi-structured catalogs (think Notion's block tree, Figma's design files, a product catalog where every category has different attributes) and for user profiles where the schema legitimately varies per customer segment. They struggle the moment you need joins — $lookup works but performs like a left join in 1998.

This is also why every "MongoDB at scale" post-mortem reads the same: the team modeled their data with deep embeds, hit a query they didn't anticipate, and ended up with a tangle of $lookup pipelines that nobody wants to touch.

Wide-column: Cassandra and ScyllaDB

This is the family interviewers love because the CAP positioning is unambiguous: wide-column stores like Cassandra and ScyllaDB sit firmly in the AP corner — available and partition-tolerant, eventually consistent by default. The data model is a table with a partition key, optional clustering keys, and columns — superficially SQL-shaped, but distributed-first under the hood.

The killer property is linear write scalability. Add nodes, get more write throughput, no application changes. Multi-datacenter replication is built in. Consistency is tunable per query via CONSISTENCY ONE, QUORUM, ALL — you trade latency for safety on a request-by-request basis.

Workloads that fit:
- Time-series events (clickstream, sensor data, IoT)
- Chat message history keyed by conversation_id
- High-write OLTP where eventual consistency is acceptable
- Multi-region writes where local-DC latency matters

Workloads that don't:
- Ad-hoc analytics — there are no joins, period
- Strong-consistency financial ledgers
- Anything requiring secondary index queries at scale

ScyllaDB is a rewrite of Cassandra in C++ with a shard-per-core architecture. Same protocol, same query language (CQL), often 3-5x throughput on identical hardware. If you're greenfielding a wide-column workload in 2026, default to Scylla unless your shop has deep Cassandra ops experience.

Graph: Neo4j and Neptune

Graph databases store nodes and edges with properties, and they exist for one reason: multi-hop traversals are stupidly expensive in relational stores. If your dominant query is "find friends-of-friends-of-friends who like jazz," every additional hop is another self-join in SQL, and the planner gives up around hop four.

Neo4j is the reference implementation; Amazon Neptune is the managed equivalent on AWS. The query language for Neo4j is Cypher, which reads like ASCII art:

MATCH (u:User {id: 42})-[:FRIEND]->(:User)-[:FRIEND]->(fof:User)
WHERE NOT (u)-[:FRIEND]->(fof)
RETURN fof.name, count(*) AS mutual_friends
ORDER BY mutual_friends DESC
LIMIT 10

Real production fits: social graphs, fraud detection (find rings of accounts sharing devices and payment methods), recommendation systems that traverse a knowledge graph, and identity resolution across customer records. The common thread is "the structure of relationships is the data."

What graph databases do badly: OLTP that's really row-oriented, analytics aggregations over the full graph, and anything where the relationships are simple enough to model as foreign keys.

Time-series: InfluxDB, TimescaleDB, ClickHouse

Time-series stores optimize for append-heavy writes ordered by timestamp, with aggressive compression on the time axis and built-in downsampling and retention policies. They're a separate family because the access pattern — "give me the average of metric X over the last 5 minutes, bucketed by 10-second windows" — is brutally inefficient in row-store SQL.

TimescaleDB is the right answer when your time-series workload needs to join to existing Postgres tables — customer dimensions, billing data, anything relational. You get hypertables (auto-partitioned by time) plus the entire Postgres ecosystem. ClickHouse wins when the query pattern is analytical scans over billions of rows, which is why it ends up powering most observability backends at scale.

When NoSQL beats SQL — and when it doesn't

Most production stacks ship polyglot persistence: Postgres for the system of record, Redis for caches and sessions, ClickHouse or Snowflake for analytics, occasionally Elasticsearch for search. Pure NoSQL shops are rare and tend to regret it once they need a JOIN. Pick the boring tool first — reach for NoSQL only when a specific access pattern Postgres can't serve justifies it.

Common pitfalls

Treating MongoDB as a drop-in OLTP replacement for Postgres. Pre-4.0 MongoDB had no multi-document transactions, and even today transaction throughput sits well below what Postgres handles trivially. Teams that picked Mongo for schema flexibility and later needed transactional guarantees over invoices or order state end up in six-month migrations. The fix: use Postgres for the ledger, Mongo (if at all) for genuinely document-shaped catalog data.

Cassandra without a partition key strategy. The biggest production incident pattern in wide-column stores is the hot partition — one key receiving the vast majority of writes while the rest of the cluster sits idle. Classic example: user_id as partition key for an event stream where one bot account generates 99% of events. Fix: compose the key with a time bucket or hash suffix so writes spread evenly, and target under 100 MB per partition.

Redis without persistence configured. Out of the box Redis is in-memory only and a process restart wipes everything. RDB snapshots and AOF append-only-file are both available; for data you can't afford to lose, enable AOF with fsync everysec. If you're using Redis purely as a cache, no persistence is fine — but be explicit about that choice.

Picking NoSQL because the schema is "flexible." Schema flexibility on the database side just moves the problem to the application layer, invisible to your DBA tools and migration framework. Eighteen months in, nobody knows what fields a user document might contain. Enforce schema in the application — JSON Schema, Pydantic, Zod — even when the database doesn't.

Joining documents with $lookup at query time. MongoDB's $lookup performs a left join, but the optimizer is nowhere near as smart as Postgres's. If your aggregation pipelines stack three or more $lookup stages, you've reinvented a relational database with a worse planner. Denormalize aggressively or admit you needed Postgres all along.

Running graph algorithms on Postgres via recursive CTEs. Works for two or three hops. By hop four on a million-node graph, the query is unkillable. If multi-hop traversal is a core query, the right tool is a graph database — even if you keep the rest of the stack relational and sync nodes/edges into Neo4j via CDC.

Related reading

• Cassandra for data engineering interviews
• ClickHouse as a DWH
• CAP theorem for systems analyst interviews
• CDC and Debezium
• Connection pooling for data engineers

If you want to drill DE storage and architecture questions like these every day, NAILDD ships a daily question loop with 1,500+ interview problems across exactly this surface area.

FAQ

Does MongoDB really support ACID transactions now?

Yes, with caveats. Since MongoDB 4.0 you get multi-document transactions inside a replica set; since 4.2 distributed transactions across shards. Both work, but per-transaction overhead is meaningfully higher than Postgres — Mongo's own docs recommend keeping transactions short, touching few documents, and preferring single-document atomic operations when possible. For a financial ledger, Postgres is still the safer default.

Cassandra vs ScyllaDB — which should I pick in 2026?

ScyllaDB is a C++ rewrite with a shard-per-core design, and on identical hardware delivers 3-5x throughput at lower tail latency. It speaks the Cassandra wire protocol and CQL, so applications port without changes. The reason to stay on Cassandra is operational inertia or specific ecosystem tooling. For a greenfield wide-column workload, ScyllaDB is the better default.

When is Neo4j worth the operational overhead vs Postgres with recursive CTEs?

When multi-hop traversal is a core query pattern, not an occasional one. Friend-of-friend recommendations, fraud-detection graph traversal, or identity resolution across linked records — Neo4j or Neptune will outperform Postgres by orders of magnitude. For one or two occasional hops, a recursive CTE is fine and saves you a whole database to operate.

Is ClickHouse a NoSQL database?

Technically it's a columnar OLAP database with SQL as the query interface, so it doesn't fit the "NoSQL" label cleanly. It's grouped with NoSQL in interview conversations because it solves the same problems wide-column and time-series stores do — analytics-scale ingestion and scans — at a different design point. Know what it's good at; don't get pedantic about taxonomy.

How do I pick a partition key for Cassandra or DynamoDB?

Two rules: distribute writes evenly, and keep partitions bounded in size. For event streams, compose the key with a time bucket (user_id:2026-05) so each partition stays small and writes spread over time. For high-cardinality lookups, the partition key should match the primary access pattern — if you query "events for user X in time range Y," that's user_id as partition key, timestamp as clustering key. Get this wrong and no tuning saves you.

What's the simplest NoSQL story to tell in a DE loop?

"Postgres for the system of record. Redis for hot caches and rate limiting. ClickHouse or Snowflake for analytics. Cassandra or DynamoDB if I need high-write throughput with eventual consistency. Neo4j if the dominant query is multi-hop traversal. I default to relational and only reach for NoSQL when a specific access pattern justifies it." That's the answer an interviewer stops probing — it shows judgment, not enthusiasm for shiny tools.