NoSQL · Data models beyond tables
What are common NoSQL mistakes?
Short answer
Common mistakes are modelling like a relational database, letting arrays grow unbounded, choosing low-cardinality keys, scanning large tables, ignoring consistency, skipping backups and treating a cache as a system of record.
Most NoSQL incidents come from applying relational habits without the relational engine. The database will accept the write, but the access pattern or the distribution will fail later under real volume.
The recurring ones
- Modelling entities first and discovering the query does not fit the key
- Embedding an unbounded array that eventually hits the document or item limit
- Choosing a low-cardinality partition key such as status or date
- Using a scan or full collection query on a large dataset
- Assuming eventual consistency is invisible to users
- Indexing every field and slowing every write
- Running without tested backups or a restore plan
- Treating a cache as durable storage
Another mistake is ignoring operational work. Compaction, repair, rebalancing and index builds are part of running the database, not background details. A design that is fast in a laptop test can still be impossible to operate at scale.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1Which mistake causes the most production incidents?
- 2How do you catch a bad key design before launch?
- 3Why is treating a cache as a database dangerous?
- 4What operational task do teams most often underestimate?
Say it in the interview
The most common mistake is modelling like a relational database and only discovering at scale that the query does not match the key. Others are unbounded arrays, low-cardinality partition keys, scans, ignored consistency and missing backups. I also see teams treat a cache as durable storage or forget that compaction and repair are ongoing work. The fix is to validate access patterns and partition sizes with production-like data before launch, and to rehearse failures and restores.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live NoSQL mock interview and get scored feedback on depth, clarity and confidence.