Remove the list view threshold (5000 by default)
This limit has always been a bit laughable, and is even more so as we develop more client side applications. In SharePoint 2007 we didn't have this limit and were allowed to make our own mistakes. Now that hardware is so much more powerful, we need this limit removed so that we can build enterprise-class applications.
We are continuing to make our large list experiences better, please keep the feedback coming.
Spring 2018 update:
- We now support being able to manually add indexes to lists of any size (increased from lists up to 20,000 items previously).
- Starting with the February release of the Office 365 Excel client, you will be able to export your full list instead of getting cut off part of the way through.
What we are working on now:
- Predictive indexing will start to work for lists larger than 20,000 items so your views will automatically cause the right indexes to be added to your lists.
In our backlog:
- Being able to index/sort/filter by lookup column types (like person, lookup or managed metadata columns) without being throttled.
- Making sure that our REST APIs support querying in ways that will guarantee that the call will not be throttled.
For a general update on large list capabiltiies, the video on myignite.microsoft.com/videos/53861 (focusing on large lists at 42 minutes and 25 seconds) describes some of the changes that we delivered back in the second half of 2017:
- Modern UI now has a lot of support for adding indexes to large lists and libraries on the fly, reducing the number of throttling errors experienced by our users, and some new UI for browsing through items in large lists with our paging model
- SharePoint runs predictive indexing jobs to automatically add indexes as lists get larger based on your view definitions, and updates these indexes when you add/update your views
Looking forward to receiving more of your feedback.
What is happening to this? This problem needs an urgent resolution. Almost every SP site we have will exceed 5000 files. It is severely impacting our ability to use SP at the enterprise level.
Marco Garibay commented
One year since the last update and nothing yet?
Speaking for our team, we just want to use sharepoint as a file repository and so far it's been a nightmare.
I'd like to see a sharepoint container that behaves exactly like a onedrive, with zero limit of file size transfer.
This is important as we use onedrive to store video files which go above 5GB
Please remove this block.
Please increase the number. It is urgent!
Please fix this Microsoft.
PLEASE PLEASE PLEASEEEE Microsoft do your thing to improve this! Looking at the number threads and complaints this is already long overdue.
I literally had to delete a whole document library because LVT wouldn't let me break permission inheritance for that library. The trick was to view that library in File Explorer and delete everything from there.
Then I have to migrate the library again which means extra down time for the users.
This is so frustrating. Even a work around where it only displays the first 5000 results will be better than displaying nothing at all.
agree with the comment that there has been no response in a year on this topic of the 5000 limit. Please update us.
Can we please have an update on this. It is a year on now from the 'Working On It' reply.
I would like to see a Sorting function added that allows you to easily select a way to filter your Sharepoint by the last X amount of Days or years. Right now there is a 'Created' field, but it is not easy to apply a date filter there that goes back a certain amount of time since it seems these fields have to be a static number. I see this as being valuable to a lot of different admins.
Sven W. commented
any update on the issue not being able to filter on Managed Metadata columns in large lists although they are indexed?
Jeff Joubert commented
Since we had a Spring 2018 update, could we get a Spring 2019 update?
Drew Kipfer commented
Thank you for all the effort you've put into improving the list experience thus far. Any further updates on when we can expect the 5,000 item query limit to be lifted?
Tom Burke commented
It seems like this isn't really an increase of the LVT, but indexing to try to work around it.
"Making sure that our REST APIs support querying in ways that will guarantee that the call will not be throttled." - This is possibly the most important point. We use K2 and are finding throttling issues with the API calls to SP lists. Not fun.
There are many cases reported in the web that users have added indexes to their lists, but when their lists reached the 5,000 threshold, end users received threshold limits erros. and when they checked with Microsoft about this issue, then got a reply that Microsoft cannot support indexes as they contain user data, and if items have been added/removed inside the list then the index can get corrupted.. So my question, is how we can verity if our indexes inside the lists are valid ? In other words if i have a list which contain 500 items and i added the indexes to it, then how i can verify if the current indexes are valid or not?
second point, there are incidents as in this link https://social.msdn.microsoft.com/Forums/office/en-US/600ab306-8aba-461c-92cf-10ea18dad288/list-view-which-is-filtering-items-based-on-an-indexed-column-and-which-will-return-2950-items?forum=sharepointdevelopment#7b1e37f2-fa2f-4ca0-8cd6-253dbacb1b7b where indexed on CreatedBy does not work,, so is Microsoft planning to fix these issues?
I noticed that there are several folks here that mentioned they have been able to add indexes to list even over the 5000 item threshold. I however get the "cant be done because over the limit" messaging. What I am missing and why cant this be completed?
SharePoint Online will never be an enterprise level Document Management Solution with these kind of ridiculous limitations. Latest one is if you have 5k+ documents and these documents have metadata field that is a lookup and you try to filter the documents by one of the items from the lookup, and the documents that have been tagged with the lookup value are very old, you wont see that lookup item in the filter. I can go on with whats wrong with Modern libraries and metadata data on SharePoint Online. To top it all off, because its a lookup, you can even do a "starts with search". A workaround is to have a background process that copies the value of the tagged item into a singlelinetext field and filter by that field. Its ridiculous because you have to have a background process that updates the singlelinetext field if the lookup value is changed/renamed. I might open a separate uservoice for the filter issue.
Good to see the changes here but it's still a nightmare working with larger lists. The task list is a perfect example.
So from extensive testing I can assure the following operations will cause a 5000 error response:
- Filtering on Lookup
- Filtering on User
- Filtering on Date
- Filtering using neq operation on ANY indexed field!
And there's more I'm missing from here. Regardless of the order of operations and the fact that you know one of the filter operations will return < 5000 items.
It's crazy that our code has to do operations explicitly stating batches of 5000 items in searches only using indexed columns.
The sooner Lookup filtering/indexing works the better the large list interaction gets.
Lisa J commented
PowerApps is basically unusable with large lists - I have a searchable drop-down, but supplying search criterion that will yield a result set under 5,000 items STILL throws an error.