The Two-Database Rule That Stopped My Workspace From Rotting
Most Notion setups fail because they add databases instead of subtracting them. Here's the constraint I now apply to every build.
Every workspace I've inherited from a client has the same disease: eleven databases, four of which are abandoned, and nobody knows which one is the real task list. The problem isn't Notion. It's that adding a database feels like progress and deleting one feels like losing work.
My rule now is simple. A project gets two databases maximum: one for deliverables and one for reference material. Tasks, notes, and assets all live as properties or nested pages, not as new top-level tables. If I think I need a third, I have to name what I'd delete to get it.
This constraint forces the hard question early: what is this project actually tracking? When I built the Studio OS template, the first draft had a separate content database, a separate client database, and a separate invoice database. Merging them into one Projects table with filtered views cut the setup time in half and removed the sync problems entirely.
Try it on your next build. Count your databases before you start, commit to two, and see what you're forced to simplify. The friction you feel is usually the system telling you it was too complicated to begin with.