Loading tutorials…
Loading tutorials…
Databases are the leverage in Notion. They are also the part most teams use wrong — flat lists with no relations, brittle formulas, and rollups that silently break. This walks the patterns that hold up at scale.
Who this is forAnyone past basic Notion docs who needs to model real data — content calendars, CRMs, project trackers, OKRs, inventory. If you have copy-pasted the same data across 4 pages because you did not know how to relate databases, this tutorial is for you.
What you'll need
Step 1
Inline = embedded in a page among other content. Full Page = a database that IS the page. Wrong choice here causes navigation pain forever.
Type '/database' on any page → Notion offers 'Database — Inline' and 'Database — Full page'.
Inline: lives inside another page, surrounded by text/headings/other blocks. Use for small databases that are part of a larger document (a 'Decisions' database inside a meeting notes page, a 'Tasks' database inside a project brief).
Full Page: the entire page IS the database. Use for any database that will exceed ~50 rows, that needs multiple views, or that other databases will relate to. The Content Calendar, CRM, Projects database — all Full Page.
Rule of thumb: if the database might ever exceed 100 rows or be referenced from other places, Full Page. Inline is for tactical, in-context use.
You CAN convert between them: '...' menu → 'Turn into page' / 'Turn into inline' — but the conversion sometimes loses view configurations. Plan correctly upfront.
Step 2
Notion has 40+ property types in 2026. Wrong choice = data that cannot be filtered, sorted, or rolled up correctly.
Text vs Title: Title is the primary identifier (database row name), one per database, always required. Text is freeform content for any other text.
Number: for math. Always set Format (Number, Currency, Percent). Currency format also picks the symbol — set it correctly the first time, because changing later affects all rollups.
Select vs Multi-select vs Status: Select = one value from a fixed list. Multi-select = many values (Channel: Blog + LinkedIn). Status = like Select but with a built-in Not Started / In Progress / Done grouping. Use Status when you have a workflow; Select for categories.
Date: also stores end date and time. Set 'Include Time' only if you actually need it — extra noise otherwise.
Person: assigns to workspace members. Cannot be assigned to a Guest unless they have access to the database.
Relation: links to another database. The most powerful property and the most misused (see next step).
Rollup: aggregates data via a Relation. Sum, Count, Average, Latest, etc.
Formula: computes a value from other properties (Notion Formulas 2.0 syntax — see step 6).
Files & Media, URL, Email, Phone, Checkbox, Created Time, Last Edited Time, Created By, Last Edited By: self-explanatory utility types.
Step 3
Relations are how databases connect. One-way is the default; two-way is what you almost always want. Get this right or your reports will lie.
Add a Relation property → Notion asks which database to relate to → pick the target.
Notion then asks: 'Show on [target database]?' — this is the two-way toggle. Default in 2026 is Yes. Verify it is on.
Two-way means: editing the relation on Database A automatically shows on Database B. You can navigate Deal → Company AND Company → Deals.
One-way is rarely correct. The only use case is when you want to reference but not pollute the other database with backlinks — e.g., a 'Mentioned in' relation that should be invisible from the source.
Verify: open a Company page and confirm Deals appear in the side panel. If not, the relation is one-way — fix it via the property settings on either database.
Plan relations before building. A 4-database system (Companies, Contacts, Deals, Activities) has 6 possible relations — sketch which 3-4 you actually need.
Step 4
Rollups aggregate data from related records. Sum of deal values per company, count of tasks per project, latest activity date per deal — all rollups.
Add a Rollup property → Notion asks: (1) Which Relation to roll up from, (2) Which Property on the related database, (3) How to Calculate.
Calculate options: Show original, Show unique, Count all, Count values, Count unique values, Count empty, Count not empty, Percent empty, Percent not empty, Sum, Average, Median, Min, Max, Range (Number properties only), Earliest date, Latest date, Date range (Date properties only), Show original (for any).
Common patterns: Sum (Deal.Value where Stage != Closed Lost) = Pipeline. Count All (Tasks) = Task count. Latest (Activity.Date) = Last touched. Show Original (Company.Lifecycle) = Inherited lifecycle.
Filter inside the rollup: Rollup settings → Filter → only include related records matching X. This is how 'Open Pipeline' (only non-closed deals) works.
Chained rollups (rollup of a rollup) work — useful for hierarchical models like Project → Tasks → Subtasks where you want a 'total estimated hours per project' across two relation hops.
Step 5
Each database has unlimited views: Table, Board, Calendar, Timeline, List, Gallery. Views are how the same data answers different questions.
Top of any database → '+ New view' → pick view type.
Table: spreadsheet-like. The editor's view. Use for bulk editing and seeing all properties at once.
Board: kanban grouped by a Select / Status / Person property. Use for workflow tracking. Cards drag between columns.
Calendar: monthly view by a Date property. Use for content calendars, event tracking, deadlines.
Timeline: gantt-style by a Date property (start + end). Use for project planning, campaign tracking.
List: minimal vertical list. Use for embedded references and clean docs.
Gallery: card grid with cover image. Use for visual content (designs, video, product imagery).
Each view has its own filters, sorts, and visible-property settings. Master view = unfiltered Table for the editor. All other views = filtered for a specific audience.
Step 6
Notion Formulas 2.0 (rewritten in 2023, polished through 2026) is a real language. Build derived properties like 'days until close,' 'deal health score,' or 'quarter from date.'
Add a Formula property → click 'Add formula' → opens the formula editor.
Reference properties with prop('Property Name'). Formulas 2.0 supports rich syntax: if-else, dates, strings, lists, math.
Common formulas: Days until close = dateBetween(prop('Close Date'), now(), 'days'). Days since last activity = dateBetween(now(), prop('Last Activity Date'), 'days'). Deal health = if(prop('Days Since Last Activity') > 14, 'Stalled', 'Active').
Quarter label from date = 'Q' + format(quarter(prop('Date'))) + ' ' + format(year(prop('Date'))).
Format output: Notion automatically detects type (number, date, string, boolean). Wrap with format() to force string output when needed.
Avoid over-formulizing. A formula that takes 10 lines and references 5 properties is fragile — changing any property name breaks it. Prefer simple chains.
Step 7
30 minutes of paper modeling saves 30 hours of restructuring. Sketch your databases, their relations, and the questions they need to answer.
On paper or a whiteboard, draw each database as a box. Inside each box, list the 6-8 most important properties (not all 20).
Draw arrows between databases for relations. Label each arrow (e.g., 'Deal belongs to Company,' 'Task is part of Project').
Decide: which arrows are two-way? Almost all of them.
List the 5 questions the system must answer ('How much pipeline at Acme?', 'Which deals stalled >14 days?', 'What is my Q2 forecast?'). For each, identify which database/view/rollup answers it.
If a question has no clear answer, the data model is missing something — add the property, relation, or rollup needed.
Only after this is built on paper, open Notion and build it. Skipping this step is how you end up restructuring 4 weeks in.
Common mistakes
Copy-pasting the same data across multiple pages instead of relating databases
What goes wrong: Company name lives in 8 different databases. Update it in one, the other 7 lie. Within 6 months, nobody trusts the data. Estimated cost: 5-10 hrs/week of 'wait, which one is right?' = $12-25K/yr.
How to avoid: One database per entity type. Use Relations to link. Update once, all linked records see the new value via Rollups.
One-way relations instead of two-way
What goes wrong: You can navigate Deal → Company but Company → Deals shows nothing. The 'show all deals at Acme' query is impossible. Sales ops time wasted: 3-5 hrs/wk = $7-15K/yr in a 5-person team.
How to avoid: Default every relation to two-way. The 'Show on [other database]' toggle should be ON unless you have a specific reason to hide.
Properties without consistent enum values
What goes wrong: Status property has values like 'Qualified', 'qualified', 'Qual', 'Q' — all entered by different team members. Filtering and reporting break because 'Qualified' is now 4 different values. Forecasts are wrong by 20%+.
How to avoid: Always use Select (not Text) for fields with a fixed set of values. Lock the options. If someone needs a new option, it goes through a small approval (a manager adds it) — no free-form additions.
Rollups without filters
What goes wrong: 'Total Pipeline' rolls up ALL deal values including Closed Lost and Closed Won. Number is meaningless. Leadership makes decisions on bad data — typical impact: $20-50K/quarter of wrong hiring or spending.
How to avoid: Every Rollup that aggregates needs a Filter. Pipeline = Sum where Stage != Closed. Activity Count last 30 days = Count where Date is within 30 days.
Over-engineered formulas that nobody understands
What goes wrong: Original builder wrote a 50-line formula combining 7 properties. They leave the company. Formula breaks. Nobody can debug it. Database becomes read-only for changes. Cost of rebuild: 10-20 hrs of specialist time = $200-400.
How to avoid: Cap formulas at ~5 lines. Document complex formulas in a comment on the property description. Prefer many simple formulas over one complex one.
No data model documentation
What goes wrong: New team member spends 2-3 weeks reverse-engineering the database structure. They cannot tell which property is canonical vs derived. They make changes that break rollups. Knowledge transfer cost: $5-15K per new hire.
How to avoid: Create a 'Data Model' page in the SOPs Teamspace. Document each database, its properties, what each Relation links to, and what each Rollup calculates. Update when the model changes.
Recap
Done — what's next
How to build a Notion content calendar that the team actually uses
Read the next tutorial
Hand it off
Databases are the highest-leverage and highest-skill part of Notion. The difference between a good Notion ops system and a bad one is usually correct data modeling — relations, rollups, and views. A specialist will model your specific use case, build the databases, configure rollups and views, and document the structure for your team. One-shot builds run $300-700; ongoing ops support runs $400-1,200/mo at $14-16/hr.
See specialist rates
Status is a Select variant designed for workflow tracking. It has three built-in groups: To-do, In Progress, Complete. Use Status for fields representing a workflow (Lead Stage, Task Status, Pipeline Stage). Use plain Select for fields representing categories without a progression (Industry, Channel, Type).
Yes — Notion → Import → CSV. Existing databases can also import via '...' menu → Merge with CSV. Watch the column-to-property mapping carefully; Notion creates new properties for unmapped CSV columns. Standardize values (especially Select option names) before importing — Notion will create separate options for 'Acme', 'acme', and 'ACME'.
Performance stays acceptable up to ~50,000 rows on Full Page databases. Past 100,000, views become noticeably slow. The hard limit per database is much higher (effectively unlimited) but you will hit UX walls before structural ones. If you regularly query 50K+ rows, consider Airtable or a real database.
Each database row IS a page. You can nest sub-pages inside any row by opening it and adding content. Notion also added 'Sub-items' (a parent-child property within the same database) — useful for task hierarchies. Don't over-use sub-items; if the hierarchy is deep, split into two related databases (Projects + Tasks) instead.
Native Notion does not sync with external databases. Use Zapier / Make / native integrations (next tutorial) to push/pull data on a schedule. For real bidirectional sync with Postgres/MySQL/HubSpot, consider tools like Whalesync or Unito. None are instant — accept 5-15 min latency.
Notion
Most Notion content calendars die within 60 days because they were copied from a template without the workflow underneath. This walks the database, the views, and the status discipline that makes a content calendar the actual source of truth.
Notion
Notion as CRM works at small scale and stops working at medium scale. This walks the right build pattern, the rollups that make it useful, and the honest signals that tell you it is time to move to HubSpot or Pipedrive.
Notion
Templates and buttons are how you turn Notion from a doc tool into an ops tool. They are also the features most teams skip. This walks the patterns that save 5-10 hrs/week.
Airtable
Airtable is fast to spin up and easy to wire wrong. Most marketing bases hit a wall at 3,000 records or 10 linked tables because the schema was built around the first idea, not the second year of data. This walks the base structure that holds up.