Cloud Storage Has Space Left but Sync Is Crawling? Too Many Small Files May Be the Real Limit

Short answer: cloud storage capacity and cloud sync scalability are two different limits. A 2 TB account can be almost empty by bytes and still make a desktop sync client work extremely hard if it must track hundreds of thousands of files, folders, placeholders, permissions, timestamps and change records. Dropbox currently says desktop performance can decline after roughly 300,000 synced files and strongly recommends not exceeding 1 million files on one computer. Microsoft likewise recommends no more than 300,000 synced items for normal OneDrive performance, although Windows now has a public preview that can raise a sync instance to 1 million items on qualifying hardware. Google applies several item-count limits of its own, including 500,000 items in a Shared Drive and 500,000 items inside a My Drive folder. Apple and pCloud do not currently publish an equivalent consumer desktop-sync soft limit in the documentation reviewed for this article.

That means the wrong first question is:

How many terabytes do I still have?

The better question is:

How many filesystem objects is the client trying to enumerate, compare, watch, index and reconcile?

A million 4 KB files and four 1 GB files can use roughly the same amount of storage while creating radically different synchronization workloads.

Why file count can hurt before storage capacity does

A cloud sync engine does more than transfer bytes.

For every object it may need to track some combination of:

• path and filename;
• file or folder identity;
• size and timestamps;
• local-versus-cloud state;
• placeholder or offline state;
• permissions or sharing metadata;
• version/change information;
• rename and delete events;
• conflict state;
• whether the object is inside or outside the active sync scope.

The exact internal database and reconciliation algorithm differ by provider and are not fully public. But the operational consequence is visible in the vendors' own guidance: several of them publish limits based on item count rather than storage used.

This is why a 40 GB source-code archive containing 800,000 tiny build artifacts can be harder on a desktop sync engine than a 400 GB video archive containing 200 large files.

Bandwidth is only one dimension.

A useful capacity model is:

sync pressure ≈ object count × metadata/change work + bytes transferred + local filesystem overhead

That is a CloudScope diagnostic model, not a vendor formula. The providers do not publish a universal equation for sync cost.

Dropbox: 300,000 is a performance boundary, not an account storage cap

Dropbox currently makes an important distinction between how many files the account can store and how many files the desktop application should actively sync on one computer.

Dropbox says the account can contain as many files as its storage allocation permits. But its desktop documentation says performance may start to decline after around 300,000 files synced to a computer. Dropbox calls this a soft limit because hardware matters and some machines can handle more.

Its current team guidance goes further: users generally should not sync more than 300,000 files, including online-only files, and Dropbox strongly recommends not exceeding 1 million files on a single computer.

That last point matters because it kills a common assumption:

“If I make everything online-only, the item-count problem disappears.”

Not necessarily.

Online-only can reduce local disk consumption, but Dropbox still has to represent and manage those items in the synchronized namespace. File-count pressure and disk-capacity pressure are different problems.

Best Dropbox fix when the account is huge

If one computer does not need the whole namespace, Dropbox's selective sync is usually the more relevant tool than simply making every object online-only. Selective sync removes selected folders from that computer's Dropbox folder instead of keeping all of their placeholders in the active local namespace.

Do not randomly remove folders until you have verified that important local-only work has already reached dropbox.com. Selective sync is a scope-control tool, not a recovery mechanism.

If local disk capacity rather than item count is the problem, the broader architecture is covered in Cloud Storage vs External Hard Drive.

OneDrive: the ordinary recommendation is still 300,000 items — but Microsoft is testing 1 million

Microsoft's current OneDrive and SharePoint limits page recommends syncing no more than 300,000 total items for optimum performance. Microsoft explicitly warns that performance problems can occur beyond 300,000 items even if you are not syncing every one of those items locally.

That is unusually useful wording because it shows the problem is not simply “how many full file copies are on the SSD.”

Microsoft also says that when OneDrive has a very large number of files, the client may sit on Syncing or Processing changes for an extended period.

The important 2026 change: 1 million items is now a public preview, not the normal baseline

Microsoft currently offers a Windows public preview supporting up to 1,000,000 items per sync instance per device, but the requirements are substantial:

