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.
Please do not waste your time with sql server anymore, rework your backend!
Use a nosql database for metadata and skip the dusty database design.
The continual claim of supporting libraries of up to 30,000,000 items and then telling us "but we can only show 5,000 at a time" is quite simply ludicrous. Just today I've been told that the issue I have scrolling a large folder when it keeps refreshing and taking me back to a point higher up the list of content so making it impossible to scroll the entire folder (of less than 5,000 items) is actually caused because the library itself has more than 5,000 items in it. Things have got better of late with better indexing and the modern views but 5,000 is still simply too low of a limit to be useful and it certainly sometimes appears that Microsoft (perhaps support) are simply hiding behind that number and using as the excuse for everything that doesn't work as it should
Everyone should tweet @jeffteper about this. He is Corporate Vice President - Microsoft 365 with Teams, SharePoint, OneDrive, Viva, more.
kevin moore commented
a limit of 5000 is a joke when working with media files for a documentary this is never mention upfront when ordering the one drive for business - not good
Nick Saia commented
We've given you plenty of money over the years, can you just fix this one thing for us?
Due Date: Yesterday
Jared Pittman commented
This is continually the most frustrating thing for our end users regarding SharePoint Online. Our team doesn't have the bandwidth to train on spreading their content across multiple doc libraries - and quite frankly we shouldn't have to. Once a library gets too big we can't make changes to permissions, or even easily delete content.
I love the new UI improvements, but this is a HUGE core usage issue that should have been resolved years ago.
Mike Doman commented
ich benötige mehr als 5000 Elemente für die Listenansicht.
Jack Salsbury commented
Absolute joke this limit, please make unlimited or allow users to specify.
Ralph Boccalini commented
Is there any news about this?
Joe McGiven Corban commented
The last update from Microsoft (above) on this was in June 2018... over 2 years ago! The list threshold is still only 5,000 items, so cross older views ("show items inside folders") will still fail when there are more than 5,000 items in that library. Agree with the original author that this limit is "laughable"... and the fact it's now 5 years since this request, and nothing has happened "now makes me cry" - oh the emotions!
Kevin Still commented
Lookup columns fail for lists with over 5k, very annoying.
Can we get an honest update on this issue?!!
The other problem with Microsoft imposed limits on Lists is users cannot create List templates with content that exceeds a measly 52 MB. So not only are they having to skirt around this 5000 list record limit, but that have additional barriers to creating copies of content just to slim their records down.
We are experiencing issues relating to not having the ability to change permissions or rename folders due to this limitation
Warren Patterson commented
While you at it MS, sort out document libraries lookup fields support for more than 5000 items too. I mean come on, just lazy load the items, its not complex, hire me, I will come do it for you.
Can we have a status update?
Craig Brookhart commented
is there a status on this?
Mohammed Ahmed commented
Limit on files and folder count is a useless option as many user they will keep old data as an archive and in this case user can not share the entire archive.
Toujours aucune solution fonctionnelle depuis toutes ces années, c'est vraiment dommage d'être limité à 5000 items.
Nick Worthy commented
We're using a large list for monitoring Staff Covid status (5000+ staff) and running into performance issues as a result. We have views set up so that users do not load 5000 entries at any time, but there are still odd, intermittent performance problems which MS has ascribed to the size of the list. (see Premier Support ticket: 21802125)
We would strongly support the increase of the limit to e.g. 25k.
I can accept that in the SPOL environment targeting mobile clients to some extent, having a list threshold limit makes sense - for general work with large lists, indexes and filtered views can be used to make it work.
HOWEVER when a lookup field references a large list, you run into the limit and there is no way to work around the issue. Processes that we set up in SP2010 can't be migrated to SPOL!!!
There should be some way to differentiate "allowable values" (Comes from whole list) and Selectable values (Comes from a filtered view) or better filtered with user adjustable query or lookup.
This needs a fix.