Relations and rollups are the point at which Notion stops being a nicer Google Doc and starts being a small database. They are also where most people give up, because the documentation explains what the fields do without ever explaining why you would want them.
Here is the whole idea in one sentence: a relation connects two rows in different databases, and a rollup pulls a number or a value from the far side of that connection back into your row.
The problem they solve
Say you have a Projects database and a Tasks database. Each task belongs to a project. Without a relation, you type the project name into a text field on every task — and now nothing links, renaming a project breaks everything, and you cannot ask “how many tasks are left on this project?”
With a relation, each task points at an actual project row. Rename the project and every task follows. Open the project and you see its tasks listed. And once that link exists, a rollup can count them, sum their hours, or show the latest due date — automatically, forever.

Setting up a relation, step by step
- Open your Tasks database and add a new property.
- Choose property type Relation.
- Pick Projects as the database to relate to.
- Turn on Show on Projects. This creates the matching property on the other side so the link works in both directions — most people miss this and then wonder why the project page looks empty.
- Name both sides clearly. “Project” on the task, “Tasks” on the project.
That is it. Now open any task and choose a project from the dropdown. Notion is doing a genuine join behind that dropdown, not a text match.
Rollups: what each function does
Add a rollup on the Projects database. It asks three things: which relation to follow, which property to read on the other side, and what to do with the values it finds. That last part is where the useful stuff lives.
| Calculation | What it returns | Good for |
|---|---|---|
| Count all | Number of related rows | Total tasks on a project |
| Count checked | How many checkboxes are ticked | Tasks completed |
| Percent checked | Completion as a percentage | A real progress bar |
| Sum | Adds a number property | Total hours, total budget |
| Average | Mean of a number property | Average task size |
| Earliest / Latest date | Min or max date | Project start and end |
| Show original | The raw values, listed | Seeing which owners are involved |
| Unique values | Distinct entries only | How many people are on it |

Three setups worth copying
A project progress bar. Tasks database has a Done checkbox. On Projects, add a rollup: relation Tasks, property Done, calculate Percent checked. Then click the rollup and set its display to Bar. Two minutes of work and every project now shows live completion.
Client hours this month. A Time Entries database relates to Clients. On Clients, roll up the Hours property with Sum. Filter the Time Entries view by date to scope it, or add a formula that only counts current-month entries.
Reading list by author. Books relate to Authors. On Authors, roll up Rating with Average, and Count all for how many of theirs you have read. Suddenly your library answers questions instead of just storing rows.
The limits that will bite you
- Rollups cannot follow rollups. You cannot roll up a value that is itself a rollup two databases away. Workarounds involve a formula on the middle database — clumsy, but it works.
- Filtering by rollup is limited. Some rollup types cannot be filtered or sorted in views. If you need to filter on it, wrap it in a formula that returns a plain number.
- They recalculate live. On a database with thousands of rows and several rollups, page loads slow noticeably. This is the most common cause of a sluggish workspace — we went through the other causes in why Notion is slow.
- Relations are not available on simple tables. The table must be a full database, not an inline simple table.
- Deleting a relation deletes both sides. And the links, permanently. Duplicate the database first if you are unsure.

One-way or two-way?
Notion lets you create a relation that only shows on one side. It looks tidier, and it is almost always the wrong choice — because a rollup can only follow a relation that exists on the database you are rolling up from.
If you build a one-way relation from Tasks to Projects and later want a task count on the project, you have to convert it, which reshuffles the property. Turn on both sides at the start. You can always hide the property in a view.
Common questions
Can a row relate to more than one row?
Yes — relations are many-to-many by default. One task can belong to several projects, and one project holds many tasks. If you want to force a single choice, there is a “limit to one” setting on the relation.
Can a database relate to itself?
Yes, and it is genuinely useful — parent and sub-task hierarchies, or linked notes referencing each other. Pick the same database when creating the relation.
Do rollups work offline?
Cached values display, but nothing recalculates until you reconnect. Notion’s offline behaviour has a few more edges worth knowing — covered in how Notion offline mode actually works.
Do relations survive duplicating a database?
Partly. Duplicating one database keeps relations pointing at the original target, which is usually not what you want. Duplicate the whole page containing both databases and the links re-map to the copies.

Leave a Reply