Cloud Sync Keeps Breaking PST, Database or Lightroom Catalog Files? The Live File May Be the Wrong Thing to Sync

Short answer: if a file is continuously open, locked, rewritten, or updated in small bursts by an application, placing that live working file inside a normal cloud-sync folder can create exactly the problems people then blame on the provider: Processing changes, conflicted copies, delayed uploads, incomplete remote versions, or an application refusing to open the file elsewhere.

The key mistake is assuming that a file-sync engine understands the transaction state of the application that owns the file.

It usually does not.

A sync client sees filesystem events: a file changed, grew, was renamed, was replaced, was locked, or became readable again. A database engine sees something much richer: transactions, journals, locks, write-ahead logs, checkpoints, related sidecar files, and rules about when the data is internally consistent.

Those are different layers.

That is why the safer pattern is usually:

live working database stays where the application expects it → application creates or reaches a consistent checkpoint → closed snapshot/export/backup is copied to cloud storage → restore is tested separately.

First separate ordinary documents from application state

A Word document that is saved, closed, and then synchronized is a relatively simple object.

A live Outlook PST, browser profile, SQLite database, Lightroom Classic catalog, virtual-machine image, or application state directory can behave very differently.

These files often have one or more of the following characteristics:

• the application keeps them open for long periods;
• writes happen repeatedly while you work;
• one logical database consists of several related files;
• temporary journals or lock files appear and disappear;
• the application may rewrite large portions of the file after a small logical change;
• another computer should not open the same working database at the same time;
• a clean copy is only guaranteed at a defined checkpoint, close, export, or backup operation.

That last point is the one generic cloud-sync guides miss.

A sync client can successfully upload bytes and still capture the wrong consistency point for an application database.

Why "it uploaded" does not prove the database is safe

Imagine an application writes a database using three files:

catalog.db

catalog.db-wal

catalog.db-shm

The exact filenames vary by application and database engine, but the principle is common: the main file may not contain every committed change at every instant.

If the cloud client captures the main file before the sidecar state is checkpointed, or one file uploads while another is still changing, you can end up with a set of cloud objects that existed on disk at slightly different moments.

That does not mean the cloud provider corrupted the database.

It means ordinary filesystem synchronization is not automatically an application-consistent snapshot system.

The right diagnostic question is therefore not:

"Did the cloud app say Sync complete?"

It is:

"Was the application at a known consistent state when these files were captured?"

OneDrive: Microsoft itself tells you to move active Outlook PST files out

OneDrive is the clearest place to see this distinction because Microsoft documents both sides of the issue.

Microsoft currently says that if another application is using a file stored in OneDrive, the file cannot sync while it is open. Its examples explicitly include Outlook data files.

Microsoft also has a dedicated support article for removing an Outlook .pst data file from OneDrive. It says a large PST inside OneDrive can slow synchronization and can leave OneDrive stuck on messages such as Processing changes or A file is in use.

The recommended fix is not "reset OneDrive harder."

It is to:

1. close Outlook;
2. let OneDrive finish syncing;
3. copy the PST to a location outside OneDrive;
4. reconnect Outlook to the new local path;
5. only then remove the OneDrive copy if appropriate.

Microsoft's restrictions page adds another subtle point: PST files are technically supported by OneDrive, but they are synchronized less frequently than ordinary files to reduce network traffic.

That is a very different statement from "an actively used PST is a good live-sync workload."

For a working Outlook profile, Microsoft itself provides enough evidence to say the safer architecture is to keep the active PST outside the synchronized folder and use a deliberate export/backup workflow instead.

Dropbox: a locked file can block synchronization, and autosave can create conflicts

Dropbox's current troubleshooting documentation says some applications place restrictions on files while those files are open. When that happens, Dropbox may not be able to access or synchronize the file until the application releases it.

Dropbox also documents conflicted copies when:

• two users edit the same file at the same time;
• one person edits offline while another edits the cloud version;
• a file is left open and an application continues autosaving changes.

