NoSQL Data Modeling: Design from Queries, Not Entities

The most expensive mistake teams make with NoSQL is bringing relational habits with them. They create a “table” per entity, sprinkle in references, and then discover — usually in production — that the database they chose for speed now needs twelve round-trips to render one screen. NoSQL databases are not “schemaless relational databases.” They reward a fundamentally different modeling process, and this post explains it.

Audience: engineers who know relational modeling and are designing for DynamoDB, MongoDB, Cassandra, Redis, or similar systems for the first time.

The Inversion: Relational Models Data, NoSQL Models Queries

Relational modeling works forward from the domain: identify entities, normalize, and trust the query optimizer to answer any question with joins. That flexibility is the relational model’s superpower — and its cost, because joins across distributed machines are expensive, which is precisely why most NoSQL systems don’t offer them (or offer them reluctantly).

NoSQL modeling works backwards from the access patterns:

1. List every query and write the application will perform. Literally enumerate them: “get user profile by ID,” “list a user’s 20 most recent orders,” “get all items in an order.”
2. Estimate each pattern’s frequency and latency requirement.
3. Design the data layout so that each important read is served by a single lookup — one key fetch, one partition read, one document.
4. Accept whatever duplication that layout requires, and plan how writes keep the copies consistent.

The mantra worth memorizing: relational databases optimize for storage and flexibility; NoSQL databases optimize for known access at scale. If your access patterns are genuinely unknown, that is an argument for a relational database, not against modeling.

The Central Trade: Embed vs. Reference

Every NoSQL design decision eventually reduces to one question — when two pieces of data are related, do you embed one inside the other, or store them separately and reference?

Embed when data is accessed together and owned together. An order and its line items are read together, written together, and line items have no life outside their order. Embedding them in one document means one read serves the whole order screen:

{
  "order_id": "ord_9812",
  "customer_id": "cus_311",
  "status": "shipped",
  "items": [
    { "sku": "KB-45", "name": "Keyboard", "qty": 2, "price": 45.0 },
    { "sku": "MN-210", "name": "Monitor", "qty": 1, "price": 210.0 }
  ],
  "shipping_address": { "city": "Pune", "pincode": "411001" }
}

Notice name and price are copied from the product catalog into the order. In relational thinking this is a violation; here it’s correct twice over — it makes the read self-contained, and it snapshots what the customer actually saw at purchase time.

Reference when data is shared, unbounded, or independently updated. The customer isn’t embedded in the order, because customers exist across thousands of orders and their profile changes independently. Similarly, never embed unbounded lists — a user’s “activity” array that grows forever will eventually hit document size limits (16 MB in MongoDB, 400 KB per item in DynamoDB) and slow every read of the parent.

Three questions decide it:

• Read together? → leans embed.
• Bounded size? → embed only if yes.
• Updated from elsewhere? → leans reference (or embed a deliberate snapshot).

The Model Families and What They’re Each Shaped For

“NoSQL” covers four genuinely different data models. Choosing among them is a modeling decision:

Key-value (Redis, DynamoDB in its simplest use). The model is a hash map: opaque value behind a key. Blazing and rigid — you get exactly the lookups you designed keys for. The modeling skill is key design: session:{user_id}, cart:{user_id}. Perfect for sessions, caches, feature flags, counters.

Document (MongoDB, Firestore, Couchbase). Values become structured, queryable JSON with secondary indexes. The modeling skill is the embed/reference balance above, plus index design. The natural fit is aggregate-shaped data: orders, profiles, product listings — anything a screen displays as one cohesive object. (The next post in this series goes deep on document design.)

Wide-column (Cassandra, HBase, ScyllaDB). Data is organized by a partition key (which machine holds it) and a clustering key (sort order within the partition). The modeling skill is designing partitions so each query reads exactly one, already sorted:

-- Cassandra: "recent readings per device" as a table designed for that query
CREATE TABLE readings_by_device (
    device_id  text,
    reading_ts timestamp,
    value      double,
    PRIMARY KEY ((device_id), reading_ts)
) WITH CLUSTERING ORDER BY (reading_ts DESC);

In Cassandra you create one table per query pattern and duplicate data across them at write time. That’s not a workaround; it is the intended methodology.

Graph (Neo4j, Neptune). Relationships become first-class stored objects, ideal when the questions are about connections — covered in its own post later in this series.

Handling Duplication Without Getting Burned

Denormalization is the price of single-read access, and it’s payable — but only with eyes open:

• Know your copy map. For every duplicated attribute, write down where copies live and what updates them. “Product name appears in: catalog (source of truth), embedded order items (snapshot, never updated), search cache (refreshed hourly).”
• Distinguish snapshots from mirrors. Order-item prices should diverge from the catalog (snapshot). A username shown on comments should follow the profile (mirror — updated asynchronously, usually via an event or background job). Confusing the two produces either rewritten history or stale screens.
• Accept eventual consistency deliberately. If a username update takes thirty seconds to propagate to old comments, is that acceptable? Usually yes — but decide it, don’t discover it.

A Worked Miniature: Modeling a Simple E-Commerce App on DynamoDB

Access patterns: (1) get customer profile, (2) list customer’s recent orders, (3) get one order with items, (4) get product details.

A common single-table design uses generic keys where several entity types share one table, laid out so each pattern is one query:

Pattern 2 becomes a single query — PK = CUS#311, SK begins_with ORD# — returning orders already sorted by date because the date is in the sort key. That trick, encoding sort order into keys, is the wide-column mindset applied inside DynamoDB, and it’s the kind of design you simply cannot retrofit after launch. Model first.

When NoSQL Is the Wrong Answer

Honesty clause: reach for relational when access patterns are exploratory or ad hoc, when multi-entity transactions dominate (ledgers, inventory reservation), or when data volume is modest and always will be — PostgreSQL at ordinary scale gives you flexibility, integrity, and joins for free. The strongest NoSQL designs come from teams who could articulate exactly why the relational model didn’t fit this workload.

The takeaway: in NoSQL, the schema lives in your key design and your duplication strategy, and it’s decided by the queries you enumerate before writing code. Skip that enumeration and you don’t have a schemaless database — you have an unmodeled one.