Scaling SQLite Beyond a Single Server: A Guide to Distributed Replication with LiteFS on Budget VPS

Introduction: The Changing Paradigm of SQLite in Production

For years, conventional architectural wisdom dictated that SQLite was strictly an embedded database, reserved for local development, mobile applications, or low-traffic IoT devices. When an application required scaling across multiple servers or demanded high availability, engineers instinctively migrated to client-server relational database management systems (RDBMS) like PostgreSQL or MySQL. However, managing these database clusters introduces significant operational complexity, heavy resource overhead, and increased infrastructure costs.

The advent of LiteFS, an open-source fusion file system developed by Fly.io, has fundamentally disrupted this paradigm. LiteFS enables real-time, byte-level replication of SQLite databases across a cluster of independent nodes. By implementing LiteFS, you can leverage the zero-configuration simplicity and blazingly fast in-memory read speeds of SQLite while enjoying the fault tolerance and scalability of a distributed system. This guide provides an enterprise-grade blueprint for setting up a 3-node distributed LiteFS cluster on budget Virtual Private Servers (VPS), achieving high availability on a minimal infrastructure budget.

Understanding LiteFS Architecture

Before diving into the implementation, it is crucial to understand how LiteFS achieves replication. LiteFS operates as a FUSE (Filesystem in Userspace) layer that sits directly between your application and the SQLite database file on disk. When your application executes a write operation, LiteFS intercepts the transactional changes at the file-system level, bundles them into journal files, and replicates them across the cluster.

The Primary-Replica Topology

LiteFS coordinates a cluster using a single-primary, multiple-replica model governed by a distributed consensus protocol (such as Consul or built-in static leasing):

• The Primary Node: The only node capable of executing write transactions. It maintains the authoritative state of the database and broadcasts changes to the rest of the cluster.
• Replica Nodes: Distributed nodes that receive real-time byte-level updates from the primary. These nodes serve read queries locally with near-zero latency, eliminating network round-trips to a central database server.

Note: If the primary node experiences an outage, the remaining replicas automatically participate in a leader election to select a new primary, ensuring continuous uptime and system resilience.

Prerequisites and Network Planning

To follow this guide, you will need three separate VPS instances. To maximize the geographical benefits of a distributed setup, consider provisioning them in different data centers or regions. However, to minimize replication lag, ensure they possess stable network connectivity.

System and Software Requirements

• Operating System: Ubuntu 22.04 LTS or any modern Linux distribution with FUSE support enabled.
• Hardware: 1 vCPU, 1GB RAM, and SSD storage per VPS (standard budget tier).
• Consul Cluster: LiteFS relies on a coordination backend for leader election. We will utilize a lightweight HashiCorp Consul cluster running across our three nodes.

Network Topology Mapping

For the purposes of this guide, assume the following private IP configurations:

1. Node 1 (Primary Candidate A): 10.0.0.1
2. Node 2 (Primary Candidate B): 10.0.0.2
3. Node 3 (Replica Node): 10.0.0.3

Step 1: Preparing the VPS Instances and Installing Consul

First, update the package manager and install the necessary dependencies on all three nodes. Fuse3 is explicitly required by the LiteFS binary to mount the virtual file system.

sudo apt-get update && sudo apt-get upgrade -y
sudo apt-get install -y fuse3 libfuse3-dev curl unzip

Configuring the Consul Cluster

LiteFS uses Consul to determine which node currently holds the distributed write lease. Install Consul on all three servers by adding the official HashiCorp repository, then configure the agent. Create a configuration file at /etc/consul.d/consul.hcl on each node. Below is a production-ready template for Node 1:

node_name = "node-1"
data_dir = "/opt/consul"
bind_addr = "10.0.0.1"
client_addr = "127.0.0.1"

server = true
bootstrap_expect = 3

retry_join = ["10.0.0.1", "10.0.0.2", "10.0.0.3"]

Remember to modify the node_name and bind_addr values on Node 2 and Node 3 to reflect their respective hostnames and private IP addresses. Once configured, start and enable the Consul service across all instances:

sudo systemctl enable consul --now

Step 2: Installing and Configuring LiteFS

Download the latest compiled LiteFS binary from the official GitHub repository and move it to your system path. Execute these commands on all three servers:

LITEFS_VERSION="v0.5.0"
curl -L -o litefs.tar.gz "[https://github.com/superfly/litefs/releases/download/$](https://github.com/superfly/litefs/releases/download/$){LITEFS_VERSION}/litefs-${LITEFS_VERSION}-linux-amd64.tar.gz"
tar -xzf litefs.tar.gz
sudo mv litefs /usr/local/bin/

Crafting the LiteFS Configuration File

Create the primary configuration file at /etc/litefs.yml. This file instructs LiteFS where to mount the file system, how to connect to Consul, and how to manage data synchronization. Apply this unified configuration across all nodes:

fuse:
  dir: "/var/lib/litefs"

data:
  dir: "/var/data/litefs"

coordination:
  type: "consul"
  address: "localhost:8500"
  lease-duration: "10s"

proxy:
  addr: ":8080"
  target: "localhost:3000"
  db: "production.db"

In this configuration, the fuse.dir attribute defines the path where your application will access the SQLite database file (e.g., /var/lib/litefs/production.db). The proxy block acts as an intelligent layer that automatically routes HTTP write requests to the current primary node while handling read requests locally.

Step 3: Initializing the Cluster and Running Your Application

With Consul active and LiteFS configured, you can now initialize the system. Start the LiteFS daemon on each server:

litefs mount -config /etc/litefs.yml

Check the system logs to verify cluster formation. Upon initialization, the three nodes will communicate via Consul, and one node will successfully acquire the primary write lease. The remaining two nodes will enter replica mode and immediately begin listening for file system changes.

Connecting Your Application

Point your application's SQLite database connection string to the newly mounted directory. For example, in a Node.js or Python application, your database initialization would look like this:

const db = new Database('/var/lib/litefs/production.db');

Because LiteFS exposes a standard file system interface, no code alterations are required for basic database operations. SQLite treats the file exactly like a standard local database, while LiteFS manages the underlying distributed consensus and network replication transparently.

Step 4: Managing Write Redirection and Failover

While reads can happen instantaneously on any of your three budget VPS nodes, write transactions must execute exclusively on the primary node. If an application instance running on a replica node attempts to write to /var/lib/litefs/production.db, SQLite will return a SQLITE_BUSY or read-only error.

Handling Write Delegation

To seamlessly manage this architectural constraint, you have two primary implementation paths:

1. Utilize the LiteFS Built-in Proxy: Direct your external web traffic through the integrated LiteFS proxy (configured on port 8080 above). The proxy analyzes incoming HTTP requests. If a request involves a mutation (like a POST or PUT request), the proxy inspects the cluster state and forwards the entire HTTP request directly to the primary node.
2. Application-Level Redirection: Inspect the .primary administrative file exposed by LiteFS in the mount directory. Your application can read this file to determine the current primary node's IP address and programmatically forward write traffic via internal APIs.

Conclusion: Enterprise Reliability on a Budget

By pairing the structural efficiency of SQLite with the distributed capabilities of LiteFS, we have effectively constructed a highly available, fault-tolerant database cluster spanning three affordable VPS instances. This architecture offers the ultimate balance for indie hackers, startups, and budget-conscious enterprises: it retains the raw performance, zero-network read latency, and simplicity of SQLite, while matching the redundancy and high availability profiles of far more expensive cloud database solutions. As your traffic grows, scaling your infrastructure is as simple as spinning up additional budget nodes and attaching them to your existing LiteFS cluster.