NoSQL data modeling for query-first database schemas

Monthly transaction buckets collapsed a predicted 280GB index to 30GB in MongoDB's financial-services example. That's NoSQL data modeling in a nutshell: organise storage around application queries and workflows, not business entities. This guide walks through choosing document boundaries, planning keys and indexes, and deciding where duplication belongs.

For anyone running an application database, the stakes are database calls, query performance, and the compute bill as usage grows. ScyllaDB's modeling guidance draws a straight line from poorly designed models to bottlenecks and higher support costs. Their core recommendation: store what a query needs together, so the application doesn't have to assemble it through repeated round-trips.

The read pattern drives design, not the other way around

ScyllaDB frames this as moving from data-first to query-first. Duplicated values across rows are acceptable when they let a query return exactly what it needs without dragging along unrelated data.

MongoDB starts with business requirements and application-user needs. They recommend expressing the domain in a usable form — JSON documents, say — then considering the access patterns that storage must support. These approaches fit together: describe the domain, but let the workflow influence how its data is physically organised.

Some NoSQL databases popularized the notion of "loose schema", often misunderstood as "schemaless" — but there is always a data model in the database, the application, or the mind of the developer.

— ScyllaDB's modeling guide

Start with the user-visible outcome rather than a catalogue of entities. For an application screen, that means describing what the user needs to see and which data must arrive together. The entity list still helps describe the business; it doesn't, by itself, settle the storage layout.

Different databases, different shapes

NoSQL databases don't share one physical model. MongoDB breaks down the storage shapes and their access methods:

This distinction changes what "keep relevant data together" means. For a document database, it can mean embedding related information within a document. ScyllaDB's wide-column guidance instead discusses tables and partitions, with a single partition targeted for an individual user query.

The column-family data model is therefore a different design starting point from a nested document. Both can support query-first thinking, but copying a document layout into a wide-column database isn't the design process either source describes.

Sketch the document around a complete read

A document can express a business object while keeping related information available together. MongoDB uses automobiles as an example of a domain where component systems can be shared and optional add-ons vary.

For an illustrative vehicle-details screen, I'd sketch the following document before touching indexes. This illustrative document shows the read the screen needs.

{
  "vehicle_key": "example-vehicle",
  "model": "example-hatchback",
  "systems": {
    "powertrain": "electric",
    "climate_control": "automatic"
  },
  "optional_add_ons": [
    "parking_camera",
    "heated_seats"
  ]
}

Suppose the screen needs the model, component details, and selected add-ons together. This document makes that intended read visible during design. The review can then ask whether those fields actually belong to the same user workflow, rather than assuming every fact associated with a vehicle must live here.

NoSQL data modeling also requires looking beyond the document's appearance. MongoDB asks designers to consider how often documents change, which queries run, and which fields need indexes. A plausible JSON structure is a starting point for those decisions, not evidence they've already been made.

A practical NoSQL data modeling review sequence

Review the schema against actual application requests. The following sequence turns the sources' recommendations into a practical design review for an existing service or a proposed feature.

1. Write down the business workflow and the data each request needs. Include how users query that data and how frequently those queries occur. MongoDB recommends beginning with user requirements and also reviewing actual queries, because observed patterns can identify useful index candidates.

2. Map each request to its storage reads. Check whether its relevant data is available in a single table, document, or other appropriate store. ScyllaDB recommends this arrangement to avoid multiple calls for the same user request. Where repeated table calls remain necessary, its guidance proposes denormalising by copying data when it's first written.

3. Review keys, partitions, and indexes for the chosen database. MongoDB's schema-design goal is to plan keys and indexes that support application queries and workflows. For ScyllaDB specifically, the guidance targets a single partition for an individual user query. Keep that database-specific distinction visible instead of treating all NoSQL stores as interchangeable.

4. Check update frequency and storage granularity together. MongoDB describes time-series options including a document per data point or buckets containing a minute's data. Its transaction example shows that document grouping can also affect predicted index size. Compare the grouping with the application's access requirements rather than choosing a bucket solely because another workload benefited from it.

5. Include schema versioning and future revisions in the design. ScyllaDB explicitly retains schema versioning as a consideration, while MongoDB describes schema design as iterative throughout an application's lifetime. Revisit the layout when business requirements, query patterns, or the data change; flexibility permits revision, but doesn't remove the need to plan it.

A useful review result is a connection between each query and the storage decisions supporting it: the required fields, their grouping, and the relevant keys or indexes. That makes later changes easier to discuss in terms of application needs rather than whether a document or table merely looks tidy.

Duplication and sizing stay open questions

Neither source supplies a universal rule for how much data to duplicate. ScyllaDB encourages duplication for query efficiency but explicitly acknowledges advanced cases where avoiding it is preferable. Their argument that efficient writes support denormalisation is made in the context of ScyllaDB, not as a measured guarantee for every NoSQL database.

Treating duplication as the default leaves copied values without a synchronisation plan. That remains an unresolved design question when a proposed model depends on several copies staying aligned. Schema flexibility alone doesn't answer it.

The index-size example has a similar boundary: MongoDB reports a particular customer's transaction-modeling decision, not a general reduction that every monthly bucket will deliver. NoSQL data modeling still depends on the workload being designed.

Change the layout when a query demands it

I'd change an existing layout when a named workflow reveals unnecessary database calls, unsuitable document grouping, or missing query support — and leave it alone when its reads already match the application's needs. Duplication is a tool for a specific retrieval problem, not a requirement to copy every field.

For a new service, the corresponding decision is to settle the important reads before treating the physical schema as finished. Both sources leave room for later revision. The useful commitment is to a model that serves the current workflow, with its query assumptions and unresolved choices made explicit — starting with the next screen or endpoint that forces a rethink.