Ask around any organisation running SharePoint and you will hear some version of the claim that a list cannot hold more than five thousand items. It is one of the most durable misconceptions in the platform, and it produces some genuinely peculiar architecture — lists split alphabetically, a new list created every quarter, libraries duplicated by year.
None of that is necessary, because the number does not mean what people think it means.
What the number actually governs
A SharePoint list can hold thirty million items. The five thousand figure is the list view threshold: the maximum number of items a single database query may touch while being served. It is a limit on the query, not on the list.
The distinction matters because it tells you what the fix is. A list with fifty thousand items is entirely healthy provided every view and every query returns a manageable subset. The same list becomes unusable the moment somebody creates a view with no filter.
Why it exists
SharePoint stores list items in shared SQL tables. Without a ceiling, one unfiltered query against a large list would lock rows that other tenants and other sites need. The threshold is a fairness mechanism protecting shared infrastructure, which is why it cannot simply be raised in SharePoint Online.
The thing that actually breaks
Filtering is not sufficient on its own. The column you filter on must be indexed, and the index must exist before the list grows past the threshold.
This is the trap. A filtered view on an unindexed column still requires SharePoint to scan every item to evaluate the filter, so it hits the threshold anyway. And once a list is over the limit, you can no longer create an index through the interface, because doing so requires a scan of the very list that is now too large to scan.
Index the columns you will filter on while the list is still small. Retrofitting is possible but considerably more painful.
Designing lists that scale
- Index early. Any column that will appear in a view filter, a Power Automate trigger condition, or a lookup should be indexed from the start.
- Filter every view. No view should be capable of returning the whole list. Default to filtering on the current user, an open status, or a recent date range.
- Filter on indexed columns first. In a compound filter, the leading clause must use an indexed column, or the index is not used.
- Use folders deliberately. Folders are unfashionable but they partition the query space, and for very large libraries that is genuinely useful.
- Paginate in code. Anything reading the list programmatically — SPFx, Power Automate, Power BI — should page through results rather than requesting everything.
When splitting is the right answer
Occasionally it is. If two sets of items have genuinely different schemas, different permission requirements, or different retention rules, separate lists are correct — not because of the threshold, but because they are different things.
Splitting purely to stay under five thousand items is almost always the wrong call. You end up with queries that must union across lists, aggregate views that are harder to build than the original problem, and a structure whose logic nobody remembers in two years.
One well-indexed list of eighty thousand items is easier to live with than sixteen lists of five thousand.