superfly/litefs

★ 4,765GoAudience · ops devopsComplexity · 4/5LicenseSetup · hard

Mindmap

mindmap
  root((LiteFS))
  How It Works
    FUSE file system
    Intercepts writes
    Transaction log
    Ships to replicas
  Architecture
    Primary node writes
    Replica nodes read
    Local SQLite copy
    Network replication
  Use Cases
    Multi-region apps
    Edge deployments
    Low latency reads
    No central DB server
  Status
    Beta release
    Core replication works
    DB deletion pending
  Made By
    Fly.io team
    Fly.io docs site

mindmap root((LiteFS)) How It Works FUSE file system Intercepts writes Transaction log Ships to replicas Architecture Primary node writes Replica nodes read Local SQLite copy Network replication Use Cases Multi-region apps Edge deployments Low latency reads No central DB server Status Beta release Core replication works DB deletion pending Made By Fly.io team Fly.io docs site

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Run your SQLite app across multiple servers or regions so reads are always fast and local

USE CASE 2

Eliminate the need for a centralized database server by giving every node its own synced copy

USE CASE 3

Deploy a web app to edge locations worldwide while keeping the database consistent everywhere

USE CASE 4

Add read replicas to a SQLite-backed application without changing your application code

Tech stack

GoSQLiteFUSEreplication

Getting it running

Difficulty · hard Time to first run · 1day+

Currently in beta, core replication works but some features are incomplete. Best suited for Fly.io deployments. Requires FUSE support on the host OS. Consult Fly.io documentation for getting-started guide.

Apache 2.0 license, free to use and modify, even in commercial products, as long as you include the license notice.

In plain English

LiteFS is a tool for keeping copies of SQLite databases in sync across multiple servers. SQLite is a type of database that stores all its data in a single file on disk, which makes it simple to use but traditionally difficult to share across a cluster of machines. LiteFS solves this by sitting between your application and the database file, intercepting writes as they happen and recording exactly what changed in each transaction. The way it works is through something called a FUSE file system, which is a technique that lets software intercept file reads and writes at the operating system level. LiteFS mounts itself as a passthrough layer: applications read and write to what looks like a normal file, but LiteFS is watching, capturing each database transaction in a compact change-log format. Those change records can then be shipped to replica machines so their copies of the database stay current. This is particularly useful for applications deployed across multiple data centers or edge locations. Instead of requiring a centralized database server that every node must reach over the network, each node can hold a local copy of the SQLite database and read from it quickly. Writes still need to go through the primary node, which coordinates replication, but reads are completely local. LiteFS is built and maintained by Fly.io, the cloud hosting company. It is currently in beta, meaning the core replication functionality works but some features are still in progress. For example, database deletion is not yet fully implemented. Documentation and a getting-started guide are available on the Fly.io documentation site. The project accepts bug fix contributions via pull requests, and larger feature contributions are coordinated through issues before development begins.

Copy-paste prompts

Prompt 1

I have a SQLite-backed web app deployed on Fly.io and want to add read replicas in multiple regions using LiteFS. Walk me through the setup.

Prompt 2

Explain how LiteFS uses a FUSE file system to intercept SQLite writes without requiring changes to my application code.

Prompt 3

What are the current limitations of LiteFS in beta that I should know about before using it in production, especially around database deletion and write coordination?

Prompt 4

How does LiteFS handle the case where my application tries to write to a replica node instead of the primary? What happens to that write?

Open on GitHub → Explain another repo

← superfly on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.