Packing for How You'll Unpack: Designing for Query Patterns, Not Just Storage

Opening Scene

A mover who packs purely for what fits neatly into a box, without any thought to which room each item is actually headed for, creates real trouble on the other end: unpacking becomes a matter of digging through mixed boxes, room by room, searching for scattered items. A genuinely smart mover packs with the destination already in mind — kitchen items together, bound for the kitchen, retrievable in one trip once the truck arrives — because how a box will actually be unpacked matters just as much as how efficiently it was packed.

Query-driven document design applies this exact same forward-looking discipline.

In Plain English

Document modeling should start from an application’s actual, real query patterns — what data needs to be retrieved together, how often, and in what shape — rather than simply mirroring how data happens to exist at its source. Unlike relational modeling, which can reasonably start from normalized entities and business rules first, document modeling genuinely works best when the target query shape drives the document structure from the very beginning.

The Old Way

Recognizing that document modeling is fundamentally query-driven, rather than entity-driven, has always been one of the field’s most important, if sometimes counterintuitive, principles:

“Design for your queries” is the core mantra of document modeling, in real contrast to relational modeling’s more entity- and normalization-driven starting point — a document schema optimized for how data will actually be read tends to outperform one optimized for storage tidiness alone.
The most common, highest-frequency queries deserve the most influence over document structure, since a document shape that serves a rare query well but makes a common query awkward has gotten the priorities backwards.
This query-first approach directly informs the embedding-versus-referencing decisions from Articles 2 and 3: a query pattern that always needs two pieces of data together is real evidence favoring embedding, just as a query pattern needing independent access to shared data favors referencing.

Getting this right has always meant genuinely understanding an application’s real, current, and reasonably anticipated future query patterns before finalizing a document structure, not treating document design as a purely storage-oriented exercise.

What’s Changing (and Why AI Is the Reason)

AI-assisted query pattern discovery can analyze real application logs, code, or anticipated usage to identify the actual queries a document schema needs to serve well, grounding query-driven design in genuine evidence. Rather than a modeler guessing at likely query patterns from a specification document, AI-assisted analysis of real or planned application behavior can surface the actual, concrete queries a document structure needs to prioritize.
AI-assisted document schema proposals can directly translate a set of prioritized query patterns into a recommended document structure, closing the loop between understanding what queries matter and designing a structure that serves them well. This connects directly to the embedding and referencing decisions covered in Articles 2 and 3, informed by real query evidence rather than assumption.
As AI agents increasingly generate their own queries against a document database based on natural-language requests, the range of query patterns a schema needs to serve well can grow less predictable than in a traditional application with a fixed, known set of query types. This raises the stakes of query-driven design, since a document structure now potentially needs to serve a genuinely broader and less predictable range of access patterns than a traditional application alone would have generated.

The Metaphor, Fully Extended

Moving Company Element	Query-Driven Design Concept
Packing boxes purely for what fits neatly together, without regard to destination	Designing a document structure based on storage convenience rather than real query needs
Packing kitchen items together specifically because they’re all headed to the same room	Designing a document structure around the actual data that needs to be retrieved together
Prioritizing the packing plan for the rooms that get unpacked first and most often	Prioritizing document structure for the highest-frequency, most important query patterns
A moving coordinator studying the client’s actual move-in day schedule before finalizing the packing plan	AI-assisted query pattern discovery grounding document design in real, anticipated usage
A logistics team adjusting the packing plan as the client reveals a broader, less predictable set of unpacking needs	A document schema needing to serve a less predictable range of queries as AI agents generate their own requests

For Beginners: What to Actually Do

Practice starting document design from the question “what will actually be queried, and how often” rather than “how does this data naturally look at its source.”
Get comfortable with the idea that document modeling and relational modeling have genuinely different starting points — query-driven versus entity-driven.
Before finalizing a document structure, identify the highest-frequency, most important query patterns it needs to serve well, and let those patterns drive the structure.
Notice that this query-first approach directly informs the embedding and referencing decisions covered earlier in this series — they’re not separate concerns.

For Practitioners and Leaders: The Deeper Layer

Use AI-assisted query pattern discovery to ground document design decisions in real application behavior, rather than assumption about likely usage.
Use AI-assisted document schema proposals to translate prioritized query patterns directly into a recommended structure, closing the loop between evidence and design.
Prepare your document schemas for a genuinely broader and less predictable range of queries as AI agents increasingly generate their own requests based on natural language.
Treat query-driven design as document modeling’s foundational discipline, distinct from and often in tension with relational modeling’s more entity-first starting point.

Quick Recap

Document modeling should start from an application’s actual, real query patterns, rather than mirroring how data happens to look at its source.
This “design for your queries” mantra genuinely contrasts with relational modeling’s more entity- and normalization-driven approach, and directly informs embedding versus referencing decisions.
AI-assisted query pattern discovery can ground document design in real, evidenced usage, and AI-assisted schema proposals can translate that evidence directly into a recommended structure.
AI agents generating their own queries raise the stakes of query-driven design, since a schema may need to serve a broader, less predictable range of access patterns than before.

Where This Fits in the Series

Article 3 covered when to tape a note to the box instead. This article covered packing for how you’ll actually unpack. Article 5 looks at what happens when the truck doesn’t care what’s inside — schema flexibility and polymorphic documents.