How to build a wardrobe database (the schema, and what it still cannot do)

Search for a wardrobe database and you will mostly find templates. An Airtable base copied nearly three thousand times, a Notion vault for seven dollars, a few spreadsheets. Which tells you something: the people asking this question do not want an app recommendation. They want to build the thing themselves, in a tool they already trust, and they are perfectly capable of doing it.

So this is not a list of apps. It is the schema, given away, with the reasoning behind each field and the three that everyone leaves out. Build it in Airtable, Notion, Sheets or Postgres. It is the same shape either way.

Full disclosure before you read on: this is the schema Modebase uses, exported from a live 167-piece wardrobe. Thirty-seven columns, and you can have the lot whether or not you ever use our product.

The short version

Most wardrobe databases fail for the same two reasons. They describe garments too vaguely to be searched later, and they store no relationships, so the table can tell you what you own but never what goes with what. Fix those two and the rest is bookkeeping.

One table is not enough, but three is too many

Start with items, one row per garment. Add outfits, which link to several items. Add wears, one row per time you wore something, because a "times worn" number you edit by hand will be wrong within a month.

That is the whole structure. People who go further, separate tables for brands and colours and seasons, end up maintaining a taxonomy rather than a wardrobe, and abandon it around week three.

The items schema, field by field

Identity

item_code, name, brand. The code matters more than it looks: a short stable id lets you refer to a specific garment in an outfit, in a note, or in a conversation, without retyping its description. Names should be full descriptions, not labels. "Blue and white striped crinkle shirt" is findable. "Blue shirt" is not.

What it physically is

category, subcategory, colours, fabric, pattern, pattern_scale, silhouette, fit, size_fit.

Two of these do disproportionate work. Colours as a list, not a single value, because most garments are two or three colours and a single-colour field quietly lies about every print you own. And pattern_scale, which sounds fussy until you try to decide whether two patterns can be worn together, at which point it is the only field that helps.

When it works

season, formality, formalities, formality_score, warmth, neutral, occasion_tags.

Store formality as a number, one to five, not as a word. "Smart casual" means something different to everybody including you, but a 3 sorts correctly against a 4. Keep formalities as a list alongside it, because a black silk shirt genuinely belongs at work and at dinner, and forcing it to pick one is how you lose it.

Warmth on its own scale, one to five by temperature band rather than by season, because a season is a place and a temperature is a fact.

Taste, which is the part templates skip

style_tags, style_essence, vibe_keywords, theme_tags.

This is where a wardrobe database stops being an inventory. Two pairs of black trousers can be identical on every physical field and belong to completely different lives. Without something here, any query you write returns both.

Relationships, which almost nobody builds

pairs_well_with, avoid_with. Links to other item codes, not free text.

This is the single biggest difference between a database that answers questions and one that just holds records. A flat table can tell you that you own a green silk shirt. Only a linked one can tell you what it goes with, and that you have twice tried it with the navy and hated it both times. Every hour you spend on this pays back.

Money

price, purchased_date, purchased_place, buy_again. Price plus a live count of wears gives cost per wear, which is the only honest feedback most of us get about our shopping. buy_again is the underrated one: a yes or no you record months later is worth more than any review you read beforehand.

State

availability, care_needs. Clean, in the wash, packed, in storage. A wardrobe database that lists things you cannot actually wear today is the most common reason people stop trusting theirs.

You

feelings, reach_for_when, complaints, story, notes.

These five are the reason to build a wardrobe database rather than photograph a rail. Too long without a heel. Only ever with flats. I feel wonderful in this. The bag is beautiful and holds a phone and nothing else. None of it is discoverable from a photograph, all of it decides what you actually wear, and every bit of it is lost the moment you switch tools without exporting.

The four mistakes

Describing things the way you think, not the way you search. You will look for "something for a wedding in October", not for "viscose". Write the row so that query finds it.

Free text where a list belongs. "Navy, cream" in one cell cannot be filtered. Two values in a multi-select can.

Cataloguing everything before using anything. Do the thirty pieces you wore last month. You will have something useful in an evening instead of something abandoned in a fortnight.

Counting wears by hand. It is the field that decays fastest and the one every interesting calculation depends on. If logging a wear takes more than a few seconds, the number will be wrong by March, and so will your cost per wear.

Where a database stops

Build all of the above and you will have something genuinely good. You will also find its edge quickly, and it is worth knowing where that edge is before you spend the evenings.

A database filters. It does not decide. You can ask it for everything formal, navy and warm. You cannot ask it what to wear to a daytime wedding in the country where you will be standing on grass and you do not want to be the most dressed-up person there. That is judgement, and no schema contains it.

It cannot see. Your rows are words. Clothes are visual, and choosing between them from a list of descriptions is harder than choosing from a wardrobe.

And it needs you to keep it true. Every field above is a field somebody has to update. That somebody is you, on a Sunday.

The version where the database answers back

That schema is not a template we drew up for an article. It is what Modebase exports, because it is what Modebase stores, and the difference is what happens around it.

The rows get written for you. Photograph a pile on the bed or a full rail and the individual pieces are separated out and described, with the physical fields filled in. No typing thirty-seven columns, one garment at a time.

The subjective fields fill themselves from conversation. This is the part that cannot be replicated in Airtable. Say "love it but not those shoes" while you are getting dressed, and it lands in avoid_with on those shoes. Say the bag is too small and it lands in complaints. You never open a record to type in a cell, which is precisely why those columns stay populated instead of sitting empty like they do in every template.

And the database is reachable from where you ask. Your wardrobe is read by ChatGPT or Claude when you ask a question, and the answer comes back as pictures of your real pieces rather than a filtered list. That is the bit a self-hosted base cannot do without building a connector yourself, which is a project rather than an afternoon.

It exports back out again, all thirty-seven columns plus a zip of every cut-out image, so nothing above is a one-way trip. Free to start, with 10 catalogue spaces. If you would rather build your own, genuinely, take the schema. It works.

If you want to see what the connected version looks like day to day, that is using your wardrobe with ChatGPT, and the spreadsheet-first route is laid out in the wardrobe inventory template.

Frequently asked questions

What is a wardrobe database?

A structured record of the clothes you own, one row per garment, with enough detail on each to answer questions later. It differs from a photo album in that it can be filtered and counted, and from a wardrobe app in that you build and own the structure yourself.

What fields should a wardrobe database have?

Identity (a code, a full descriptive name, brand), the physical facts (category, colours as a list, fabric, pattern and its scale, silhouette, fit), when it works (formality as a number, warmth by temperature, occasions), taste, relationships to other pieces, money, current state, and your own notes on how each piece makes you feel. Thirty-seven columns covers it comfortably.

Should I use Airtable, Notion or a spreadsheet?

Airtable if you want linked records, which matters for pairs-well-with. Notion if you already live there. A spreadsheet if you want it working this afternoon. The tool matters far less than whether each row is described well enough to be found again.

How long does it take to build one?

Roughly one to two minutes per garment once you find a rhythm, so a 150-piece wardrobe is several hours. Start with the thirty pieces you wore last month rather than the back of the cupboard, and you will have something useful in an evening.

Can a wardrobe database tell me what to wear?

It can narrow the options, which is genuinely most of the work. What it cannot do is weigh an occasion, the weather, what you wore on Tuesday and how you feel today, and then commit to one answer. For that the database has to be readable by something that can reason over it.