superfly/litefs

FUSE-based file system for replicating SQLite databases across a cluster of machines

View on GitHub ↗Jump to charts ↓

Summary Information

Updated 26 minutes ago
Type:Server / PlatformCategory(s):Relational & SQL DatabasesDatabases & Storage
Added to GitGenius on September 14th, 2026
Created on April 21st, 2022
Open Issues & Pull Requests: 62 (+0)
GitHub issues: Enabled
Number of forks: 128
Total Stargazers: 4,879 (+0)
Total Subscribers: 46 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 34.9 hours
Mean response time: 118.8 days
90th percentile: 655.9 days
Tracked items: 7

Most active contributors

Sign in to see contributor activity.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 8
New in 7 days: 0
Closed in 7 days: 0
Avg open age: 752 days
Stale 30+ days: 8
Stale 90+ days: 8

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

  • enhancement (3)
  • packaging (1)

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

LiteFS is a FUSE-based file system for replicating SQLite databases across a cluster of machines.

LiteFS addresses the challenge of distributing SQLite, which is designed for single-machine use, to multiple nodes in a cluster. It works as a passthrough file system that intercepts writes to SQLite databases, detects transaction boundaries, and records changes at the per-transaction level in LTX files. This approach allows SQLite to operate transparently across a distributed system without requiring application-level changes to how the database is accessed.

LiteFS suits teams running SQLite-based applications that need high availability or geographic distribution without the complexity of migrating to a traditional distributed database. It is particularly valuable for applications already built around SQLite that want to scale beyond a single machine. The project is in beta, meaning it is actively maintained but not yet feature-complete; notably, database deletion is not yet implemented, which causes some test failures during teardown.

The project maintains a structured contribution process that distinguishes between bug fixes, which can be submitted directly, and feature contributions, which require prior discussion in an issue and are implemented by the maintainers using submitted pull requests as starting points. Development activity shows engagement with the SQLite TCL test suite as a validation target, indicating a commitment to compatibility with SQLite's own test standards. The maintainers follow a deliberate roadmap for feature addition and prioritize code style, implementation details, and test coverage in a specific order.