• Windows 11 or Windows Server 2022 under the preview requirements;
• latest OneDrive client with the appropriate Insider/public-preview configuration;
• at least 16 GB RAM, with 32 GB recommended;
• SSD required;
• modern CPU class specified by Microsoft.

Microsoft also notes that devices not meeting the preview requirements remain on the existing 300,000-item supported model.

So a planning document should not casually say “OneDrive supports one million files now.”

The accurate statement is:

300,000 remains the general performance recommendation; a qualifying Windows public preview can extend a sync instance to one million items.

That distinction will matter until Microsoft changes the general-availability documentation.

Google Drive: separate account limits, folder limits, Shared Drive limits and desktop behaviour

Google's limits are easy to misread because several completely different item ceilings coexist.

A user account can create far more than 500,000 items

Google Workspace's current storage-and-upload documentation says a user can have up to 500 million items created by that account at one time.

That is an account-level creation ceiling. It is not a recommendation that Drive for desktop should continuously manage 500 million visible filesystem entries.

A My Drive folder can contain up to 500,000 items

Google currently documents a maximum of 500,000 files, folders and shortcuts inside an individual My Drive folder. The limit does not apply to the top level of My Drive in the same way.

A Shared Drive has a strict 500,000-item cap

Google's current Shared Drive documentation also caps a Shared Drive at 500,000 items, counting files, folders, shortcuts and items in Trash.

Google explicitly says this is an item-count limit rather than a storage-use limit and recommends keeping Shared Drives well below the ceiling.

That means a team can hit the Shared Drive boundary while still having enormous storage capacity available.

Google itself recommends much smaller structures for large migrations

Google's large-migration guidance is even more revealing. To reduce errors and improve performance during and after a migration, Google recommends not letting a user create or own more than 500,000 files, folders or shortcuts in that migration design.

This is a best-practice recommendation, not the same thing as the 500-million account-level technical ceiling.

Drive for desktop can also hit operating-system resource pressure

Google's current advanced Drive for desktop guide warns that making a large number of files available offline at once can produce errors such as “too many open files” and recommends working in smaller batches.

This is a useful reminder: cloud-platform limits and local operating-system resource limits can collide before cloud quota does.

iCloud Drive: Apple does not publish a comparable numeric desktop item threshold in the current user docs we reviewed

Apple's current iCloud Drive documentation explains how files and folders sync across Macs and other devices, how Desktop & Documents can be included, and how Finder exposes states such as In iCloud, downloaded and waiting to upload.

What those current consumer-facing documents do not provide is a Dropbox-style “300,000 synced files” performance recommendation or a Microsoft-style item threshold for the desktop namespace.

That absence should not be converted into this claim:

“iCloud has no file-count limit.”

The documentation does not establish that.

It only means CloudScope could not verify a comparable published numeric sync threshold from Apple's current public user documentation used for this article.

For a very large iCloud Drive tree, diagnose the actual symptom instead:

• is Finder still reporting upload activity?
• are files waiting to upload?
• is local disk pressure interacting with downloaded items?
• is another cloud service also trying to manage Desktop/Documents?
• is the problem one giant directory tree or only a specific application folder?

Apple explicitly warns that other third-party apps or cloud services syncing the same Desktop/Documents folders can interfere with iCloud Drive. That can look like a scale problem while actually being a competing-sync problem.

pCloud: do not invent a desktop sync ceiling that pCloud does not publish

pCloud's current public help pages do not give a Dropbox-style “desktop sync slows after X items” number for ordinary pCloud Sync.

That means this article will not claim that pCloud can sync one million, five million or unlimited files on a desktop merely because the storage plan has enough capacity.

There are documented item-count limits in another pCloud feature: folder collaboration.

For Invite to Folder, pCloud currently documents these folder limits:

• Basic accounts: up to 25,000 subfolders or 150,000 files;
• Premium/Business accounts: up to 50,000 subfolders or 300,000 files.

Those are shared-folder collaboration limits, not a universal account-storage limit and not proof of a general desktop Sync ceiling.

Keeping those scopes separate matters. A technically honest comparison should never copy a collaboration limit into a desktop-sync table and pretend it means the same thing.