That makes live database-like files a bad place to assume "Dropbox will just merge it."

Dropbox does not understand the rows inside your SQLite database or the internal structure of your application catalog. If two versions diverge, the safe fallback can be preservation of both files rather than semantic merging.

For normal documents, that behavior protects edits.

For an application database, two whole-file copies can leave you with a much harder question: which database contains the authoritative application state?

That decision belongs to the application, not the sync engine.

Google Drive: synchronization keeps files aligned, but it is not an application-aware database snapshot

Google Drive for desktop is designed to keep files synchronized between the local filesystem and Google Drive. Google describes both Stream and Mirror as reflecting changes across devices.

What Google does not publicly promise is that arbitrary third-party database formats receive application-consistent transaction snapshots while they are actively being written.

That absence matters.

If you put a constantly changing SQLite file, mail database, browser profile, or VM image into a mirrored Google Drive folder, Drive can synchronize filesystem changes. That should not be upgraded into the stronger claim that it understands database journals, checkpoints, or crash-consistency requirements for every application.

Treat live application databases as unsupported architectural assumptions unless the application's own documentation says the workflow is safe.

For Google Drive, a better pattern is usually to synchronize:

• closed exports;
• application-created backups;
• compressed snapshots made after the app is closed;
• ordinary project assets that are not themselves a live database.

The difference is important because a cloud file being current is not the same thing as a database being internally consistent.

iCloud Drive: application guidance matters more than Finder visibility

Apple's public iCloud Drive documentation is strong on file synchronization and local/cloud availability, but it does not provide a universal guarantee that arbitrary live third-party databases are safe to keep inside iCloud Drive while those applications continually write to them.

So the application vendor's documentation becomes the higher-value source.

Adobe is unusually explicit here.

Adobe's current Lightroom Classic catalog FAQ describes the Lightroom catalog as a database and says it is recommended not to store the catalog in locations used by third-party online storage and syncing services, specifically mentioning services such as Microsoft OneDrive and Apple iCloud Drive in that warning context.

Adobe separately explains that Lightroom catalogs can become corrupt if access to the drive is interrupted while Lightroom is writing to the catalog, and recommends keeping the catalog on a local drive.

That means "Finder lets me put the .lrcat file in iCloud Drive" is not enough justification.

The application vendor says the catalog itself should not be treated as an ordinary always-synced working document.

A better Lightroom pattern

Keep the active catalog on a stable local drive.

Use Lightroom's own catalog backup feature to create consistent backups.

Then store those closed backup archives in cloud storage if you want an off-device copy.

Also remember Adobe's separate warning: backing up the Lightroom catalog does not back up the original photos referenced by the catalog. Your photo archive needs its own backup/storage design.

pCloud: its own documentation explicitly says not to sync PST/OST and constantly updated database files

pCloud is unusually direct about this class of workload.

Its current help documentation says files that are actively used or frequently updated can cause issues with Sync, Back up, or Upload. It specifically lists:

• .pst and .ost email data files;
• .git directories;
• browser data;
• email-client data;
• hidden/system files.

A broader pCloud file-management page additionally says to avoid database files that are constantly being updated and files that are locked or in use by other applications.

pCloud explains the failure mode as repeated modifications producing filename.conflicted copies during transfer.

That is important because it prevents a dishonest recommendation.

pCloud is not the service to choose because it somehow makes live databases safe to synchronize. pCloud itself tells you not to use these workloads this way.

The useful pCloud angle is different: it lets you separate the live application layer from the archive layer.

For example:

• active Lightroom catalog → local SSD;
• Lightroom catalog backup ZIP → pCloud Drive/archive;
• active Outlook PST → local path outside pCloud Sync;
• periodic closed PST export → pCloud archive;
• live SQLite database → application host/local storage;
• scheduled database dump → pCloud storage;
• current browser profile → local/application-managed;
• exported bookmarks/config backup → cloud archive.

That separation is much safer than treating every mutable application state file as if it were a Word document.

