By 
A Notion database can have up to 500 properties. At that limit, you cannot create another property until you remove some, according to Notion’s current property-count limit. Hiding columns does not remove them from the database.
If you have fewer than 500 properties and still see a property-data warning, check the affected database or record against the size limits below. Notion also limits the database’s property structure and the property data on each record. I’d identify the affected limit before deleting anything; a count problem and a data-size problem need different cleanup decisions.
Property count and property data have different limits
| Limit | Applies to | Useful first check |
|---|---|---|
| 500 properties | The number of properties in a database | Find unused or duplicate fields. A new view does not create a smaller schema. |
| 1.5MB database structure | The total size of the database’s properties, including option definitions | Inspect large Select or Multi-select option lists and unnecessary formula definitions. |
| 2.5MB per database page | The combined property data on one record, with exclusions | Inspect the record identified by the warning and the data stored in its properties. |
| 1.5MB deleted-property store | Properties kept in the database’s deleted-property area | Preserve needed data before considering permanent deletion. |
These limits come from Notion’s database size documentation. The 2.5MB page limit excludes the actual size of uploaded files, formulas and rollups, and content in the page body. The 1.5MB database limit concerns the structure: adding another option to a large dropdown can encounter it even when you are not adding a new column. Notion says new changes will not be saved once database size limits are hit.
Read the message closely. A formula-depth error concerns a chain of up to 15 layers, with each referenced formula or rollup adding a layer. It does not mean the database can have only 15 properties. A pinned-property limit or a count of displayed columns is also a different question from the total property count.
If the add-property control is unavailable without a limit warning, check your access before restructuring the database. Can edit content permits editing records and their values, but not the database structure.
Match the failed action to the affected limit
Record what you were doing when the warning appeared. “I cannot create field 501,” “I cannot add another Select option,” and “this one record will not save” are different starting points. The number of visible columns cannot resolve those differences.
| What failed? | Inspect first | What the check can establish |
|---|---|---|
| Creating another property | The full property list and the exact warning | Whether the database is at the 500-field cap or the warning concerns structure size |
| Adding a Select or Multi-select option | The affected field's option definitions | Whether structure-size cleanup is relevant; being below 500 does not rule it out |
| Saving data on one record with a page banner | That record's populated property values | Whether the per-page property-data condition applies rather than a database-wide field count |
Notion documents a banner on specific pages at the page-data limit, and structure-size problems when adding a property or option. Use the symptom to decide what to inspect, not as a final diagnosis. Keep the exact warning and the page or database link before you change anything. Do not infer a precise byte count from the length of the text you can see.
Inventory fields before deleting them
Open database settings and select Edit properties. That menu lets you search for properties and manage individual fields, as described in Notion’s property-management instructions. Review the complete list rather than counting the columns currently visible in one view.
For each candidate for removal, record its purpose and whether any records contain values you need. Then trace its dependencies. A field may feed a formula or rollup even when nobody reads it directly; a template or automation may still populate it.
- Keep fields needed for current decisions, historical reporting, or another calculation.
- Investigate fields that appear to ask the same question under different names.
- Remove a field only after confirming its data and dependent rules are no longer needed.
A hidden property is not automatically unused. Property visibility changes what a view displays; the property remains in the database. Deleting old records likewise changes the number of rows, not the number of fields.
Before changing live data, preserve an export of the relevant values and record the current configuration. Check the exported contents rather than assuming that a download includes everything you need. The client-project backup guide explains the limits of treating an export as a restore.
A useful inventory records both a field's data and its dependencies. For example, a hidden Legacy project code Text field may still identify old invoices; a Budget Number may feed a client rollup; and a Temporary flag checkbox may be genuinely unused. “Hidden,” “old,” and “not currently displayed” are not removal decisions. Confirm what each value would mean to the people who need the history.
Consolidate matching meanings, not similar names
Notion recommends deleting unused properties and consolidating similar ones at the count limit. That is a design decision; it is not a promise that the app will merge existing values for you.
If the database already has 500 properties, you cannot add a new consolidated field alongside the old ones yet: a property must be removed before another can be created. First look for one confirmed-unused field whose values and dependencies have been preserved, then use ordinary deletion to free that slot. Keep the active source fields while mapping their values. If you cannot identify a safe field to remove, pause the consolidation plan rather than deleting an active source merely to create an empty replacement.
Consider an example with separate checkbox fields for “Website,” “Email,” and “Print.” If more than one service can apply to the same project, a Multi-select could represent those categories in one field. If exactly one applies, use Select. The documented property types distinguish one choice from several tags. Preserve the old values and map them to the new options before retiring the checkboxes.
Two fields called “Project type” and “Engagement type” may still answer different questions. Compare their definitions and actual values first. A smaller property list that loses a useful distinction is a poor trade.
For a structure-size warning, inspect option lists as well as field count. Notion’s size guidance recommends removing unnecessary options, shortening option names, and shortening formulas. Record any changed labels and review rules that compare those labels. Keep the meaning clear rather than replacing a readable option with an unexplained abbreviation.
Change the data model when columns repeat the same pattern
Repeated fields such as “Client A deadline” and “Client B deadline” suggest that client-specific work belongs in separate records. In a project database, each project can have one deadline property and a link to its client. Adding a new client then means adding a record, rather than designing another client’s set of columns.
When clients, projects, and deliverables have their own identities and attributes, separate databases can make those distinctions easier to maintain. Relations connect those records and rollups summarize related data. Plan the relationships before moving values; splitting a database creates migration work and does not promise a particular performance gain.
Long explanations that are only read as notes can live in a record’s page body, which is excluded from the 2.5MB property-data limit. Keep a value in a typed property when the workflow needs to filter, sort, or calculate with it. Moving every field into one text paragraph would remove that structure.
Use ordinary deletion before permanent deletion
To delete a confirmed-unused field, go to Edit properties, select the property, and choose Delete property. Deleting the field also removes its values from the active records. Notion documents recovery through Edit properties → Deleted properties: select the restore arrow beside the deleted property.
The deleted-property area has its own 1.5MB capacity. If it is full, Notion may require permanent deletion to clear that store. Permanently deleting a property and its data prevents recovery through that area. Notion’s deleted-property guidance makes that risk explicit. Preserve anything needed before taking that step.
If a field was removed by mistake, restore that specific property from Deleted properties before continuing cleanup, then check its values and dependent views or calculations. Recovery from that area is different from retyping the field name: the documented restore action restores the deleted property and its data.
After cleanup, try the action that failed: create the intended property or save the affected value, then reopen the record to confirm it persisted. Check the views and calculations that depended on the changed fields. If the same warning remains, return to the specific count or size condition rather than deleting more fields at random.
If the remaining problem is slowness, treat it separately. Notion says hiding unnecessary visible properties may improve responsiveness; complex formula and rollup chains can also affect loading. A cleaner view can help that problem while leaving the property count unchanged.
