Skip to content

Contradictions with the List View Threshold (LVT)

Lately I’ve been talking a bit with customers wanting to have large libraries, far exceeding the List View Threshold. And as Microsoft shifts its focus to Share Point Online (Office 365) there seem to be some contradictions in their statements about the LVT, so will these consolidate in the next year or so? Right now:

  • Libraries can have up to 30 million items, y et the default LVT for libraries is 5000 items. [More …]
  • The administrator LVT setting (default 20,000) should be available to power users at off peak times. [More …]
  • Careful and sophisticated design of views, along with use of metadata navigation, allows comfortable use of libraries far exceeding the LVT.
  • In Office 365 functionality is reduced on a library if you have more than 5000 items, regardless of how carefully you design your Views.
    • Using a folder structure and ensuring n o folder has more than 5000 items helps (as long as you don’t have any Views that ignore the folders.
    • Document Sets are even better in that they count as 1 item regardless of how many items they hold.

So should we be paying more attention to keeping our Libraries light on content to “future proof” them? I’m not sure, but understanding the List View Threshold has certainly become more important.

A few notes on the List View Threshold

The major reason behind having a List View Threshold is performance. Executing a View on a large library uses a fair bit of resource, and multiple concurrent Views being executed against large libraries can slow SharePoint down for everyone, so a throttling mechanism makes sense. And even more sense in Office 365, a shared hosting environment.

Filtering results on a Library, as View does, is a search on database table, and when large number of users are searching on the same table performance can take a hit. In addition, SQL Server puts a temporary lock on a table when it is dealing with more than 10,000 rows.

Views that are designed around indexed columns work better as the indexes are filtered before you have to touch the main table, reducing the number of rows your View actually touches, and thus giving you more leeway on the 5000 record limit.

Incidentally, Search is optimised to return you the top results from millions, or billions (we hope), of items with effectively no limits on how many items it can return. So you can use search, rather than a View on a Library with a large number of records, with no ill effects. MacroView DMFs Search Site Tree feature utilizes that to allow granular searching (disclosure: I work for MacroView).

I guess only time will tell whether designing our libraries to better observe the LVT is useful future proofing or not.

[8 June: Links to Software Boundaries and Limits page added]

Leave a Comment





This site uses Akismet to reduce spam. Learn how your comment data is processed.