Limits and Performance: Large Boards, Long Threads and the List View Threshold

Overview

Discussions keeps every board of a site in a handful of ordinary SharePoint lists, so the limits that apply are the limits of SharePoint Online lists plus a few fixed values built into the web part. This article lists those values as implemented in version 26.11.4, explains the effects of paging, indexes and the list view threshold, and gives recommendations for sites with very large boards or very long threads. The lists and columns themselves are described in KB10426. Discussions Lists and Columns Reference.

The limits at a glance

How the topic list stays fast

Each request returns at most the configured number of topics, sorted by the pinned flag and then by last activity, newest first. Load more uses the continuation link returned by SharePoint. Paging limits the response size; it does not guarantee constant server work or avoid the list view threshold.

Several filters and sort columns are indexed, but not every condition is. In particular, the accepted-answer column used by the answered views has no index:

Title search adds a contains condition. Neither a small page size nor fewer than 5,000 topics on one board guarantees a successful query: all boards on the site share the topics list, and the board filter uses a lookup. Microsoft states that an indexed lookup column does not prevent list view threshold errors. Test the actual queries with representative data; use site search if a query is refused. See Microsoft: Add an index to a list or library column.

Long threads

When a topic is opened, the web part loads all of its replies, not just the first page. Replies are read from the Discussions Posts list in batches of 500 through the indexed VtxTopic lookup, and the reply tree is then built in the browser from the parent and path columns. There is no configurable maximum depth, but the parent path column is limited to 255 characters, so arbitrary nesting is not guaranteed. There is no separate “show more replies” step.

The practical consequences:

• Assuming full batches of 500 visible replies and successful queries: a thread with 2,000 replies needs four requests before it is shown; a thread with 10,000 replies needs twenty. The page becomes noticeably heavier, because every reply is rendered at once.
• Deeply nested replies are indented level by level. On narrow screens, very deep branches become hard to read; moderators can lock a topic that has run its course and ask for a new one.
• The Replies counter in the list is a stored number on the topic, not a live count (see KB10432. Counters, Last Activity or Best Answer Look Wrong).

Images and attachments

Inline images pasted, dropped or inserted with the Insert image button are uploaded to the Discussions Assets document library. The web part creates a folder per calendar year (for example 2026) and stores every image there under a unique name. Year folders organise the files; a busy year can still exceed the list view threshold. Images larger than 10 MB are rejected before the upload starts; files that are not images are ignored by the editor.

Attachments added with Attach file are ordinary list item attachments on the topic or reply. The web part puts no limit on their number or size; the limits of SharePoint Online for list item attachments apply. File names are made safe for SharePoint before the upload: the characters \ / : * ? " < > | # % & { } ~ are replaced by an underscore and names longer than 120 characters are shortened.

Moderation queue, Activity web part and subscriptions

• The Moderation screen requests up to 200 newest items in each of six sections: pending, rejected and reported topics and replies. Reply queries first select items across the whole site and only then filter them to the current board. Other boards can occupy that 200-item window, hiding older replies from the current board. The queue is not a complete audit: inspect the underlying lists for a large backlog.
• Discussions Activity requests the number of topics configured in Maximum items (1–50), filtered by approval and sorted by last activity. This limits the response size but does not guarantee that a large-list query succeeds.
• Subscriptions are read per user and board, up to 500 rows; subscriptions beyond that window are not returned by this query.

Counters and versioning

Reply counts, view counts, last activity and the like are stored on the topic item and updated by the browser of the user who replies or opens the topic. Each such update creates a new version of the topic item, because the lists are created with versioning enabled. On a very active board, the version history of a popular topic grows quickly; a site owner can lower the number of versions kept in List settings → Versioning settings of Discussions Topics without affecting the web part.

Recommendations for very large boards

1. Plan shared lists. Boards on one site share the same lists; splitting one board into several does not reduce the total list size or create separate access boundaries. Separate sites provide separate lists when that fits your organisation.
2. Test realistic volumes. Check search and each view with representative data. A board below 5,000 topics is not a guarantee; if a query is refused, use site search and review the list design.
3. Use categories to organise related topics. The category column is indexed, but filtering still has a processing cost.
4. Lock finished threads and start new ones instead of letting a single topic collect thousands of replies.
5. Page size. Start with 20 topics per page. Increasing it to 100 returns and renders more data per request and can make the initial load heavier.
6. Imports. The importer reads batches of 2,000 and writes items individually. Test permissions and a representative source before a large import, allow time, and review warnings and interrupted runs. KB10417. How to Import a Classic SharePoint Discussion Board into Discussions.