Managing tasks in Notion: databases, views, and where it gets heavy
A Notion task database is an ordinary Notion database that has been told which of its properties hold the status, the assignee and the due date. Once those three are mapped, Notion treats every row as a task: anything assigned to you shows up in My Tasks on your Home tab, you can turn on sprints, and each task can get a permanent ID such as TASK-123. You can convert any existing table this way from the database settings, and undo it later. That is the whole mechanism. The harder questions are how to structure the database so it stays trustworthy as the team grows, and where Notion's own documented limits start to make a task setup feel heavy. This article covers both, with the exact menu paths and the numbers from Notion's help center as checked on October 8, 2026.
How a task database differs from a normal database
Every Notion database is a collection of pages with properties. A task database adds one thing: Notion knows which property means "status", which means "assignee" and which means "due date". Notion's help center describes it as a type of database that "requires a status, assignee, and due date property to help you track the work that you need to get done."
To turn a table into a task database:
- Open the settings menu at the top of the database.
- Under Database settings, select More settings.
- Select Turn into Tasks.
- Map your existing properties to status, assignee and due date, or choose Create new for any that do not exist yet.
- Select Turn into task database.
To reverse it, follow the same path and choose Undo Task database. Nothing is deleted; the database simply stops being treated as a source of tasks.
What you gain from the conversion is mostly outside the database itself. Tasks assigned to you from every task database in the workspace appear together in My Tasks, a widget on Home. Without the conversion, a person who works across three projects has to open three tables to see their week. With it, they open one place.
You can also add an ID property. Click the plus sign at the far right of the database, choose ID, and optionally set a prefix. Notion assigns a number to every existing and future row, and those numbers never change. With a prefix in place, each task is reachable at a short URL such as notion.so/TASK-123, which is useful when tasks are referenced in chat or commit messages. IDs start at 1 and are assigned to deleted pages too, so gaps in the sequence are normal.
Structuring the database so people trust it
The technical setup takes ten minutes. The structure decides whether the team still uses it after a month. A few decisions matter more than the rest.
One task database, many views
Teams often end up with a tasks table inside each project page. It feels organized at first, but it splits the team's work into separate sources and makes cross project views awkward. A single task database with a Project relation, filtered into a view on each project page, is easier to maintain. Notion's own performance guidance points the same way: it recommends housing each database on its own page and using linked views elsewhere, because a page that loads many separate inline databases at once is slower.
Status options that mean one thing each
The status property is where trust breaks down first. If "In progress" means "someone opened it" for one person and "half done" for another, the board stops being informative. Keep the list short, usually four or five options, and write one sentence for each in the database description. A separate "Blocked" option is less useful than leaving a blocked task in its current status and marking it with a checkbox, because the status then still shows how far the work got.
Properties that earn their place
Every property you add is something someone must fill in, and something that makes the database slower. Start with the three required properties plus Project and Priority. Add more only when a specific view or report needs them. If a property has been empty on most rows for a month, it is a candidate for removal.
A starting set for a team of five to ten people looks like this:
| Property | Type | Purpose |
|---|---|---|
| Name | Title | What the task is, written as an action |
| Status | Status | Mapped as the task status |
| Assignee | Person | Mapped as the task assignee |
| Due | Date | Mapped as the task due date |
| Project | Relation | Links the task to a project page |
| Priority | Select | Three options at most |
| ID | ID | Permanent reference for chat and commits |
Seven properties is enough to run a board, a planning table and personal views. Anything beyond that should be added because a real view or report needs it, not because a template included it.
A small set of named views
Most teams need four views at most: a board grouped by status for the daily stand up, a table sorted by due date for planning, a "My tasks" filter for each person, and a calendar or timeline for deadlines. Name them by purpose, not by layout, so that "Stand up" is more discoverable than "Board 2".
Sprints, if the team works in cycles
Notion's sprint feature only works on a task database. Once a database is converted, open the settings menu, choose More settings, then Sprints, and select Turn on sprints.
Notion then creates two things in the sidebar. The Sprint board has three views: Current Sprint, Sprint planning (which shows the current, next and last sprint plus unassigned tasks) and Backlog. The Sprints database lists each sprint and includes a Timeline view.
Sprint settings live under the same More settings menu:
- Duration from one to eight weeks.
- Start on, the weekday each sprint begins.
- Incomplete tasks, which can roll into the next sprint, return to the backlog, or stay in the original sprint.
- Automated sprints, which complete one sprint and start the next on schedule.
To close a sprint by hand, open Current sprint on the Sprint board and select Complete sprint. Notion asks for the next sprint's dates and what to do with unfinished tasks, then shifts the labels: Current becomes Last, the previous Last becomes Past, and Next becomes Current.
Two details are easy to miss. Sprint dates cannot be edited directly in the Sprints database; they come from the settings or from completing a sprint. And turning sprints off permanently deletes the sprints database, the sprint board and the relations between tasks and sprints. Turning them back on starts from scratch. For a holiday pause, Notion's advice is to switch off automated sprints rather than turn sprints off.
Where a Notion task setup gets heavy
Notion is flexible because almost everything is a page with properties. The same flexibility produces the points where a task system starts to feel slow or fragile. Notion's help center is specific about several of them.
Speed. Notion lists three things that slow a database down: a large number of pages, a large number of visible properties, and sorts or filters on title, text, formula or rollup properties. A task database that has accumulated two years of finished work, twenty properties and a view sorted by a rollup is likely to feel sluggish. Notion suggests filtering on simple properties such as select, status, number and date, hiding properties a view does not need, and filtering out old pages by created time.
Size limits. Each database can hold up to 250,000 rows and up to 500 properties. All property data on a single row is limited to 2.5MB, and the overall structure of the database, meaning its properties and their options, is limited to 1.5MB. For two way relations, once the same page has been referenced 10,000 times from the other database, new references stop appearing on the other side. Small teams will not reach the row limit, but long select lists and many properties can approach the structural limit sooner than expected.
Plan limits. On Notion's pricing page, checked on October 8, 2026, the Free plan allows unlimited pages and blocks for individuals but limits them for workspaces with two or more members, caps file uploads at 5MB, keeps 7 days of page history, and allows 10 external guests. Plus is $10 per member per month billed yearly or $12 monthly, with unlimited blocks and uploads and 30 days of history. Business is $20 per member per month billed yearly or $24 monthly, adding private teamspaces, granular database permissions and 90 days of history. Prices are shown in local currency in some regions, so confirm on the page itself.
Maintenance. The less visible weight is that someone has to own the structure. Every new property, view and automation is a design decision, and in a team of five, that person is usually also doing their own work. When nobody owns it, the database drifts toward many half used properties and views that nobody remembers creating.
When the team has outgrown Notion for tasks
None of this means Notion is the wrong tool for tasks. For a team that already keeps its specs, meeting notes and wiki in Notion, having tasks next to those documents is a real advantage, and many teams never need anything else. Keep tasks in Notion if most of the following are true: the tasks are closely tied to documents, the team is small, someone enjoys maintaining the structure, and nobody needs a Gantt style view of dependencies.
The signals that a team has outgrown it are usually practical rather than technical. The person who built the database has left and nobody wants to change it. People keep a private list elsewhere because My Tasks feels incomplete. Planning meetings start with ten minutes of fixing statuses. Or the team needs to plan dates and dependencies across several projects, and the timeline view is being stretched further than it comfortably goes.
At that point, the choice is between investing in the Notion setup, by giving someone time to own it and trimming it back to the essentials, or moving tasks to a dedicated tool while keeping documents in Notion. The second option is common. Specs and notes stay where they are, and each task links back to the relevant Notion page.
A dedicated kanban board tool is one way to do that. One example offers eight board types, including kanban, Gantt, calendar, list and timetable, all showing the same cards, with chat and comments on each card and custom fields of six types. It is free for up to 5 people and 10 boards, and $5 per user per month after that. It is not a document tool and has no equivalent of Notion's nested pages and wiki, so it only makes sense alongside Notion or another place for documents, not as a replacement for everything Notion does. The Notion comparison sets the two side by side, and the feature overview lists the board types and card fields.
What to change first
Open your task database settings and check whether it has been converted with Turn into Tasks; if not, convert it so that My Tasks starts working for everyone. Then remove any property that has been empty on most rows for a month, and replace any sort on a formula or rollup with a filter on status or date. If after that the team still keeps tasks somewhere else, try moving just the task list to a dedicated board such as Pinateca and keep the documents in Notion.
Q1. How do I make a task database in Notion?
Open the database's settings menu, choose More settings, then Turn into Tasks. Map the properties that hold status, assignee and due date, or create them, and select Turn into task database. Tasks assigned to you from that database then appear in My Tasks on your Home tab.
Q2. What is the difference between a task database and a regular database in Notion?
A task database is a regular database where Notion knows which properties are status, assignee and due date. That mapping is what feeds My Tasks and makes sprints available. You can switch back with Undo Task database in the same menu, and no data is lost.
Q3. Why is my Notion task database slow?
Notion's help center names three causes: many pages, many visible properties, and sorts or filters on title, text, formula or rollup properties. Filtering on simple properties such as status or date, hiding unneeded properties, and filtering out old pages by created time usually helps.
Q4. Is there a limit on how many tasks a Notion database can hold?
Yes. Each database can hold up to 250,000 rows and 500 properties. All property data on one row is limited to 2.5MB, and the database's overall property structure is limited to 1.5MB. Small teams rarely hit the row limit, but long select lists can approach the structure limit.