SharePoint list limits cheat sheet

Download this page as a PDF

Most people meet these limits from the SharePoint side. A view that worked last spring now shows the list view threshold message, or a Power Automate flow starts failing with 429 errors every month end. The table names the Microsoft page behind each limit, and the sections after it cover what each one does to a sync job and how SPSync reads within it. Every Microsoft figure here was checked against Microsoft’s own pages on 22 October 2026, and the three Microsoft Support articles again on 23 October 2026.

The limits at a glance

Microsoft Lists limitations and maximum rows

Microsoft Lists is the app; the lists in it are SharePoint lists. Microsoft’s guide to SharePoint lists in Power Apps says you can always find a list in both Microsoft Lists and SharePoint. So the Microsoft Lists row limit, item limit and 5,000 limit are the SharePoint figures on this page, and the lookup cap in Lists is the same 12 joins per query.

The maximum number of rows in a Microsoft list is 30 million items. The 5,000 figure you see in the Lists app is a threshold on what one view can scan, which is why a list can hold far more than 5,000 rows and a view on it can still fail. Microsoft Lists to SQL Server covers where a Lists list is saved, a team site or My lists, and the routes into a SQL table.

What is the SharePoint list row limit?

A SharePoint Online list can hold up to 30 million items. That is the only row limit on the list itself. The same Microsoft page adds a smaller one that catches people out: once a list holds more than 100,000 items, you can no longer break permission inheritance on the list as a whole, only on individual items.

Long before either figure, a large list slows down, and the number that decides whether a view or a filter works is the 5,000-item list view threshold.

The 5,000-item list view threshold

The threshold applies to a single query, so a list can hold far more than 5,000 items and still work. The trouble starts when a view or a filter touches an unindexed column and SharePoint would have to scan past 5,000 rows to answer. Because the real number varies with load, a view that passed last week can fail on a busy afternoon.

For a sync job the threshold matters because of $filter. Filtering list items through Graph works only on an indexed column, one at a time. SPSync never filters list items. It reads every list through Graph delta queries, 200 items to a page, and you filter in SQL afterwards. Our run on the development tenant read 10,303 items across four lists, one of them well past the threshold, in 115 Graph calls.

Can you increase the list view threshold in SharePoint Online?

No. Microsoft’s support article List View Threshold for large lists and libraries says that for SharePoint the list view threshold can’t be changed. It is there so that every tenant on the shared service gets steady query performance. The Learn troubleshooting page gives the value as 5,000 items by default and sends you to that article for workarounds.

The forum answers that say you can raise it are about SharePoint Server, where the threshold is a setting a farm administrator can change (software boundaries and limits). In SharePoint Online the workarounds all keep one query under the threshold, mainly by indexing the column a view filters on and filtering on it first. When a report needs the whole list in one query, the threshold has to be avoided altogether, which is what a database copy does. Our post on what breaks past 5,000 items covers the error wording, the export and Power BI cases and the index-first fixes, and the 5,000-item threshold use case covers the copy.

The 12 lookup column threshold, and why Created By counts

Every lookup, person or workflow status column in a view counts as a join, and a SharePoint Online query can make at most 12 join operations. Past 12 the query is blocked, which is why wide project lists with many people columns break in classic views and in Power Query.

Created By and Modified By are person columns, and Microsoft’s support article on list forms with many lookup columns counts person and group columns as lookups. A view that shows both of them alongside ten lookup columns is already at 12. Copilot Studio applies the same cap: it does not support a list with more than 12 lookup columns in its default view.

The post on the lookup column threshold quotes the error each of views, Power Automate, Power Apps and Power BI shows past 12, with the fix for each. SPSync asks for single person columns by id only, which keeps its own requests further from the cap. In the database a lookup becomes {col}_id and {col}_value and a person becomes a user id in sp_users, so a report can join as many as it needs.

Is it 2,000, 5,000, 2,048 or 20,000 rows?

All four numbers get quoted as “the SharePoint list limit”. Each one belongs to a different Microsoft product, and none of them caps the list itself.

The 2,000 rows in older answers is the Power Apps data row limit. Learn now says the setting runs from 1 to 10,000 rows, with 500 rows as the default, so 2,000 is no longer the ceiling. Whatever the setting, a formula Power Apps cannot delegate to SharePoint only sees that many rows, and a match past the last one is not returned. Our post on Power Apps past the data row limit lists which formulas SharePoint delegates and when an app should read from SQL instead.

Copilot Studio can use a list as knowledge, but its list queries only return data from the first 2,048 rows. Agent Builder takes one list per agent, up to 20,000 items and 50 MB of text, and truncates a larger list, saying so in its answer. Each is a cap on how much of the list one tool reads at a time. A copy in a database has none of them, which is the route on the Power Apps performance and Copilot Studio grounding pages. For an agent that finds some items and says others do not exist, the post on the item at row 3,000 has a test that shows where the 2,048-row line falls on your own list.

Column counts and indexed columns

SharePoint Online caps columns by their combined storage size, so the ceiling depends on the column types you use. Indexes are scarcer. Microsoft’s support article Add an index to a list or library column allows indexes on up to 20 columns, and on a busy list they go quickly. In SharePoint Online you can add an index to a list of any size, so a list that is already past 5,000 items can still be indexed on the column its views filter on.

Discovery follows Graph’s paging past its default of 200 columns a page, so a wide list comes across whole. Before creating any table, SPSync checks the result against the destination’s own ceiling (1,024 columns on SQL Server, 1,600 columns on PostgreSQL) and stops with a message naming the table if a list would not fit. In the database you can index any column your queries filter on.

Throttling, 429 and 503

SharePoint Online meters each app per tenant in resource units. The smallest licence tier gets 1,250 resource units a minute, and a delegated user has a cap of 3,000 requests per five minutes across every app they use. When an app goes over, SharePoint answers 429 or 503 with a Retry-After header. Throttled calls still count against the quota, so retrying early makes things worse.

SPSync sends every call through one client. It waits out the full Retry-After, backs off with jitter from two seconds up to a five-minute cap when the header is missing, and gives up on a request after ten attempts. The x-ms-resource-unit header on each response feeds a meter that slows the client at 80 percent of the minute’s budget. By default the client runs four requests at a time per tenant. Three 429s in a row pause the whole tenant for the longest wait seen, and the run shows as throttled.

Delta tokens and 410 Gone

A delta query hands back a deltaLink that asks for everything changed since the last call. Microsoft publishes no fixed lifetime for SharePoint list item tokens. What you see instead is HTTP 410 Gone with a Location header, which means the client has to read the list again from the start.

SPSync stores each deltaLink as Graph returned it and never edits it. On a 410 it follows the Location header, reads that list again and merges the result into the existing table, so a replayed item updates its row and never duplicates it. A reconcile, weekly by default, compares the replica with the list as a quality check and a recovery path.

The throttling article works through the resource-unit arithmetic, and the schema reference has the full column mapping.