The dangerous category: files whose logical state spans multiple objects

Some applications maintain data across several related files.

Typical patterns include:

• main database + journal;
• main database + WAL + shared-memory file;
• catalog + catalog-data file;
• virtual-disk image + differencing disk;
• repository metadata + working tree;
• index + sidecar metadata;
• mail data + lock or index files.

If those pieces are not captured from one consistent point in time, restoring "all the files that happened to be in the folder" may not reconstruct the state you expected.

This is why a provider's version history is useful but not magical.

Version history can recover older file objects. It does not automatically know which version of File A belongs with which version of File B for your specific application transaction.

For application-consistent recovery you usually want one of these:

1. the application's own backup/export feature;
2. a database-native dump or snapshot;
3. a filesystem snapshot method documented as safe for that workload;
4. a closed application followed by a controlled copy of the complete state set.

"But it has worked for years" is not the same thing as a supported recovery design

Many risky sync workflows look perfect until the first time two events overlap.

A PST can sit in a sync folder for months and appear fine. Then one day Outlook is still writing while the cloud client sees a large change, the laptop sleeps, another device touches the file, or the sync client retries after reconnecting.

A Lightroom catalog can survive hundreds of ordinary closes. Then a machine crashes while the catalog and its sidecar state are changing.

A VM image can synchronize successfully every night until the user leaves the VM running during one of those transfers.

The absence of failure is weak evidence because the failure requires timing.

The right test is not "Has this broken yet?"

It is:

"Does the application vendor or cloud provider document this live-file pattern as safe?"

If the answer is no, redesign the capture point before the first recovery incident forces the issue.

Safe architecture: sync the snapshot, not the transaction stream

A robust pattern separates working state from portable recovery state.

Layer 1: live working state

Keep the database where the application expects stable local access.

Examples:

• Outlook PST outside the OneDrive/pCloud/Dropbox live sync path;
• Lightroom catalog on local SSD;
• SQLite database in the application's normal data directory;
• VM disk in the hypervisor's documented storage location.

Layer 2: consistent export or backup

Use the application's own backup/export feature, or close the application before copying the complete state.

Examples:

• Outlook export/archive PST after Outlook is closed;
• Lightroom's catalog backup ZIP;
• a database-native backup/dump supported by the application;
• shutdown VM followed by an image copy, unless the hypervisor provides a supported snapshot mechanism.

Layer 3: cloud archive

Upload the resulting closed, self-contained snapshot to cloud storage.

This is where Dropbox, Google Drive, OneDrive, iCloud Drive, or pCloud become ordinary file-storage systems again.

The object is no longer changing every second. That makes synchronization, versioning, and long-term retention much easier to reason about.

Do not confuse Sync, Backup and application-aware backup

This is one of the highest-value distinctions in the entire cloud-storage category.

Sync answers:

"Can another location converge toward the same file state?"

A generic folder backup answers:

"Can copies of this filesystem content be retained remotely?"

An application-aware backup answers:

"Can I capture a recoverable state that the application itself considers internally consistent?"

Those are three different guarantees.

If the application is a database, accounting system, mail store, catalog, or VM, the third question can be the one that determines whether the restore actually opens.

If you have not already separated these layers, read Cloud Backup vs Cloud Storage before treating a green sync checkmark as a recovery strategy.

A practical diagnostic when one file keeps saying "in use" or keeps creating conflicts

Use this order instead of resetting the entire cloud client.

1. Identify the owning application

Which process opens the file?

If it is Outlook, Lightroom, a database engine, browser, VM, or another stateful application, assume the file may have application-specific consistency requirements.

2. Close the application cleanly

Do not kill the process unless you have no safer option. Let it flush and close its own state.

3. Watch the cloud client again

If the file suddenly synchronizes after the application closes, you have strong evidence that file locking/high churn was the real issue.

4. Verify the remote copy

Check the provider's web interface or another trusted device after synchronization completes.

5. Do not immediately reopen the remote copy as a second live working database

