Five Notion database design rules I wish I knew sooner
Most messy Notion workspaces aren't a discipline problem — they're a schema problem. Here are the five rules I now apply before building anything.
Every chaotic Notion workspace I've audited has the same root cause: the databases were designed for how the creator felt on day one, not for how they'd work on day ninety. The fix is almost always structural, not motivational.
Rule one: one database per noun. If you have a Content database and an Ideas database and a Drafts database, you have three places to look and zero sources of truth. Merge them and use a status property to separate stages. Rule two: relations beat folders. Folders hide information; relations surface it. A client page should link to projects, invoices, and notes — not live above them in a tree.
Rule three: keep properties under ten. Every extra property is a decision you make every time you add a row, and decisions are friction. If a property hasn't been filled in for a month, delete it. You can always add it back.
Rule four: build views for questions, not categories. "All projects" is a category. "What's due this week and not started" is a question. Your board views should answer the second kind, and you should have three or four of them at most.
Rule five: name things the way you'd say them out loud. "Q3 Launch – email sequence" beats "Project 14b." Six months from now, future-you will not remember the code. The extra three seconds of typing is the cheapest documentation you'll ever write.