David Neira is an official Notion Ambassador and the founder of NotioStore, where he builds custom Notion operating systems for architecture, construction, and interior design firms. He run 40 Notion Setup Sessions per week and writes here about making Notion hold up under real client work.
You keep reorganizing, and it keeps getting messy. There’s a task list for this project and a separate one for that, a contacts table here and another list of people there, and somewhere a table that’s half clients and half projects jammed together. Every few weeks you tidy it up; every few weeks it slides back into a tangle you can’t quite see through. The problem was never tidiness. It’s that the bones are wrong.
Almost every messy Notion workspace has the same underlying fault, and one principle fixes most of it: one database per object. The idea is simple. Every distinct type of thing your business tracks gets exactly one database, and then you connect them with relations. Get that right and a clean Notion workspace mostly builds itself; get it wrong and no amount of rearranging will save you, because you’re tidying a broken structure. Of every design decision you’ll make in Notion, this is the one that matters most.
The first cost is the reorganizing that never ends. When the underlying structure is wrong, tidying only ever moves the mess around, so you clean it up, it drifts back, and you clean it again, forever. That’s real hours spent on maintenance that solves nothing, because you’re treating the symptom while the cause sits untouched underneath.
The second cost is what a broken structure hides from you. When the same kind of thing is scattered across many databases, a task list per project, say, you can never see all of it at once, so things slip, get duplicated, and go unnoticed. And when different kinds of thing are crammed into one database, filtering breaks and relations become impossible, because half the rows have properties the other half shouldn’t. Either way, the workspace can’t answer basic questions, and you’re left doing by hand what a correct structure would have shown you instantly.
The deepest cost is that everything you build on bad bones inherits the flaw. Every view, every automation, every new feature you add on top of a broken structure is harder to build and quicker to break, because it’s all resting on the same fault. You end up blaming yourself for being disorganized when the truth is structural, and that compounding drag is far more expensive than the afternoon it would take to fix the foundation.
An “object” is just a distinct type of thing your business tracks, a noun. Clients are an object. Projects are an object. Tasks, invoices, meetings, content pieces, each is a distinct kind of thing with its own attributes and its own life. The rule says: give each of these exactly one database, and relate them to each other into one connected workspace. One Clients database, one Projects database, one Tasks database, connected.
The reason this is the number one principle is that databases and relations are the foundation Notion is built on, so mapping your business to them correctly is the decision everything else depends on. Get the objects right and the workspace is clean and scalable by construction, because the structure matches how your business actually works. Get them wrong and you fight the structure forever. It’s the difference between a building with a sound frame and one you keep repainting to hide the cracks. If databases are new to you, this is the concept to learn first.
Finding your objects is mostly listing the nouns in how your business runs. “We run projects for clients, broken into tasks, and we bill invoices” gives you four objects, and therefore four databases: Clients, Projects, Tasks, Invoices. Say how your business works in a sentence or two, underline the nouns, and you’ve usually found them.
The tricky part is telling a real object from something that only looks like one. Here’s the test: if the only thing separating two groups is a category, a date, or a status, they are not separate objects, they’re one object with a property. “2024 Projects” is not an object; it’s your Projects database filtered by year, a view. “Residential Projects” is not an object; it’s a Type property on Projects. A thing earns its own database only when it has genuinely different attributes and its own relationships. When in doubt, assume it’s a property, not a new database, because that’s the error people make most.
That test exposes the first way people break the rule: over-splitting, making many databases for one object. A separate task list for every project, a fresh contacts table for every purpose. The fix is always the same, collapse them into one database and use a relation and views to separate what you were splitting by hand.
The second way people break it is under-splitting: cramming several objects into one database with a “type” column, clients and projects and tasks all in one table. The fix is to separate them into their own databases and relate them, so each has the properties it actually needs and the relations become possible.
A construction firm had built its workspace one job at a time, literally, a separate little set of databases for every job, until it had dozens of near-identical databases and no way to see across any of them. Simple questions, how many jobs are active, which are overdue, took an afternoon of clicking through folders. Applying the rule collapsed all of it into a handful of databases, one Jobs, one Tasks, one Client, one Invoices, related together. Dozens of databases became four, every job became a row, and questions that used to take an afternoon took a glance.
The rule is a strong default, not an iron law. There are rare cases where genuinely different sub-types warrant separation, or where a database has grown so enormous that splitting it helps performance. Learn the rule cold first, then break it knowingly in the few situations that call for it. Dogmatism is its own mistake; the point is judgment, not obedience.
Identifying objects also takes a little thought, and the honest guidance is to bias toward fewer databases, not more. Most messes come from treating every category and time-slice as its own object, so when you’re unsure whether something deserves a database, it usually doesn’t. It’s a property until proven otherwise.
And getting your objects right is necessary, not sufficient. It gives you sound bones, but you still have to build good views, processes, and habits on top; the rule fixes the structure, not the whole workspace. Fixing an existing tangle is also real work, worth doing, but do it deliberately rather than expecting an instant transformation.
Where the rule pays off is every Notion workspace, which is why it’s the first thing worth getting right. Nail it and everything you build afterward is easier; skip it and everything is harder.
Don’t restructure anything yet. Spend five minutes and write down the nouns in how your business works, the distinct types of things you track. That short list is your database list: one database per item on it, no more, no less.
Then hold your current workspace up against that list. Anywhere you have several databases for a single noun, or one database holding several nouns, you’ve found exactly what’s wrong and exactly what to fix. That comparison alone usually explains why the tidying never stuck.
If you’d rather have your workspace structured correctly from the foundation, the right objects, cleanly related, so it stays clean instead of drifting back into a tangle, book a discovery call and we’ll design it together.
A pile of tasks isn’t task management. Real task management is knowing, at any moment, what to do next, and that takes more than a list. This is a step-by-step tutorial for using Notion for task management.
Entrepreneurs can replace expensive tools with Notion by consolidating the overlapping ones, notes, docs, projects, wiki, simple CRM, into a single subscription, while keeping only the specialized tools that genuinely earn their price.
New to Notion? Discover the most common beginner mistakes and how to avoid them so you can build a smarter, simpler, and stress-free Notion system.
Built for the businesses that build everything else.
No product pitches. No padding. One weekly read for serious operators.