That can recreate the exact multi-writer conflict you just diagnosed.

6. Check the application vendor's storage guidance

If the vendor says the catalog/database should remain local, follow that guidance and move the active file out of the sync path.

7. Replace the live-sync design with snapshots

Create a scheduled export, application backup, or closed copy and sync that instead.

Big Five: what the public documentation actually supports

The honest conclusion is not that one provider "wins databases."

The correct conclusion is that generic cloud file synchronization is the wrong abstraction for many live database workloads.

Where pCloud fits after you fix the architecture

If your actual requirement is to keep closed snapshots, exports, ZIP backups, media catalogs after backup, or historical database dumps for long-term access, pCloud becomes relevant again.

Its storage-first desktop model is useful because the archive does not need to become the same thing as the local active database.

A clean pattern is:

Application live data → local / application-supported storage

Scheduled consistent backup → export folder

pCloud Drive or Uploads → long-term cloud archive

pCloud Sync → only if you genuinely need a bidirectional local mirror of the closed backup folder

This is a narrower recommendation than "put your database in pCloud," and that is exactly why it is safer.

Choose the right fix by file type

Outlook PST / OST

Do not treat the active data file as a normal cloud document. Microsoft itself provides a workflow for moving active PST data out of OneDrive, and pCloud explicitly advises against PST/OST in Sync/Backup/Upload.

Lightroom Classic catalog

Adobe recommends not storing the active catalog in third-party synced locations such as OneDrive or iCloud Drive. Keep the catalog local and put Lightroom's own catalog backups into cloud storage.

SQLite or other embedded databases

Use the application's documented backup/export function or a database-native snapshot method. Do not assume copying the live main file captures every journal/WAL state correctly.

Browser profiles

Browser profiles are high-churn application state. pCloud explicitly lists browser data among content to avoid in live Sync/Backup/Upload. Use browser-native account sync or export the data you need rather than synchronizing the live profile directory as ordinary files.

Virtual-machine images

Treat the VM disk as application state. Shut down the VM or use a hypervisor-supported snapshot/backup path before copying the image. A multi-gigabyte .vhdx, .vmdk, or similar file being rewritten while a generic sync client uploads it is not a reliable recovery design unless the platform explicitly documents it.

What not to do

Do not delete the conflict copy before opening both versions

A conflicted copy can contain the only version with your most recent local changes.

Do not clear sync state while the application still owns unsynchronized data

Closing the application and protecting the local file is safer than resetting the cloud client first.

Do not assume version history makes multi-file databases consistent

A provider can retain Version 12 of File A and Version 9 of File B without knowing that your application needed A12 + B11 at the same transaction boundary.

Do not put the same live database on two computers and expect cloud sync to become collaborative editing

Whole-file synchronization is not record-level database replication.

Do not confuse "Backup" branding with application-aware backup

A folder-backup feature can still capture files at filesystem level. For critical databases, confirm whether the database/application vendor supports the backup method.

The decision rule

If a file is:

• open all day;
• constantly rewritten;
• protected by application locks;
• backed by journals or sidecars;
• unsafe for two computers to edit at once;
• or explicitly called out by the vendor as unsuitable for synced storage;

then stop asking which cloud provider will make the live file behave better.

The better question is:

What is the application's supported way to create a consistent recovery copy, and which cloud should store that copy afterwards?

Once you make that distinction, most of the mysterious Processing changes, file in use, conflict-copy and "worked for months, then broke" incidents stop being mysterious.

The cloud archive is still valuable.

It just should not be asked to impersonate a database replication engine.

Related technical reading

• Cloud Backup vs Cloud Storage — the core distinction between synchronized access and independent recovery.
• How pCloud Drive Cache Actually Works — useful when closed archive files are cloud-first but active access still consumes local working space.
• Cloud Storage vs External Hard Drive — decide whether application backups belong on local secondary storage, cloud storage, or both.

Reverse internal link suggestions for batch wiring