The pCloud advantage here is architectural scope, not an unverified “unlimited files” claim

pCloud documents two separate desktop roles:

• pCloud Drive — a virtual drive for cloud-first access;
• Sync — an explicit two-way mirrored relationship between selected local folders and pCloud.

That separation can help a user who has one enormous archive but only a much smaller active working set.

For example:

• 700,000 historical design assets can live in the cloud-first archive;
• 30,000 current project files can be the explicit local Sync set;
• completed projects can move out of the active Sync relationship after verification.

The useful part is not that pCloud publishes a superior million-file benchmark — it does not.

The useful part is that you can reason about which folders actually need a persistent two-way local mirror instead of making the entire archive one giant working sync set.

Dropbox selective sync, OneDrive scope controls and Google Stream can solve similar classes of problem, so this is not unique magic. The comparison is about how naturally the storage model matches your workflow.

If you want the architecture before the plan, How pCloud Drive Cache Actually Works explains the virtual-drive versus persistent-Sync distinction in more detail.

Why “lots of tiny files” is worse than the same number of bytes in large files

Suppose two archives are both 100 GB.

Archive A contains 100 video files of roughly 1 GB each.

Archive B contains 1,000,000 tiny source files, thumbnails, sidecars, metadata fragments and cache objects averaging roughly 100 KB.

Archive B forces the system to process vastly more filesystem identities and change events.

Even if raw transfer bandwidth were infinite, the sync engine still has to discover, compare and represent those items.

This is also why large developer dependency trees, package caches, build outputs, node-module-style directories, application caches and generated thumbnail trees are poor candidates for ordinary cloud sync. Many of those files are reproducible and do not belong in a durable synchronized archive in the first place.

The storage question becomes:

Which individual objects actually need independent cloud history, sharing and retrieval?

If the answer is “almost none of the generated ones,” reducing the item count is more effective than buying another terabyte.

Do not solve a file-count problem by blindly ZIPing live data

Packaging thousands of small, static files into a ZIP or TAR archive can be useful because it converts many filesystem objects into one cloud object.

But that optimization has a cost.

You lose easy per-file:

• version history;
• selective download;
• sharing;
• search/indexing;
• incremental sync;
• conflict visibility.

So archive containers make sense for cold, immutable or versioned bundles, not a live working tree you edit every hour.

A safe pattern is:

1. finish the project or snapshot;
2. verify the source is consistent;
3. create a dated archive container;
4. calculate a checksum if integrity matters;
5. upload the archive;
6. verify the remote copy;
7. keep an independent copy according to your backup policy.

Do not delete the source merely because the ZIP appeared in the cloud.

If the goal is resilience rather than convenient access, read Cloud Backup vs Cloud Storage before reorganizing the archive.

A practical diagnostic sequence when sync is “stuck” but quota is fine

Use this order before resetting the client.

1. Measure item count, not only folder size

On the local source, record:

• total files;
• total folders;
• total bytes;
• number of files in the largest single directory tree;
• number of currently active/sync-scoped items.

A 60 GB folder with 600,000 files is a very different incident from a 60 GB folder with six videos.

2. Determine whether the provider publishes a boundary you are near

Examples from current documentation:

• Dropbox desktop soft performance boundary around 300,000 synced files;
• OneDrive optimum-performance recommendation of 300,000 items;
• Google Shared Drive strict cap of 500,000 items;
• Google My Drive folder cap of 500,000 items;
• pCloud Invite-to-Folder count limits that apply to collaboration, not ordinary Sync.

Do not transfer one provider's number to another.

3. Separate account scale from local sync scope

The account may legitimately hold far more items than one laptop should actively synchronize.

Ask which folders this specific device actually needs.

4. Stop adding more objects while diagnosing

If a migration is still generating tens of thousands of new objects while you are trying to determine whether the client is caught up, your evidence is moving underneath you.

Pause the producer where operationally safe, or finish one controlled batch before the next.

5. Test a representative smaller scope

A small isolated folder can reveal whether the account, client and network still function normally.

If 5,000 representative files sync quickly while the 400,000-item tree remains stuck in metadata processing, that is useful evidence of scale pressure.

