Notion Databases - Full Course for Beginners

TL;DR

Notion database records are pages, while properties define structured fields at the database level for every record.

Briefing Cornell Notes

Briefing

Notion databases turn individual pages into structured, queryable records—letting users build task managers, dashboards, and project systems that can be viewed, filtered, sorted, and linked in multiple ways. The core idea is that each database record is a page, while “properties” define structured fields at the database level (like name, due date, assignee, or status). That combination—page flexibility plus structured metadata—makes it possible to create tools far beyond a simple list, including board-style views, calendar layouts, and dashboards that stay consistent across the workspace.

A key distinction is that databases behave differently from spreadsheets. Spreadsheet cells sit at fixed coordinates and can be targeted directly by formulas (e.g., adding values from specific cells). Notion database entries instead store property values per record, so there’s no cell-by-cell targeting in the spreadsheet sense. The tradeoff is powerful: the same underlying records can be displayed through multiple “views” with different layouts and rules. Views can switch between table, board (Kanban), calendar, timeline, list, or gallery formats, and they can apply sorting, grouping, and filters so the same data serves different contexts—like “all tasks,” “due this week,” or “completed.”

Creating databases in Notion is straightforward: typing “/database” offers inline or full-page databases, and “/table,” “/board,” or similar slash commands can start with a specific layout. Linked databases also matter: they reference an existing source database but allow custom filters and sorting for a specific context. The lesson builds a “Simple Task Manager” by creating a tasks database and a companion projects database, then adding properties such as a checkbox “done,” a date “due,” and a select “assignee.” Layout changes then become meaningful once sorting and filtering are added.

Sorting and filtering are treated as the engine of usefulness. Sorting can be single or multi-level (e.g., due date first, then assignee as a tie-breaker). Filters come in simple and advanced forms, including date logic like “on or before one week from now.” A standout feature is “forcing functions,” a practical effect of filtered views: when a new row is created inside a filtered view, writable properties automatically receive values that satisfy the filter. In the task manager, adding a new task in the “due this week” view automatically sets its due date to exactly seven days out; adding in the “completed” view auto-checks the done box.

The course then scales the system using relations, templates, and derived data. Relations connect records across databases—tasks can link to projects—so each side can show contextual data via filters and groupings. Database templates provide default page content for new records; combined with linked databases and a self-referential filter, they enable “add tasks from the project page” workflows. Finally, rollups and formulas turn relational structure into summaries: a rollup counts unfinished tasks per project, and a formula formats that number into readable text like “1 task left” vs “2 tasks left.” The lesson closes with database/view locking to prevent accidental structural edits and shows how to embed a customized tasks view into a personal dashboard template for a compact, mobile-friendly workflow.

Cornell Notes

Notion databases store records as pages, with structured “properties” defined at the database level. This structure enables multiple views—table, board, calendar, timeline, list, gallery—each with its own sorting, grouping, and filtering rules, so the same records can serve different workflows (e.g., all tasks vs due this week vs completed). Filters can create “forcing functions,” where new rows added inside a filtered view automatically receive property values that satisfy the filter (like due dates set to one week out). Relations connect tasks to projects across databases, while templates and linked databases let users add tasks directly from a project page using self-referential filters. Rollups and formulas then summarize related data into human-readable metrics such as “tasks left.”

How does a Notion database differ from a spreadsheet, and why does that matter for building systems?

A spreadsheet organizes data into rows and columns where each cell has a fixed coordinate, enabling formulas that target specific cells (e.g., adding B2 and D5). A Notion database organizes data into records, and each record is a page. Properties are structured fields attached to every record, but they aren’t “cells” you can target by coordinate. The payoff is flexibility: the same records can be displayed in many views with different layouts, filters, sorting, and grouping—so the system behaves like a set of connected tools rather than a single grid.

What makes database views powerful in practice?

Views let users create multiple contextual lenses on the same master database. In the task manager example, one view shows “all tasks,” another shows “due this week,” and another shows “completed.” Each view can change layout type (table vs board/kanban) and apply different sort and filter criteria. View options also allow hiding the database title, showing/hiding properties, wrapping columns, and limiting load to improve performance when databases grow.

What are forcing functions in Notion databases, and how do they work?

Forcing functions are the automatic property values that appear when adding a new row inside a filtered view. Because the new record must satisfy the view’s filter, writable properties get defaulted accordingly. In the lesson, adding a task in the “due this week” view automatically sets its due date to one week from now (matching the filter “due on or before one week from now”). Adding in the “completed” view auto-checks the done checkbox. The effect applies to writable properties (not things like files/media, formulas, rollups, or created/edited timestamps).

How do relations, templates, and linked databases combine to let users add tasks from a project page?

Relations connect tasks to projects across databases (a “project” relation on tasks and a “tasks” relation on projects). Templates provide default content for new project records. A linked database inside the project template copies a view of the tasks database, then uses a self-referential filter: it filters tasks where the task’s project relation contains the current project page. When a new project is spawned from the template, the linked view’s filter updates to that specific project, so adding a task from the project page automatically links it to the right project.

How do rollups and formulas turn relational data into readable summaries?

A rollup reaches through a relation and calculates a value from related records—like counting unfinished tasks per project by rolling up the done checkbox and switching the calculation from “show original” to “unchecked.” Then a formula property formats that numeric rollup into text. The lesson uses a format/if-style approach with prop references (e.g., prop undone tasks) to output “1 task left” vs “2 tasks left,” including pluralization logic based on whether the count is greater than one.

What does database/view locking protect, and how is it applied?

Locking prevents structural or view changes. Permission settings can restrict someone from editing database views/structure (e.g., “can edit content” but not views). Additionally, locking a database stops changes to properties and formulas. Linked database views can also be locked so filters/sorts can’t be permanently changed; changes may be temporary unless unlocked.

Review Questions

When would you choose a linked database instead of creating a new database, and what customization still remains possible?
Describe a scenario where multi-level sorting would change the order of results compared with sorting by a single property.
How would you design a forcing function so that new tasks created in a specific view automatically receive a due date and a default status?

Key Points

1
Notion database records are pages, while properties define structured fields at the database level for every record.
2
Database views are the main mechanism for turning one dataset into multiple workflows using different layouts, sorting, grouping, and filters.
3
Filters can act like forcing functions: creating a new row inside a filtered view auto-fills writable properties so the new record matches the filter rules.
4
Relations connect records across databases (e.g., tasks to projects), enabling contextual grouping and filtering from either side of the relationship.
5
Database templates plus linked databases with self-referential filters enable “add related items from the parent page” workflows.
6
Rollups summarize properties from related records (like counting unfinished tasks), and formulas can format those rollup results into human-readable text.
7
Locking databases and views helps prevent accidental changes to structure, formulas, and view criteria—especially in shared workspaces.

Highlights

A database record in Notion is a page, so databases combine page flexibility with structured properties.

Views can be radically different (table vs Kanban vs calendar) while still pointing to the same underlying records.

Forcing functions happen automatically when adding rows inside filtered views—due dates and checkboxes can be set to match the filter.

Self-referential filters let a linked database inside a template automatically target the specific page where the template was spawned.

Rollups plus formulas can convert raw counts into polished labels like “1 task left” and “2 tasks left.”