Only add these after the final target URL is confirmed to return 200 directly at 50/50 deployment:

1. From cloud-sync-conflicted-copy-duplicate-files — in the section explaining files that conflict repeatedly because applications keep them open.
2. From cloud-backup-folders-outside-sync-folder — where folder backup is distinguished from application-aware backup.
3. From cloud-sync-symbolic-links-symlinks-junctions — where application data directories are mentioned as poor candidates for filesystem hacks.
4. From can-cloud-storage-protect-against-ransomware — in the recovery-layer section explaining why clean historical files still need application-consistent restore points.

Indexing and URL integrity checks for publication

This draft must not enter the sitemap until all of the following are true:

• https://cloudscope.org/articles/cloud-sync-open-database-pst-lightroom-catalog/ resolves directly with HTTP 200;
• no alternate slug for this same intent is registered;
• the canonical points to that exact final 200 URL;
• no publication path depends on a 301/302 redirect;
• all three /assets/... images exist at their final production paths;
• every internal link used in the published article resolves directly and does not point to an unpublished batch draft;
• the article is registered exactly once in the build/content source.

Do not create a separate near-duplicate URL for OneDrive PST sync, Lightroom catalog cloud sync, or cloud database corruption unless a later article has a genuinely different primary search intent and passes a cannibalization review.

Image metadata

1. Hero

• Filename: cloud-sync-live-database-hero.svg
• ALT: Cloud sync diagram showing an application continuously writing to a live database while the sync client tries to capture changing file states
• Purpose: Explain why filesystem sync and application state operate on different timelines.
• Dimensions: 1200 × 760.

2. Filesystem vs consistent snapshot

• Filename: cloud-sync-filesystem-vs-consistent-snapshot.svg
• ALT: Comparison between ordinary filesystem synchronization and an application-consistent database snapshot
• Purpose: Show why a successful file upload does not prove transaction consistency.
• Dimensions: 1200 × 760.

3. Safe architecture

• Filename: cloud-sync-live-data-safe-architecture.svg
• ALT: Three-layer workflow separating live application data, consistent backup generation and cloud archive storage
• Purpose: Give readers a safer production architecture.
• Dimensions: 1200 × 760.

Sources and verification

Product and application behavior can change. Primary sources checked on 21 August 2026:

1. Microsoft Support — Troubleshoot OneDrive error: "This file can't be synced" — https://support.microsoft.com/en-US/onedrive/troubleshoot-onedrive-error-this-file-can-t-be-synced
2. Microsoft Support — How to remove an Outlook .pst data file from OneDrive — https://support.microsoft.com/en-US/onedrive/how-to-remove-an-outlook-pst-data-file-from-onedrive
3. Microsoft Support — Restrictions and limitations in OneDrive and SharePoint — https://support.microsoft.com/en-US/onedrive/restrictions-and-limitations-in-onedrive-and-sharepoint
4. Dropbox Help — Dropbox stopped syncing / files not syncing — https://help.dropbox.com/sync/files-not-syncing
5. Dropbox Help — What's a conflicted copy? — https://help.dropbox.com/organize/conflicted-copy
6. Google Drive Help — Stream & mirror files with Drive for desktop — https://support.google.com/drive/answer/13401938
7. Google Drive Help — Use Drive for desktop — https://support.google.com/drive/answer/10838124
8. Adobe — Lightroom Classic catalog FAQ — https://helpx.adobe.com/lightroom-classic/kb/catalog-faq-lightroom.html
9. Adobe — Troubleshoot corrupt catalog — https://helpx.adobe.com/lightroom-classic/desktop/technical-support/workflow-issues/catalog-issues/troubleshoot-corrupt-catalog.html
10. pCloud Help — Files Not Recommended for Sync, Back up, or Upload — https://help.pcloud.com/article/files-not-recommended-for-sync-backup-or-uploads
11. pCloud Help — Uploading, Downloading, and Organizing Files — https://help.pcloud.com/article/uploading-downloading-organizing