6. Reduce the active namespace before reinstalling

Provider-specific tools may include selective sync, choosing fewer folders, using Stream rather than Mirror, or separating cloud-first archive data from explicit mirrored folders.

A reinstall that reconnects the same oversized namespace can simply force the client to enumerate everything again.

7. Verify before deleting or restructuring

Before moving or removing large trees, confirm remote completeness and preserve any local-only changes.

A “Processing changes” screen is exactly the wrong moment to assume every current file already exists in the cloud.

Big 5 comparison: item count is not one universal number

The table is deliberately asymmetric because the vendors publish different kinds of limits. Making every cell look equally neat would require inventing data.

When splitting the archive is smarter than switching providers

Changing cloud provider is expensive when the real problem is one pathological namespace.

Stay with the current provider and restructure if:

• most of the pain comes from one generated/cache directory;
• the service already fits collaboration and sharing needs;
• reducing local scope fixes client performance;
• a Shared Drive can be divided cleanly by team/project;
• the archive can be separated from active work without breaking workflows.

Consider another storage model when:

• the account is mostly cold archive but the current client continually treats it like an active working set;
• the storage layout forces too many objects into every endpoint's sync namespace;
• local SSD pressure and object-count pressure repeatedly return together;
• you no longer need the office/collaboration ecosystem attached to most of the archive.

If the issue is specifically that Google has become an archive rather than a collaboration tool, Google Drive Alternatives is the broader provider-level decision framework.

The architecture that scales better than “sync everything everywhere”

For very large collections, a useful design separates data by activity, not just by subject.

Tier 1 — active working set

Frequently edited files that need low-latency local access and true bidirectional synchronization.

Keep this set intentionally small enough that the desktop client remains observable and recoverable.

Tier 2 — warm reference library

Files browsed regularly but edited infrequently.

Cloud-on-demand or selective local availability usually fits better than a permanent full mirror.

Tier 3 — cold archive

Completed projects, immutable exports, historic datasets and infrequently accessed media.

These may benefit from cloud-first storage, archive containers for static tiny-file trees, and an independent backup copy.

The purpose of the tiers is not to force a specific vendor. It is to stop one laptop from acting as if every file the organization has ever created is part of today's active working set.

What not to do

Do not buy more TB before checking object count

Capacity upgrades do not fix a desktop engine that is spending its time reconciling hundreds of thousands of filesystem entries.

Do not assume online-only eliminates metadata cost

Dropbox explicitly includes online-only files in its team guidance around the 300,000-file desktop performance recommendation. OneDrive also warns that performance issues can occur over 300,000 items even when you are not synchronizing all of them.

Do not call every published number a hard account limit

Dropbox's 300,000 is a soft desktop performance boundary. OneDrive's 300,000 is an optimum-performance recommendation. Google's 500,000 Shared Drive cap is a hard structural limit. pCloud's 300,000-file figure applies to Premium/Business shared folders, not all storage.

Those are different classes of number.

Do not reset the client while local-only changes are uncertain

An oversized reconciliation job can take time. Protect unsynced work before unlinking, reinstalling or deleting local state.

Do not build a million-file design around a preview feature without accepting preview constraints

Microsoft's one-million-item OneDrive support is currently a Windows public preview with hardware and configuration requirements. Treat it as a deliberate deployment choice, not a universal default.

The final decision is not “Which cloud has the biggest number?”

A provider that publishes a larger item ceiling is not automatically the better storage system.

The right decision depends on what those objects are doing.

If 600,000 files are active project data that multiple people edit every day, you need a collaboration and sync architecture designed for that workload.

If 550,000 of those files are five-year-old static assets that nobody edits, forcing every endpoint to keep them in the active sync namespace is usually self-inflicted complexity.

Most people who reach this problem think they need more capacity because the folder is “large.”

The unresolved question is actually more specific:

How many of these objects still need to behave like live synchronized files?

Until you answer that, changing plans only changes the size of the bucket. It does not reduce the amount of state your sync engine must manage.

Related technical reading

