iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Two instances of a self-hosted app can safely open the same SQLite database when they run on one machine and use a local database file. SQLite coordinates access, but it allows only one writer at a time. The more serious risk is putting that file on a network share and letting applications on different machines open it directly.
Can two app instances use one SQLite database?
Yes—if both processes access a local SQLite file on the same host. SQLite’s FAQ says, “Multiple processes can have the same database open at the same time,” while qualifying that only one process can make changes at any moment. SQLite’s FAQ describes this coordination for multiple applications or instances using one database file.
This means “two writers” does not mean two independent writes happen simultaneously. If both instances try to write, one may wait for the other or encounter a busy/locked result. Your application should handle that outcome rather than assume every write can proceed immediately.
What WAL mode changes—and what it does not
Write-ahead logging (WAL) can let readers continue while a writer is working, improving reader/writer coexistence. It does not allow multiple simultaneous writers: SQLite still serializes writes. See SQLite’s isolation documentation for the concurrency details.
#1 Best Overall
WAL is therefore useful when readers should not be blocked by a write, but it is not a fix for a workload that needs several independent writes at once.
Why a shared network drive changes the answer
A local file shared by processes on one host is different from a file on NFS, SMB, or another network filesystem that multiple hosts open directly. SQLite relies on filesystem locking, and WAL also relies on shared-memory coordination. Network filesystem behavior may not provide the assumptions SQLite needs, creating locking, correctness, or performance risks. SQLite advises against treating a network-mounted file as a shared multi-host database; see SQLite’s guidance on using SQLite over a network.
Rank #2
Containers do not automatically make a database remote. Multiple containers on the same Docker host using a local shared volume remain within the same host’s coordination domain. Litestream documents this local-volume, same-host pattern in its Docker guide. By contrast, containers on separate hosts mounting the same network share cross the boundary that makes direct file sharing risky.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsChoose a deployment pattern that matches your writers
| Pattern | What to expect | Practical guidance |
|---|---|---|
| Multiple processes or containers on one host, local volume | SQLite coordinates access through the same host; writes still take turns. | Reasonable for modest workloads. Set an appropriate busy timeout and handle contention. |
| Multiple machines directly opening one SQLite file over NFS or SMB | Network locking and WAL shared-memory assumptions may fail or perform poorly. | Avoid this for simultaneous writes. |
| Multiple application machines using a client/server database | The database server coordinates remote clients. | Consider this when multi-server operation or write-intensive demand is a genuine requirement. SQLite names PostgreSQL as an example, not the only option. |
| One host owns SQLite and an application service provides remote access | Clients communicate with the service; database file access stays local to its host. | Use this approach if you want to retain SQLite while centralizing database access. |
The choice depends on where the file lives, whether writes can queue, whether all processes share one host’s locking domain, and whether operational simplicity or multi-host scale matters more. SQLite’s appropriate-use guidance discusses when a client/server database may be a better fit; it does not establish a universal request-rate, database-size, or user-count threshold.
Rank #3
Reduce brief lock conflicts on a local deployment
A busy timeout gives a short-lived lock conflict time to clear before the operation returns an error. Litestream’s Docker integration guidance suggests PRAGMA busy_timeout = 5000 for its setup scenario. That is a source-specific example, not a universal optimal setting; choose a timeout appropriate to your application and still handle errors if contention lasts longer.
If you use Litestream to replicate a database from a Docker deployment, keep the application and Litestream containers on the same Docker host with local storage, and follow Litestream’s guidance that only one Litestream instance should replicate a database. Replication or backup storage is not a live shared database: copying or streaming a file to object storage does not make independent writers safe.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When to move beyond a shared SQLite file
Move to a client/server database when multiple machines need live concurrent reads and writes, or when serialized writes are a material bottleneck. PostgreSQL is one example SQLite names. Another option is to keep SQLite on one host and route remote application traffic through a service that owns database access. Neither choice is triggered simply by running a second process; the key distinction is whether writers can queue on one local database or need coordinated access across machines.
Recommended Free Tools
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
