Can I use SQLite on a network drive if only one person writes to it?

It is still risky because network file systems can corrupt data even with a single writer due to caching and delayed writes. A local disk is much safer.

Does WAL mode fix the network drive corruption problem?

No. WAL mode does not work over a network file system because it relies on shared memory, which is not available across a network. It can actually make corruption more likely.

How do I back up a SQLite database safely on a network drive?

Keep the live database on a local disk and use the .backup command or VACUUM INTO to create a consistent copy. Then store that copy on the network drive or cloud folder.

What should I do if my cloud synced SQLite file shows a sync conflict?

Do not delete the conflict copy right away. Compare the two files. The original may be intact, or you may need to recover data from both using a tool like sqlite.repair.

SQLite on a Network Drive or Cloud Folder: Why It Corrupts

Putting a SQLite file on a network drive or inside a cloud sync folder (Dropbox, OneDrive, Google Drive) is a fast track to corruption. SQLite depends on file locks to coordinate writers. Most network file systems (NFS, SMB/CIFS) implement those locks unreliably. The result is a broken file. Here is why that happens and what to do instead.

How SQLite Depends on File Locks

SQLite uses a strict file-locking protocol. Its job is to make sure only one writer touches the file at a time and that every reader sees a consistent state. On a local disk the operating system provides reliable byte-range locks. The OS controls all access, so the locks hold.

Move that file to a network share and the picture changes. Both NFS (common on Linux/Unix networks) and SMB/CIFS (used by Windows shares and many NAS boxes) translate locks across the wire. They can fail silently. A lock can report success without actually blocking another process. A lock can vanish mid-transaction. Two processes end up writing at once. The file corrupts.

SQLite's own documentation tells you not to open one file from multiple computers over a network file system. That is not a suggestion. It reflects the fundamental gap between what SQLite demands from a filesystem and what network filesystems actually deliver.

WAL Mode and Network Drives Do Not Mix

Write-Ahead Log mode speeds up reads and writes, but it breaks on a network drive. WAL requires all processes to run on the same host because it uses shared memory to keep the main file and the WAL file in step. Over a network, shared memory is absent. The two files drift apart.

Turn on WAL for a file stored on a network drive and you will see errors: "database disk image is malformed" or "unsupported file format". Corruption can strike even with a single writer. The network filesystem may cache writes and deliver them out of order, and WAL cannot cope with that.

SMB Shares

An SMB share (Windows file sharing) is the network filesystem most people try first. SMB locking has improved, but it still falls short of local-disk reliability. Concurrent writes from different machines over SMB corrupt databases routinely. Keep the file on a local disk. For multi-user access, switch to a client-server engine.

Cloud Sync Folders Dropbox, OneDrive, and Others

Cloud sync folders introduce a different class of trouble. Dropbox, OneDrive, Google Drive, and iCloud Drive synchronize files between your machine, a remote server, and other devices. The sync software does not understand SQLite's internal structure.

Sync Conflicts

Modify a SQLite file on two devices before the sync finishes and the cloud service creates a conflict copy ("database (conflicted copy).sqlite"). You are left with two divergent files. Neither may be complete. Worse, the sync can upload the main file and the -wal file at different moments. The copy on the server, or on another device, arrives inconsistent.

Corruption During Writes

Cloud sync folders corrupt files by copying them mid-write. The sync agent sees a changed file and starts uploading. If it captures a half-written page, the remote copy is broken. The local original might survive. The synced copy does not.

Do not keep a live SQLite file inside a cloud sync folder. Store it on a local disk. Back it up with VACUUM INTO or the .backup command to a location that syncs.

Common Symptoms of Corruption on Network Drives

Database disk image is malformed. The file header or a page has been damaged.
File is not a database. The first bytes of the file got overwritten, often by a partial write or a sync conflict.
Unexpected application crashes. The app hits a corrupted page and dies.
Missing or duplicate rows. Inconsistent writes leave transactions lost or applied twice.

Safer Setups for Multi-User Access

Keep the file on a local SSD on one machine. Have every client connect to that machine over the network using a client-server protocol. SQLite is not a network engine.

If you are stuck with a shared filesystem, follow these rules:

Put the file on a local SSD. Never on a network drive or cloud folder.
Run a single writer process. Concurrent writers from different machines destroy files even when the filesystem claims locking works.
Enable WAL mode only when every process lives on the same host.
Back up regularly with VACUUM INTO or the .backup command. Both create a consistent snapshot while the file is in use.
Send backups to a different drive or a sync folder. Never run the live file from that sync folder.

What to Do If the File is Already Corrupted

Stop using it immediately. Copy the damaged file before you try anything. Run the .recover command in the SQLite command-line tool; it extracts as much data as possible from a broken file. Online services like sqlite.repair can also pull data from a corrupted SQLite file.