• How pCloud Drive Cache Actually Works — understand cloud-first visibility versus a persistent local Sync copy.
• Cloud Storage vs External Hard Drive — decide whether part of the archive should remain local, cloud-first, or both.
• Cloud Backup vs Cloud Storage — do not remove independent recovery just because you reduced the active sync set.
• Google Drive Alternatives — useful when Google Drive has become mainly an archive rather than a collaboration environment.
• Secure File Sharing Controls — if splitting the archive changes how external users receive files, rebuild sharing controls deliberately.

Reverse internal link suggestions for batch QA

Only add these after the target draft and this article both return direct 200 responses on their final canonical URLs:

1. Draft 30, the filename/path restriction article — add this page where very large trees amplify path and naming failures.
2. Draft 31, the conflicted-copy article — add this page where large active namespaces increase reconciliation complexity.
3. Draft 33, the live database/PST article — add this page where high-churn generated files inflate the item set unnecessarily.

Do not create those links during draft accumulation. This batch deliberately waits until final routing is verified to avoid indexing links that could become 404s.

Image metadata

1. Capacity vs item-count hero

• Filename: cloud-sync-file-count-vs-capacity-hero.svg
• ALT: Cloud storage diagram showing a small total data size made of hundreds of thousands of files overwhelming sync metadata work despite plenty of storage capacity
• Purpose: Explain why bytes and objects are separate scaling dimensions.
• Dimensions: 1200 × 760.
• Source: Original CloudScope technical diagram based on published provider item-count guidance.

2. Too-many-files diagnostic tree

• Filename: cloud-sync-too-many-files-diagnostic-tree.svg
• ALT: Diagnostic tree separating cloud quota, item-count limits, local sync scope and operating-system resource pressure when cloud sync is slow
• Purpose: Guide safe troubleshooting before reinstalling or deleting data.
• Dimensions: 1200 × 760.
• Source: Original CloudScope diagnostic diagram.

3. Tiered file-count architecture

• Filename: cloud-file-count-tiered-architecture.svg
• ALT: Three-tier cloud storage architecture separating active synced files, warm on-demand reference data and cold archive content
• Purpose: Show how reducing the active sync namespace can improve operational scalability without deleting the archive.
• Dimensions: 1200 × 760.
• Source: Original CloudScope architecture diagram.

Sources and verification

Product limits change. These primary sources were checked on 21 August 2026:

1. Dropbox Help — How many files can I store in my Dropbox account?

https://help.dropbox.com/storage-space/file-storage-limit

1. Dropbox Help — Restrictions and limitations for teams

https://help.dropbox.com/plans/large-deployments

1. Microsoft Support — Restrictions and limitations in OneDrive and SharePoint

https://support.microsoft.com/en-us/onedrive/restrictions-and-limitations-in-onedrive-and-sharepoint

1. Google Workspace Learning Center — Shared drive limits in Google Drive

https://support.google.com/a/users/answer/7338880

1. Google Workspace Admin Help — Storage and upload limits for Google Workspace

https://support.google.com/a/answer/172541

1. Google Workspace Admin Help — Google Drive large migration best practices

https://support.google.com/a/answer/10445916

1. Google Drive Help — Manage Google Drive for desktop: Advanced guide

https://support.google.com/drive/answer/16631477

1. Apple Support — Store files in iCloud Drive on Mac

https://support.apple.com/guide/mac-help/mchle5a61431/mac

1. Apple Support — Work with folders and files in iCloud Drive

https://support.apple.com/guide/mac-help/mchl1a02d711/mac

1. pCloud Help — Managing Shares and Access Control

https://help.pcloud.com/article/managing-shares

1. pCloud Help — pCloud Drive vs (pCloud) Sync

https://help.pcloud.com/article/pcloud-drive-vs-pcloud-sync

Publication/index QA gate

Before this draft can be wired into production:

• final slug must be registered exactly once;
• final article URL must return 200 directly, not 301/302;
• canonical must equal the final 200 URL exactly;
• no alternate slug or duplicate article may expose the same intent;
• all production /assets/ paths must return 200 before the page enters sitemap;
• only verified 200 internal links may remain clickable;
• batch reverse links must be added only after both source and target URLs exist;
• sitemap must include only the final canonical URL, never a draft, alias or redirecting version.