An online retailer's catalog holds items whose attributes differ widely: shoes have sizes and widths, laptops have CPU and memory specs, and some items carry nested lists of variants. Developers want to store each item as one nested JSON record and still query on fields inside it. Which NoSQL type is the most natural fit?

Document databases store self-describing records, usually JSON or a binary JSON variant, where each document can have its own set of fields, nested objects and arrays. There is no requirement that every product share the same columns, so a shoe and a laptop can live in the same collection with different attributes. Crucially, the engine understands the document's internal structure, so it can index and filter on nested fields such as a variant's color or a laptop's memory size. A key-value store can hold the same JSON as a value, but it treats that value as an opaque blob retrieved only by its key; filtering on attributes inside it would require reading every value in application code. A graph database is designed around nodes and edges for traversing relationships, which is not the primary need of a catalog with variable attributes. A time-series database optimizes timestamped measurements and time-window aggregation, which does not match product records that are read and updated by product attributes. Exam caveat: a relational table with a JSON column can also hold such data, but the question asks which NoSQL type is the natural fit for variable-schema nested records. Operational check: load two products with different attribute sets into one collection, create an index on a nested field, and confirm a filter on that field uses the index.