Twenty minutes into a build session, the agent stops and prints a question: "Should I store saved items in a database, or keep them in a local file for now?" Your first tester, the colleague who gave your build her lunch break, is watching your screen, so you answer like someone who knows: just a file. Nine days later she messages you a screenshot, and her saved list is empty. The trace takes one evening: every save read the whole file, added one item, and wrote the whole file back, and when your two testers saved within the same second, the later write replaced the file, her items included. Nothing crashed and no error appeared; the file held whatever was written last, as files do.
The agent was asking where your product's data should live. All data lives in some structure: your photos in files, your household budget in a spreadsheet, your bank balance in a database.
The table that would have kept her list
Here is the same data in the home the agent offered, a database table:
saved_items
id | user_email | item | saved_at
1 | [email protected] | Sunrise Alarm Clock | 2026-06-24 09:12:41
2 | [email protected] | Folding Desk Lamp | 2026-06-24 09:12:41
3 | [email protected] | Noise-Cancelling Headphones | 2026-06-25 14:03:09
4 | [email protected] | Standing Desk Mat | 2026-06-26 08:47:52
Each line is a record, one saved item, and every record carries the same columns: who, what, when. Rows 1 and 2 are stamped the same second: Asha and Leo saving at once, the collision that emptied her list. This time both survive, because a database never rewrites the whole store; each save lands as its own row, and rows do not overwrite each other. The table also answers questions the file never could: "which items did Asha save this week?" is a query, a question asked across every record at once.
The four forms data can live in
Nearly every piece of data in software sits in one of these places.
- A file on disk. The home for drafts, exports, images, and configuration: data read often, written rarely, touched by one person or one program at a time.
- A spreadsheet. A file with rows, columns, and an editing screen included for free; Google Sheets and Airtable made it a respectable home for a small product's data.
- A database. A purpose-built service for records like the saved_items table: many users writing at once, each write its own row, questions answered by query. Here the backend keeps everything it must not lose.
- A data warehouse. A database tuned for analytics across long history rather than serving an app; you will not need one for a long time.
The sorting test follows from the failure. Who writes it? One person on one device is file territory; two people writing, or one person from two devices, calls for a form that keeps each write separate, a spreadsheet at small scale and a database beyond it. What will you ask of it? If you only ever open it and look, a file or spreadsheet holds up; questions across records call for a database.
List what your product will actually store, then pick the smallest form that holds it; moving up later is a routine, well-documented job, not a rewrite.
When the test says database, approve the default
When the test comes up database, your agent proposes one, almost always Postgres: a relational database, meaning tables like the one printed above, hosted by a provider so you never run the machine yourself. Articles will pit it against document databases, whose looser JSON records (the labeled-fields format from APIs, how systems talk to each other) need not all carry the same fields; you do not have to referee that debate. The move is the one from Languages and frameworks: approve the pick: approve the default and note it, "Postgres, the agent's pick, accepted for now."
Why not just take the database every time
A fair objection: the agent can set up hosted Postgres for the cost of a yes, so why keep a menu in your head? Because a database is a second running service, with overhead of its own:
- Another dashboard, another secret. A hosted database brings its own console, credentials to protect, and backups to mind.
- You cannot open it like a file. In your first debugging weeks, opening a spreadsheet takes two minutes where a database console can stall an evening.
- Columns you commit to early. A database asks for its columns up front, and changing them later is a deliberate step, while a spreadsheet lets you add a column as you learn.
The menu exists so you take each cost knowingly: the opener showed what "just a file" costs once two people write, and this list is what "database" costs for a tool only you use.
The two kinds of data in an AI product
Once a model enters your product, data splits into two kinds.
What the model is given this turn. Every request carries everything available for that one answer: instructions, the user's question, snippets from stored records, recent turns of the conversation. The bundle is called the prompt, or the context; your backend assembles it fresh for each request, the model answers over the round trip you traced in The journey of a request, and the bundle is gone. Its ceiling, the context window, is the maximum text one request can include.
What your product stores. Accounts, documents, preferences, and conversation history are ordinary records in the forms above, durable between sessions and yours to protect.
Where a product's memory actually lives
Suppose the app gains a suggestion feature: a model proposes one item the user might want next. One afternoon Asha types "warm-light products only, please," and the product stores that line as a record:
preferences
user_email | detail | noted_at
[email protected] | warm-light products only | 2026-06-25
On her next visit, the assembled prompt carries the stored row beside her two saves from the table above:
You suggest one item for the saved-items app.
About this user: warm-light products only.
Recent saves: Sunrise Alarm Clock, Noise-Cancelling Headphones.
User message: "any desk lamp for me?"
The model is handed the bundle, returns a warm-light lamp, and the bundle is discarded; models retain nothing between requests. When she tells you the app remembered her, both halves of the trick are printed above: the stored record and the prompt it rode in.
When a product seems to remember you, it stored the detail as a record and re-sent it in the next prompt.
The same machinery runs in products you use daily: when ChatGPT flashes "Memory updated," a record like Asha's row was just written, its settings page lists every line kept, and later conversations start with those lines in the prompt. What your build sends each turn, and what it costs as the bundle gets heavier, is the subject of Give the model the facts it wasn't trained on.
Try it now
This drill takes about fifteen minutes and spends nothing on either path.
No setup: Audit one AI product you already use, such as a chat assistant or a meeting notetaker. Write two lists. The first holds stored data, what it keeps across sessions: saved conversations, uploaded files, custom instructions, anything its settings page shows. The second holds context, what survives only within one conversation: details you gave it ten messages ago that vanish in a fresh thread. If it seems to remember something across sessions, find the stored record that explains it. Add both lists to the idea file you started in Decode the technical questions that stop you, with one line on what your own idea would store and the smallest form that holds it.
With your tools: Open Claude Code, describe the product you are circling, and ask: "Split this product's data into two lists: what we store durably, and what we assemble into the model's prompt each request. Then name the smallest storage form that fits the stored list." Challenge anything heavy in the answer, then copy both lists and the storage note into your idea file. Same move in Codex or Cursor: put the two-list question to the sidebar chat and push back on the storage pick. If your tools are not set up yet, the Setup Clinic gets you there in one sitting.
Chapter Summary
- Data lives in one of four forms: a file on disk, a spreadsheet, a database, or a data warehouse.
- A file is rewritten whole and keeps whatever landed last, so it fits data one person or one program writes; a database keeps every write as its own row, so shared or synced data belongs there.
- A query is a question asked across every record at once, and it is the other half of what a database buys you.
- List what your product would store and pick the smallest form that holds it, because moving up a form later is routine work, not a rewrite.
- When the answer is a database, agents propose hosted Postgres; approve the default and note it, the same move as your language and framework picks.
- A database is also a second running service, with its own console, credentials, and backups, so a tool only you use should not carry one.
- An AI product holds two kinds of data: stored records that last between sessions, and the prompt, also called the context, assembled fresh for each request, capped by the context window, and discarded after the answer.
- When a product seems to remember you, a stored record was re-sent inside the next prompt; the model kept nothing.
- Store less by default, because data you never keep cannot leak, cannot be subpoenaed, and cannot be sent to the wrong place.
- Every form on the menu still needs a machine to run on, and renting that machine is the subject of Hosting, renting a computer on the internet.
Sources
- PostgreSQL documentation (postgresql.org), the relational database agents most often propose (last verified July 2026).
- OpenAI Help Center, Memory FAQ, on ChatGPT's "Memory updated" notice and the saved-memory settings page (last verified July 2026).
- Anthropic documentation on context windows and prompt construction (last verified July 2026).