> ## Content Index
> Fetch the complete content index at: https://notionsolutions.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# Notion Database Organization: When to Split, When to Merge, and How to Clean Up
- URL: https://notionsolutions.net/notion-database-organization/
- Published: 2026-10-30T10:17:14.000Z
- Updated: 2026-11-02T14:09:50.000Z
- Description: Keep one Notion database per kind of record, connect them with relations and use filtered views for every subset. Here's when a split is justified, which property answers which question, Notion's published database limits, and a clean-up order that keeps each step reversible.
- Author: Kevin Turner
- Tags: guide, databases

**Keep one Notion database per kind of record (Clients, Projects, Tasks, Meetings, Invoices), connect them with relations, and show filtered views wherever you need a subset. Don't create a new database for each client or each year.** I'd keep every task in one Tasks database even with a dozen clients, because a property or template change then applies everywhere and a cross-client “due this week” list is a filter, not a merge job. Split a list only when its records need different properties or when client access forces it.

For a solo freelancer, start with three master databases and build them with the [client project tracker steps](https://notionsolutions.net/notion-client-project-tracker-template/). For a studio that shares records with clients, choose the access route first, because it decides whether a per-client split is a mess or a requirement. For related record types you want side by side, such as projects and their tasks, use one database with several data sources. The master-database idea isn't new: [Notion VIP's golden rules](https://www.notion.vip/insights/golden-rules-of-notion?ref=notionsolutions.net) state it as “Structure all information in related master databases, then create dashboards for accessing it contextually.” This guide adds Notion's own limits, data sources, and a clean-up order for a workspace that grew by accident.

## When two lists belong in one database

Use one database when the records share the same properties and move through the same stages. Every client task has a due date, an owner and a status, whichever client it belongs to, so the client is a value on the task rather than a reason for a new database. Use separate databases when the records need different properties: a client has a main contact and billing details, a task has a due date and an assignee. Join those two with a relation. When two groups differ only by a label, such as active and past clients or 2025 and 2026 projects, the label is a property value.

Notion VIP makes the same call for tasks: “Avoid separate task databases for each project or client. Instead, centralize them in a single Tasks database, then view them in contextual linked views.” Its broader rule, “Any information of the same type, with the same structural features, belongs in the same database,” is the test I'd apply to every list you're unsure about.

__Split-or-merge decisions for common freelance lists__
| The lists you have                  | Decision                                                              | Why                                                                                                                         |
| ----------------------------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| A task list per client              | One Tasks database with a Client relation                             | Same properties and stages; the client is a value on each task.                                                             |
| “Projects 2024” and “Projects 2025” | One Projects database; filter by a Date property                      | The year is a date question. A copy per year splits every rollup and report in two.                                         |
| Active and past clients             | One Clients database with a Status property                           | The fields don't change; only the stage does.                                                                               |
| Clients and their contacts          | Separate databases, related                                           | A contact has an email and a role; one client can have several contacts.                                                    |
| Meetings and tasks                  | Separate databases, each related to Projects                          | A meeting has a date and notes; a task has an owner, a due date and a status.                                               |
| Invoices and projects               | Separate databases, related                                           | An invoice has an amount and a paid state; one project can have several invoices.                                           |
| Leads, clients and deals for a CRM  | Separate related databases, or one database with several data sources | Different properties per record type; Notion uses a CRM with contacts, companies and deals as its own multi-source example. |

[![Decision diagram: lists with the same properties and stages go in one database with a property value; lists with different properties become separate related databases, or one database with a data source per record type](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/notion-database-organization-split-or-merge.webp)](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/notion-database-organization-split-or-merge.webp?ref=notionsolutions.net)

Two questions settle most split-or-merge calls: same properties, and whether the record types belong side by side.

Notion will build either structure without complaint. It can't tell you that “Acme tasks” and “Beta tasks” are the same kind of record; that call stays with you, and the property test is the quickest way to make it. If you're weighing one client board against one board per client, the [Kanban board guide](https://notionsolutions.net/notion-kanban-board/) works through the same question for Board view.

Check copies made by duplication before you rely on them. Notion's [relations help](https://www.notion.com/help/relations-and-rollups?ref=notionsolutions.net) explains that when you duplicate a related database, “we convert the relation from a 2-way sync to a 1-way sync,” so the copy doesn't show up as a relation on the other database until you convert it back. A “Projects 2025” copy can look complete while its clients show none of its projects.

### When one database should hold several data sources

Notion's [data sources help](https://www.notion.com/help/data-sources-and-linked-databases?ref=notionsolutions.net) separates a database from its data: “Every database is made up of at least one data source,” and “A database can contain multiple data sources in one,” such as a tasks source and a projects source managed together. Its examples are a CRM with contacts, companies, deals and activities, and a project setup with members, projects, tasks and resources. To add a source, click the slider icon at the top of the database, select Manage data sources, then Add data source for a new one or Link existing data source to bring in one you already have.

Two access rules matter before you combine anything. Notion says “You can't set a different level of access for each source in your database,” and every linked data source respects the access level of its original database. The sharing help adds that each data source can have its own page-level permission rules when a database contains several, a Business and Enterprise feature. If you link a source into another database, keep its intake form on the original: Notion says forms can only be added to the original database that contains the data source.

I'd use several sources when different record types belong in one place, such as a project and its tasks, and still keep one record type per source. Each source keeps its own structure: Notion's [developer guide to data sources](https://developers.notion.com/guides/get-started/upgrade-guide-2025-09-03?ref=notionsolutions.net) says a change to one data source's properties doesn't affect another source's schema, even when both share a database, and its [templates guide](https://developers.notion.com/guides/data-apis/creating-pages-from-templates?ref=notionsolutions.net) describes templates as special pages under one data source. Splitting one record type across sources, say one source per client, brings back the copy problem inside a single database.

## One question, one property

Each property should answer one question about the record, and each question should have one property. Three tag columns that all mean “what stage is this in?” give you three places to forget an update and three filters to keep in step. Notion's [property reference](https://www.notion.com/help/database-properties?ref=notionsolutions.net) describes what each type is for; the table maps those types to the questions a client database asks.

__Which property type answers which question__
| Question the record answers        | Property     | Why this type                                                                                               |
| ---------------------------------- | ------------ | ----------------------------------------------------------------------------------------------------------- |
| What stage is it in?               | Status       | Options sit in To-do, In Progress or Complete groups that can't be changed, so filters stay predictable.    |
| Which client or project is it for? | Relation     | The client is a record with its own page; a relation connects the two and lets rollups summarize across it. |
| What single kind is it?            | Select       | One option from a list, which Notion calls useful for categorization.                                       |
| Which several labels apply?        | Multi-select | Only when more than one label genuinely applies to the same record.                                         |
| When is it due?                    | Date         | A date or a range, the type Notion suggests for deadlines, especially in calendar and timeline views.       |
| Who owns it?                       | Person       | Tags a workspace member, and page-level access rules can key off it.                                        |
| When was it added?                 | Created time | Set automatically and not editable; Notion suggests it for filtering out old pages.                         |

Status beats Select for workflow stage, and Notion's [status property guide](https://www.notion.com/help/guides/status-property-gives-clarity-on-tasks?ref=notionsolutions.net) gives the reason. With a Select, “anyone can just type in a whole new category, without knowing that a similar one already exists,” and a view then needs several filters to catch every variant: “If you miss one, your view of a project's status is compromised.” Status keeps its three groups fixed while you add as many stages inside them as you need.

The client name is the property most worth turning into a relation. As a Select, “Acme” is text in a dropdown; as a Relation to Clients, it's a link to the client's page, where rollups can count open tasks or sum invoices. The [relations and rollups guide](https://notionsolutions.net/notion-relations-and-rollups/) covers building that link and the calculation on top of it.

When you find two properties doing one job, merge them. Notion's [database performance guide](https://www.notion.com/help/optimize-database-load-times-and-performance?ref=notionsolutions.net) says, “If you have multiple properties that serve the same purpose, consider merging them,” and the property reference gives the same advice about duplicate “Status” or “Category” properties. Keep the one with the right type, move any values the others hold into it, then delete the extras.

Put anything you'll filter or find in a list into a property. Notion's database search looks at page titles and properties, so a detail that lives only in the page body won't surface there; the [database search guide](https://notionsolutions.net/notion-database-search-page-text/) covers the search that does reach page text. Long notes still belong in the page body, which doesn't count toward the property size limit covered below.

Hiding a column and restricting it are different jobs. Property visibility hides or shows a property in a database view, which keeps that view readable. Restricting who can see a property is [property access](https://www.notion.com/help/database-property-access?ref=notionsolutions.net), a Business and Enterprise feature: you can add a max of 20 properties with permissions, the rules go on the original database rather than a linked view, and you need Full access to set them. Notion also says “A column rule never gives someone access to a database page that they can't already open.” If a client reports a missing column, the [column access troubleshooting guide](https://notionsolutions.net/notion-client-cannot-see-database-property/) separates the two causes.

## Names you'll still understand in a year

Name each database after the record it holds, in the plural: Clients, Projects, Tasks, Meetings, Invoices. Notion VIP's rule is that “the most intuitive name will be the plural form of that entity,” so it calls a contacts list “People” and a calendar “Events.” A name like “Acme board” or “Q3 stuff” describes a view, not a record type; if a database carries one, check whether it's a copy that should be a filter.

Name properties after the question they answer: Due, Client, Owner, Invoice sent. Keep Select and Status options short too. That's more than tidiness: Notion caps the total size of a database's structure, and one of its fixes is to shorten option names, “for example, you could change a Complete option to Done.”

## Where databases should live

Put each master database on its own page, then show it elsewhere through linked views. Notion's performance guide gives that order for large workspaces: “Try housing each database in its own page first,” then type /linked on the working page and select Linked view of a database. One linked database can hold several views, and Notion notes that each view can point to a different source database. With a single linked database, only the open view is listening for updates, and Notion says you should see a performance improvement over many inline databases on one busy page.

That gives a short sidebar: one Data page holding Clients, Projects, Tasks and the rest as full-page databases, and working pages, such as a weekly dashboard or a client page, that contain only linked views. The [weekly review dashboard](https://notionsolutions.net/notion-project-dashboard-weekly-review/) is built this way on one set of project and task records. Linked views share the records, not just the look. Edits to a linked source's title, properties or pages change the original, while the views, filters, sorts and groups you create there stay local. The guide on [which linked database edits reach the original](https://notionsolutions.net/notion-linked-database-edits-original/) covers how to check before you change anything.

Notion VIP goes further with a single “HQ” page that contains the whole workspace: master databases linked as full pages at the bottom, linked views of current items at the top. It says this lets you back up the workspace “simply by duplicating that page.” A duplicate is a convenient copy, but I wouldn't make it the recovery plan; the [client project backup guide](https://notionsolutions.net/notion-client-project-backup/) separates exports from Notion's own restore options.

On Plus, Business and Enterprise plans the sidebar has a Teamspaces section. Notion's [teamspaces guide](https://www.notion.com/help/intro-to-teamspaces?ref=notionsolutions.net) says “you'll only need one default teamspace” in most cases and recommends “no more than three default, even for large workspaces.” A teamspace can be Open (anyone can join and view), Closed (visible, but invite only) or Private (Business and Enterprise only, hidden from people not added). I wouldn't create a teamspace per client to sort records: teamspaces “can only be archived, not deleted,” and the client is already a property.

Keep the Private section for drafts. Notion's [sidebar help](https://www.notion.com/help/navigate-with-the-sidebar?ref=notionsolutions.net) says anything there is only visible to you, and dragging a page from Workspace into Private makes everyone else lose access, so a master database doesn't belong there once anyone else works in it. For a view you open every day, pin it instead: Notion lets you pin a database view to the sidebar “so a view you check often is one click away no matter where the database lives.”

[![Map of a Data page holding Clients, Projects, Tasks, Meetings and Invoices as related full-page databases, with linked views on a weekly dashboard and a client page pointing back to them, and the Private section kept for drafts](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/notion-database-organization-data-page-map.webp)](https://storage.ghost.io/c/5c/30/5c30c46b-86a3-4d20-984f-4f6ae8ad1ed2/content/images/2026/10/notion-database-organization-data-page-map.webp?ref=notionsolutions.net)

Originals live on one Data page; dashboards and client pages hold only linked views of them.

## Use views instead of copies

Whenever you're tempted to duplicate a database to show a subset, add a view. A view changes which records appear and how; the records stay in one place. Notion's [views and filters help](https://www.notion.com/help/views-filters-and-sorts?ref=notionsolutions.net) notes that “Each database view has its own settings,” so a filter on one view doesn't touch the others, and when you add a filter you choose whether to Save for everyone or keep it for yourself. The [guide to choosing a view for the question](https://notionsolutions.net/notion-database-views-for-client-work/) matches each layout to the question it answers, and the [missing tasks guide](https://notionsolutions.net/notion-filtered-view-missing-tasks/) helps when a filter hides more than you meant.

A view isn't a permission. Notion's [sharing and permissions help](https://www.notion.com/help/sharing-and-permissions?ref=notionsolutions.net) says it “respects the broadest level of access given to a user,” so a filter controls what a view shows, not what a person can open. If clients need their own slice, settle the access route in the [client portal permissions guide](https://notionsolutions.net/notion-client-portal-permissions/) before you build their views. Page-level access rules on one master database need Business or Enterprise, and they must be set on the source database, not a linked view.

## Keep new records consistent with templates and layouts

A clean structure starts to drift the first time someone creates a task by hand and skips half the properties. [Database templates](https://www.notion.com/help/database-templates?ref=notionsolutions.net) fix that at the source: click the dropdown arrow next to New at the top right of the database, then select + New template. Templates live only in the database where you created them, which is one more reason to keep one Tasks database rather than eight with eight template sets to keep in step.

Two template rules prevent most surprises. Leave relation properties empty in a template unless every new page should link to the same record; Notion warns against filling one in “unless you want every page you create with that template to relate to the same existing page(s).” The [same-client template fix](https://notionsolutions.net/notion-template-same-relation/) covers it when that has already happened. For routine work, a template can repeat daily, weekly, monthly or yearly, and the [recurring tasks guide](https://notionsolutions.net/notion-recurring-tasks/) compares that with repeating after completion.

A [page layout](https://www.notion.com/help/layouts?ref=notionsolutions.net) does for the page what a template does for its starting content. Notion says a layout “will apply to all pages in the database” and can't be limited to specific pages or views, which suits a master database. You need at least Can edit access to build one, the full builder works on desktop or web with the database open as a full page, and you can pin up to 15 properties. A tabbed layout can add a tab with views of another database, such as the tasks that belong to a project. If you change your mind, Reset to original page layout deletes no properties.

## Keep databases fast and under Notion's limits

Most of what slows a database comes from structure decisions you make once. The performance guide names each factor; the table pairs Notion's wording with the change it implies.

__Notion's documented performance factors and what to change__
| Factor                         | Notion's wording                                                                                             | What to change                                                                  |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
| Page count                     | “If your database has a ton of pages, it might be slower to load.”                                           | Remove unnecessary or duplicate pages, or filter old pages out on Created time. |
| Visible properties             | “The more visible properties your database has, the longer it might take to load.”                           | Hide properties a view doesn't need; delete properties no view uses.            |
| Sorts and filters              | A sort or filter on “title, text, formula, or rollup” properties “can make load times longer.”               | Filter on select, multi-select, status, number or date properties instead.      |
| Formula and rollup chains      | “a formula that depends on several other formulas that each depend on rollups may take longer to calculate.” | Shorten the chain before you add another layer.                                 |
| Inline databases on busy pages | “avoid having lots of inline databases, like dashboards, in high-traffic pages.”                             | Full-page databases plus one linked database with several views.                |
| Property access rules          | “A database with many property access rules may load more slowly.”                                           | Restrict only the columns that need it.                                         |

If a formula in such a chain reports a depth error, the [rollup troubleshooting guide](https://notionsolutions.net/notion-rollup-not-working/) shows how to simplify the dependency chain.

## Clean up a messy workspace in a safe order

Clean-up is where links break, so work in an order that keeps each step reversible. Take one record type, starting with tasks, finish it, then move to the next. Notion moves sources and pages for you; deciding which database is the keeper and what each property means stays with you.

1. **Know your way back first.** Read the [recovery options in the backup guide](https://notionsolutions.net/notion-client-project-backup/) and note what version history your plan keeps. Notion's [restore help](https://www.notion.com/help/duplicate-delete-and-restore-content?ref=notionsolutions.net) lists 7 days on Free, 30 days on Plus, 90 days on Business and any number of days on Enterprise, and you need at least Can edit access to open a page's version history.
2. **List each record type and where it lives.** One line per database: what it holds, its properties, and which pages show it. Notion VIP blueprints databases in a spreadsheet, a sheet per database with properties as column headings and a few sample items, and it says to use real information rather than hypotheticals. The same sheet works as an audit of what you already have.
3. **Pick the keeper for each type.** Choose the database with the right property types and the most relations pointing at it. The others are copies to bring in.
4. **Bring the copies in.** To keep a copy as its own source inside the keeper, open the slider icon on the copy, select Manage data sources, then ••• next to the source and Move. Notion adds it to the destination database as a data source, and you choose whether its views move too; views left behind become linked views. Notion's help asks for Full access in the database to move its sources. Moving a source keeps its rows in their own source. If you want one set of rows instead, make the copy's property names and types match the keeper's, move a few pages, check their values, then move the rest. For tasks with sub-items, Notion's [sub-items help](https://www.notion.com/help/tasks-and-dependencies?ref=notionsolutions.net) says sub-items get turned on in the target database when you have permission; without it, they become parent items after the move. Skip a CSV round-trip: relations export as plain text URLs, and the CSV can't be re-imported to restore them.
5. **Unify the properties.** One name and one type per question, then delete the duplicates. Deleting a property deletes its data, but you can restore it from the slider icon, Edit properties, then Deleted properties. Notion keeps up to 1.5MB of deleted properties there; past that you have to delete some permanently, and permanently deleted properties can't be recovered.
6. **Put linked views where the copies were.** Once a copy's records are in the keeper, add a linked view of the keeper on that page, filtered to what the page needs, so the old links still lead somewhere useful.
7. **Archive with a property, not a second database.** A Complete status or an Archived option, plus a filter on your working views, keeps old records out of sight without splitting your reports. The [client CRM workflow](https://notionsolutions.net/notion-client-crm-workflow/) covers archiving past clients. On Business and Enterprise, Notion's Archive (in beta) marks pages as no longer current without deleting them and filters archived database content out of views; Settings → View archived pages shows them again.
8. **Delete last.** Empty copies go to Trash, where pages stay 30 days by default before permanent deletion. Notion retains permanently deleted pages for 30 more days before they become inaccessible to everyone, workspace owners included, and Enterprise owners can change these settings. Dragging a page into Trash also deletes everything nested in it, including database items, so check a page for databases before you drag it.

Once the structure settles, protect it. Can edit content lets people create and edit pages and property values without changing the database's properties, views, sorts or filters. The [page lock vs database lock guide](https://notionsolutions.net/notion-lock-page-vs-database/) compares that with locking the database.

## Structure options compared: limits and a worked example

Notion publishes hard limits rather than timings, so the comparison below uses those limits plus a worked example you can check by counting. The limits come from the performance guide unless a row says otherwise.

__Notion's published database limits and what a freelance setup meets first__
| Limit                                   | Value   | What happens                                                                                  | What a freelance setup meets first                                                  |
| --------------------------------------- | ------- | --------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Properties per database                 | 500     | You can't add new properties until you remove some.                                           | Rarely the count; duplicate properties push you toward the structure limit sooner.  |
| Rows per database                       | 250,000 | A warning as you get close; at or over the limit, new rows fail with an error.                | One master Tasks database shares this ceiling across all clients.                   |
| Property data per page                  | 2.5MB   | New changes stop saving. Uploaded files, formulas, rollups and page body content don't count. | Long property options and many people tagged in a Person property on the same page. |
| Database structure                      | 1.5MB   | New changes stop saving; you meet it when adding a property or an option.                     | Many Select and Multi-select options, long option names and long formulas.          |
| Two-way relation references to one page | 10,000  | The next reference made in Database B won't show on the page in Database A.                   | A catch-all page, such as an “Internal” client, that every task relates to.         |
| Deleted-property trash                  | 1.5MB   | You have to delete some properties permanently; those can't be recovered.                     | A clean-up that deletes many properties at once.                                    |
| Properties with access rules            | 20      | No more columns can carry rules (Business and Enterprise feature).                            | Restricting client-facing columns one at a time.                                    |
| Pinned properties in a page layout      | 15      | The layout builder pins no more than 15.                                                      | Busy project pages with every property pinned.                                      |

The worked example uses 8 active clients whose tasks share the same properties (Due, Status, Owner, Client). It compares one Tasks database per client, one master Tasks database with a Client relation, and one database with a data source per client.

__Worked example: 8 active clients, three ways to hold their tasks__
| What you maintain                 | 8 per-client databases                                                         | 1 master database                                                        | 1 database, 8 sources                                                                       |
| --------------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
| Databases to look after           | 8                                                                              | 1                                                                        | 1 database holding 8 sources                                                                |
| Edits to add one new property     | 8                                                                              | 1                                                                        | 8, because properties belong to each source                                                 |
| Template sets to keep in step     | 8                                                                              | 1                                                                        | 8, because templates sit under each source                                                  |
| Cross-client “due this week” list | 8 lists: 8 views, or one linked database with 8 views, one per source database | 1 view with a Due filter                                                 | 8 views, because each added source appears as its own view                                  |
| Client-specific access            | Share each client's database separately, without page-level rules              | Page-level access rules on the source database (Business and Enterprise) | Page-level rules per source (Business and Enterprise); no different access level per source |
| Row ceiling                       | 250,000 in each database                                                       | 250,000 shared, or 31,250 tasks per client at an even split              | Notion states the 250,000 limit per database                                                |

The master database wins four of the six rows outright: one database, one edit per new property, one template set and one filter for the cross-client list. Per-client databases win two: separate sharing without page-level rules (a Business and Enterprise feature), and eight separate row ceilings, although at an even split the master database still holds 31,250 tasks per client (250,000 ÷ 8). A source per client wins no row here; it gives you one container while keeping the per-client maintenance: 8 property edits, 8 template sets and 8 views. That's why I'd reserve several data sources for different record types and keep clients as a relation.

## Verdict

Keep one database per record type, connect them with relations, and put views everywhere else. Split only for different properties, or when access leaves you no other way to keep one client's records apart from another's. Use a database with several data sources when different record types belong side by side, such as a project and its tasks. If several people need to maintain linked client data through forms and defined fields, compare [Notion with Airtable for a client database](https://notionsolutions.net/notion-vs-airtable-client-database/) before you rebuild.

I'd start the clean-up with tasks, because a task list per client multiplies fastest: every new client adds another copy. Once one Tasks database feeds every dashboard and client page, the other record types have a pattern to follow.