SQLite built its reputation as the database that does not need a database server. An application opens a file, runs SQL and relies on a compact, mature engine with almost no operational surface area. That simplicity now looks especially attractive to developers building small web services, platform tools and applications running close to users at the edge.
But a database file attached to one process also creates an obvious question: what happens when the server fails, traffic must move to another region or several machines need access to the same data?
Philip O’Toole, creator of rqlite, used the project’s 12-year retrospective, published on October 24, 2026, to examine how the idea of distributed SQLite developed from an experiment into a production architecture. The retrospective is a timely reminder that “distributed SQLite” is not one technology. It can mean a consensus cluster, remotely recoverable backups, read replicas, managed regional placement or a service-specific distributed-write system.
The differences matter. rqlite, Litestream and Turso all build around SQLite or SQLite-compatible technology, but they are not interchangeable. Choosing correctly starts with identifying whether the application needs recovery, automatic failover, geographically local reads or genuinely coordinated writes.
Why developers want SQLite beyond one server
SQLite’s appeal extends well beyond hobby projects. It offers transactional SQL, a portable file format, a small deployment footprint and remarkably low administration overhead. There is no separate server to provision, connection pool to tune or network dependency for local queries.
Those characteristics align with several modern development patterns:
- Small web applications: Many services have modest data volumes and write rates, making a large client-server database cluster unnecessary.
- Edge deployments: A local SQLite edge database can answer reads without crossing a continent, improving latency and resilience.
- Single-tenant databases: Giving each customer or workload a separate file can simplify isolation, movement and backup.
- Developer tooling and agents: Applications distributed to customer machines benefit from an embedded database requiring no administrator.
- Portable infrastructure: A database represented by a file is easy to copy, inspect and run in development.
The complication is concurrency. Traditional SQLite permits many simultaneous readers but serializes writes. Write-ahead logging improves reader-and-writer coexistence, yet it does not turn a local file into an unlimited horizontal-write system. Any distributed SQLite database must add coordination, replication or recovery mechanisms around that fundamental behavior—or implement service-level capabilities that go beyond a standard SQLite file.
Distributed SQLite, replication and backup are not synonyms
Before comparing products, separate four requirements that are often bundled together.
- Backup creates recoverable copies. Recovery normally requires an operator or automation to restore data and restart service.
- Replication maintains additional copies, but replicas may be read-only, asynchronous or unable to take over automatically.
- High availability keeps a service operating through failures, typically through health detection, leader election, routing and a tested failover process.
- Multi-writer operation accepts writes through more than one location or node. It requires explicit ordering, conflict handling or distributed transactions.
A replica can improve read latency without improving write availability. A Litestream backup can provide excellent disaster recovery without being an online replica. A system can also advertise multiple write endpoints while internally routing every transaction to one authority. Architecture—not the endpoint count—determines the consistency and failure behavior.
Three architectures for running SQLite across servers
1. rqlite: a Raft-coordinated SQLite cluster
rqlite is an open-source, MIT-licensed distributed relational database that uses SQLite as its storage engine and Raft consensus for cluster coordination. Applications communicate with rqlite through its network API rather than opening a shared SQLite file.
A leader accepts writes and appends database operations to the Raft log. A majority of voting nodes must acknowledge a log entry before the cluster can commit it. The committed operation is then applied to SQLite on the nodes. This produces an ordered write history and prevents two sides of a network partition from independently accepting conflicting writes.
Raft consensus gives rqlite its high-availability behavior. If the leader fails, a quorum of surviving nodes can elect another leader. In a three-node cluster, one node can fail while writes continue. The isolated minority cannot commit writes, which favors consistency over write availability during a partition.
Read behavior depends on the selected consistency level. A local or weak read can be faster but potentially stale, while stronger modes coordinate with the leader to provide fresher guarantees at additional latency. Developers should consult the official rqlite documentation for current read-level semantics, backup procedures and cluster configuration.
rqlite is a strong fit when a modest-write workload needs automatic failover and consistent coordination. It is not a transparent shared-filesystem extension, and consensus does not create unlimited write scaling. Every committed write still travels through an ordered Raft path.
2. Litestream: continuous backup and point-in-time recovery
Litestream takes a fundamentally different approach. It observes SQLite’s write-ahead log and continuously copies changes to remote storage, commonly object storage. Snapshots and streamed WAL data can then reconstruct the database after a server loss.
This is best understood as a Litestream backup and disaster-recovery system, not a consensus-based distributed database. The application continues using a normal local SQLite file. Litestream does not coordinate writes among several active application servers, elect a leader or automatically direct traffic to a replacement machine.
If the source server fails, a replacement must restore the latest database state and resume the application. Recovery-point exposure depends on how much recent WAL data had not reached remote storage. Recovery time includes provisioning, download, replay and application startup. Both objectives should be measured through restore drills rather than inferred from upload frequency.
A temporary loss of connectivity usually does not stop local SQLite writes immediately; Litestream can upload accumulated changes after connectivity returns. The trade-off is a larger durability window while the remote destination is unreachable. Monitoring should therefore cover replication position, upload errors, retained WAL data and successful restore tests.
Litestream is open source under the Apache License 2.0. It is ideal when one server is operationally acceptable but losing that server’s disk is not. Adding orchestration can shorten recovery, but orchestration does not transform asynchronous backup streaming into Raft consensus or synchronous SQLite replication.
3. Turso and libSQL: managed replicas and edge-oriented deployment
Turso’s ecosystem grew around libSQL, an open-source, MIT-licensed fork of SQLite designed to support network access, replication and extensions useful to hosted deployments. Turso provides the managed-service layer: database provisioning, authentication, regional placement, observability and platform-operated infrastructure.
In the established libSQL replication model, a primary write authority commits changes while remote or embedded replicas synchronize from it. Replicas can place reads near users, and write requests made through replica-facing clients can be forwarded to the write authority. Embedded replicas maintain a local database for low-latency reads and synchronize according to application or client behavior.
That does not mean disconnected replicas can independently accept arbitrary writes and merge them later. If an embedded replica loses connectivity, local reads may continue from its last synchronized state, but operations requiring the remote write path cannot receive the same guarantees until connectivity returns. Replica lag also means an ordinary local read may not immediately observe a write performed elsewhere unless the selected client workflow provides read-your-writes behavior.
Turso’s platform and SQLite-compatible engine work have continued to evolve, so teams should verify whether a chosen product, region or deployment mode uses primary-based replication, embedded synchronization or a separately documented distributed-write capability. Turso’s current primary documentation defines the supported topology and consistency semantics. A managed service’s multi-writer feature, where explicitly offered, is a service-level protocol; it must not be attributed to an ordinary local SQLite file.
Turso is compelling for read-heavy applications, database-per-tenant designs and globally distributed reads where operating replication infrastructure would be disproportionate. Its convenience introduces platform dependency, network-path considerations and service-specific limits that should be evaluated before migration.
Compact distributed SQLite comparison
| Approach | Primary purpose | Model | Write behavior | Operational burden | Best fit |
|---|---|---|---|---|---|
| rqlite | Consistent HA cluster | Raft-replicated operation log | Leader coordinates ordered writes through quorum | Medium: operate nodes, quorum and backups | Small HA services with moderate writes |
| Litestream | Backup and disaster recovery | Snapshots plus continuous WAL streaming | Normal local SQLite writer | Low, but restores must be automated and tested | Single-node apps needing low-cost recovery |
| Turso/libSQL | Managed cloud and edge data | Managed remote or embedded replicas | Product-specific authority, forwarding and consistency | Low for customers; platform operates infrastructure | Distributed reads, edge workloads and many small databases |
Failure, partition and recovery trade-offs
Failure behavior is the most useful architecture test. With rqlite, a healthy majority can elect a leader and continue. A minority partition loses write availability by design. Cross-region quorum placement increases failure tolerance but also adds round-trip latency to commits.
With Litestream, the local application may remain available during a remote-storage outage, but newly written data has greater recovery risk until streaming catches up. A host failure is an actual recovery event, not an automatic consensus failover.
With Turso or another managed SQLite cloud database, behavior depends on replica type and service guarantees. Reads may continue from cached or embedded state during disconnection, while writes requiring coordination can fail, block or be routed elsewhere. Lag metrics, failover documentation and consistency options should be reviewed together.
No architecture eliminates backups. rqlite replicas can faithfully replicate accidental deletion. Managed replicas can repeat a destructive migration. High availability protects service continuity; versioned backups and recovery procedures protect data history.
SQLite vs PostgreSQL: when to choose each
The SQLite vs PostgreSQL decision should reflect workload shape rather than fashion. SQLite-based systems work well when data fits comfortably on individual nodes, write concurrency is moderate, schemas are straightforward and operational simplicity has high value.
PostgreSQL or another client-server database is usually the safer choice when an application needs many concurrent writers, mature role and permission controls, complex extensions, extensive analytical SQL, large shared datasets or established tooling for connection pooling, change-data capture and cross-service integration.
Moving an existing SQLite application to rqlite or libSQL is not automatically zero-effort. Network APIs alter latency and error handling. SQL compatibility does not guarantee identical extensions, pragmas, transaction behavior or driver support. Test migrations with production-sized data, concurrent transactions and realistic failure injection.
A practical decision framework
- Choose plain SQLite plus Litestream for a small web app that can tolerate a short recovery period but needs durable off-machine backups.
- Choose rqlite when automatic leader failover and consensus-backed writes matter more than maximizing write throughput.
- Choose Turso/libSQL when managed operations, many databases, local reads or edge placement are the main requirements.
- Evaluate documented multi-writer services when writes must originate in multiple locations, paying close attention to conflict, partition and consistency semantics.
- Choose PostgreSQL or another distributed client-server system when high write concurrency, broad ecosystem support or sophisticated server features dominate.
Before committing, document acceptable data loss, recovery time, stale-read tolerance, partition behavior and peak concurrent writes. Add monitoring for replica lag, quorum health, backup age and restore success. Then choose the simplest architecture that meets those explicit requirements—not the one with the most distributed label.
Frequently asked questions
Is SQLite itself a distributed database?
No. Standard SQLite is an embedded database operating on a local file. Products such as rqlite, Litestream and libSQL add consensus, recovery or replication around SQLite or SQLite-compatible engines.
Does Litestream provide SQLite high availability?
Not by itself. Litestream continuously protects data for restoration, but it does not provide leader election, traffic routing or coordinated failover among active database nodes.
Does distributed SQLite support multiple writers?
It depends on the architecture. rqlite can accept networked requests but orders writes through a Raft leader. Primary-replica systems may forward writes to one authority. Only explicitly documented multi-writer services should be treated as distributed-write systems.
Can distributed SQLite replace PostgreSQL?
Sometimes, but not universally. It can simplify moderate workloads and edge-heavy applications, while PostgreSQL remains stronger for high concurrent-write demand, advanced server features and large shared operational datasets.
