Designs Notion databases that scale - one entity per database, deliberate property types, two-way relations with rollups, audience-specific views, and row templates - with explicit decision rules for relation vs rollup vs formula. Use when someone asks "design a Notion database for my projects", "should this be a relation or a rollup", "my Notion workspace is a junk drawer", or "set up a tasks and projects system in Notion". Do NOT use for building a full personal knowledge-management method with capture and review habits - use second-brain instead. For SQL or application database schemas, use database-schema.
Click to play with sound.
---
name: Notion Database Designer
description: Designs Notion databases that scale - one entity per database, deliberate property types, two-way relations with rollups, audience-specific views, and row templates - with explicit decision rules for relation vs rollup vs formula. Use when someone asks "design a Notion database for my projects", "should this be a relation or a rollup", "my Notion workspace is a junk drawer", or "set up a tasks and projects system in Notion". Do NOT use for building a full personal knowledge-management method with capture and review habits - use second-brain instead. For SQL or application database schemas, use database-schema.
---
# Notion Database Designer
A well-modeled Notion database scales; a sloppy one becomes a junk drawer where the same project name is typed forty different ways and no filter works. The expensive mistake is deferred: free-text fields and duplicated names feel fine for a month, then the workspace crosses a few hundred rows and every view, count, and cleanup becomes manual archaeology.
## Inputs to collect
1. What a single row represents, in one sentence (a task, a contact, a project). If a row could mean two different things, that is two databases - settle this first.
2. The questions people will ask of the data ("what's overdue?", "how loaded is each project?") - each question becomes a view or a rollup.
3. Who uses it and how often - each distinct audience gets its own view.
4. What already exists - related databases to link to rather than duplicate.
## Operating procedure
Order matters: entity before properties (properties describe the entity), relations before rollups (rollups aggregate across relations), structure before views (views are lenses on structure).
### Step 1: Define the entity
State in one sentence what a single row represents. If a row could mean two different things - a task sometimes, a meeting note other times - split into two databases now; migrating rows apart later is the most painful operation in Notion.
### Step 2: Choose property types deliberately… install to load the full skill