Worth a direct correction before the numbers themselves: “15 concurrent workflows per content database” doesn’t appear anywhere in Microsoft’s own current software boundaries documentation for SharePoint Server — the real, verified workflow constraint is a rate limit (activations per second per web server), not a fixed concurrency cap. This post keeps the genuinely accurate numbers from the usual version of this list and corrects the ones that aren’t, plus adds the one piece of context that changes how seriously to take the workflow numbers at all: the workflow platform itself is being phased out.
In this post: Storage limits that are still accurate · The list view lookup threshold, corrected · Service application limits · Permissions and groups · The real workflow limit, and why it matters less than it used to · On-premises vs. Online: the real difference · Related reading
Storage limits that are still accurate
Worth confirming directly rather than assuming these have drifted: Microsoft’s current SharePoint Server 2016/2019 boundaries documentation still recommends keeping a content database under 200GB for general usage, with up to 4TB supported when specific disk-subsystem performance requirements are met (0.25 IOPS per GB, tested up to 60 million items per database). This hasn’t loosened over time the way some other on-premises limits have — it’s still the current, actively maintained guidance, not a stale figure carried over from an older version.
- Site collection storage: no hard limit, but keeping individual collections under 100GB is still the practical recommendation for backup/restore times and page rendering performance.
- File upload size: 2GB by default, raisable via Central Administration or PowerShell (`Set-SPWebApplication -MaximumFileSize`) — worth testing at the higher setting before rolling it out broadly, since larger uploads increase timeout risk on constrained network paths regardless of the configured ceiling.
Microsoft’s own documented maximum for the list view lookup threshold is 12 joins per query — but the same page notes that exceeding eight joins is what actually blocks the operation. The practical number to design around is 8, not 12.
The list view lookup threshold, corrected
Worth stating precisely rather than as a single round number: the documented maximum is 12 join operations per query (lookup, person/group, or workflow-status columns each count as a join), but Microsoft’s own notes on that same limit specify that a query using more than 8 joins gets blocked for non-administrative users. The extra headroom above 8 exists specifically for the maximal view via the object model, not for a normal user-facing view — worth designing list views around 8 lookup-type columns as the real practical ceiling, not the larger number that shows up first when skimming the spec.
The list view threshold itself — 5,000 items — applies the same way on-premises as it does in SharePoint Online; it’s a query-scan limit, not a storage limit, and a list can hold millions of items as long as no single view needs to scan more than 5,000 to render.
Service application limits
| Service | Limit |
|---|---|
| Search: content sources per Search service application | 500 |
| Search: crawl databases per Search service application | 15 |
| Search: crawled properties | 500,000 per Search service application |
| Search: managed properties | 50,000 per Search service application |
| User Profile: distinct users/groups with access to one item | 1,000,000 (beyond this, the item stops being searchable for anyone but eDiscovery) |
Worth noting the last row specifically, since it’s a genuinely non-obvious failure mode: an item shared with more than a million distinct users or security groups doesn’t get slow to search — it stops appearing in search results entirely for everyone, surfacing only through an eDiscovery query. This is far more likely to occur through an oversized, inherited security group nested several layers deep than through anything resembling a million individual grants.
Permissions and groups
The 50,000 unique-permissions-per-list ceiling is the same practical figure that governs performance in SharePoint Online too — it’s a SQL Server row-and-join scaling constraint, not something specific to either hosting model, which is why this particular number is worth remembering regardless of which environment a given list actually lives in. Group-based permission assignment over direct individual grants remains the real, current mitigation on both platforms — one group membership change instead of N individual permission changes scales the same way in either environment.
The real workflow limit, and why it matters less than it used to
The verified, documented workflow constraint is a rate: a SharePoint web server can activate a maximum of 6 workflow instances per second, cumulative across the farm’s web servers (two servers scale to 12/second, three to 18, and so on). Other real, documented ceilings worth knowing: 1,000 published workflow definitions per web site, 1,799 total workflow associations per site (a Service Bus subscription limit), and 100 workflow associations per list before the status columns start degrading browser performance.
Worth weighing all of this against a bigger fact, though: the SharePoint 2013 workflow platform — the engine behind SharePoint Designer workflows, still the most common workflow type running in on-premises farms — is itself being retired by Microsoft, the same trajectory covered in this site’s Modern Script Editor content. Tuning around these limits is worth doing for what’s running today, but it’s not worth investing further in expanding SharePoint Designer/2013 workflow capacity long-term; Power Automate is the durable direction regardless of hosting model, including for on-premises data via the on-premises data gateway.
On-premises vs. Online: the real difference
Worth being precise about what actually changes between the two, since it’s a narrower list than it first appears: SharePoint Online’s file upload cap (250GB) and its complete absence of a content-database concept are genuine platform differences — storage there is abstracted away entirely rather than tuned by an administrator. The list view threshold, the lookup-join threshold, and the 50,000 unique-permissions ceiling are the same SQL-level constraints on both, because SharePoint Online runs on the same underlying data-tier architecture, just managed by Microsoft rather than by an on-premises administrator with direct SQL access.
Related reading
- How to Avoid List Throttling in SharePoint — the list view threshold and indexed-column mechanics in more depth.
- SharePoint Online Modern Script Editor and Its Consequences — the same classic-platform retirement trajectory covered from the customization angle.
Most of what actually constrains an on-premises SharePoint environment is the same SQL Server-driven math that constrains SharePoint Online — the real platform differences are narrower than a long side-by-side limits table usually suggests. Design around the practical 8-join lookup ceiling rather than the documented 12, and treat workflow-capacity tuning as a stopgap for what’s already running rather than a foundation worth building further on.
App Catalog Authentication Automation Backup Compliance Content Type CSS Flows Google Javascript Limitations List Metadata MFA Microsoft Node NodeJs O365 OneDrive Permissions PnP PnPJS Policy PowerApps Power Automate PowerAutomate PowerPlatform PowerShell React ReactJs Rest API Rest Endpoint Security Send an HTTP Request to SharePoint SharePoint SharePoint List SharePoint Modern SharePoint Online SPFX SPO Sync Tags Teams Termstore Versioning