HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
superfly
litefs
Go2022–2025
superfly / litefs

litefs

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

Data & DatabasesSystems & Infrastructure
Explore on GitHubRead Hacker News discussions
26Distinct people
38Mentions
0Explicit recommenders
4.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

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

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:59:22 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year38 dated mentions

Observed mentions: 2022-07-26 16:14:28 UTC to 2025-06-03 18:02:50 UTC.

051015202022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 19 mentions; 1 submissions, 18 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 14 mentions; 0 submissions, 14 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC19118
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC14014
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC312
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
LiteFS LiteFS is a FUSE-based file system for replicating SQLite databases across a cluster of machines. It works as a passthrough file system that intercepts writes to SQLite databases in order to detect transaction boundaries and record changes on a per-transaction level in LTX files. This project is actively maintained but is currently in a beta state. Please report any bugs as an issue on the GitHub repository. You can find a Getting Started guide on LiteFS' documentation site. Please see the ARCHITECTURE.md design document for details about how LiteFS works. SQLite TCL Test Suite It's a goal of LiteFS to pass the SQLite TCL test suite, however, this is currently a work in progress. LiteFS doesn't have database deletion implemented yet so that causes many tests to fail during teardown. To run a test from the suite against LiteFS, you can use the Dockerfile.test to run it in isolation. First build the Dockerfile: docker build -t litefs-test -f Dockerfile.test . Then run it with the filename of the test you want to run. In this case, we are running select1.test: docker run --device /dev/fuse --cap-add SYS_ADMIN -it litefs-test select1.test Contributing LiteFS contributions work a little different than most GitHub projects. If you have a small bug fix or typo fix, please PR directly to this repository. If you would like to contribute a feature, please follow these steps: Discuss the feature in an issue on this GitHub repository. Create a pull request to your fork of the repository. Post a link to your pull request in the issue for consideration. This project has a roadmap and features are added and tested in a certain order. Additionally, it's likely that code style, implementation details, and test coverage will need to be tweaked so it's easier to for me to grab your implementation as a starting point when implementing a feature.
Read the full README on GitHub

What Hacker News says

19 sources
stevefan1999·Nov 11, 2022
The very problem of SQLite: Single user only. Although SQLite does have WAL but it still doesn't allow you to do concurrent write unless you want to see file corruption. This means SQLite is very much locked to things that works with one specific purpose and almost nothing else. Sure, you can be read-only, but you have to run alongside the app in the specific node, too. Another problem (although without solving the single user mindset this wouldn't be a problem at all) is high availability. You want to make sure that your database won't get lost do you. Things like Litestream [1] attempts to solve the SQLite backup problem it by continuously saving the database state and pack t up to S3-compatibles or file system but its just half the story. You want to make sure your operation not stopping. This is where HA comes in to save you from an e
Read the rest
mergency fixup when you are enjoying your holiday. It doesn't mean that nobody tried to solve both these problems though. Ahem, introducing rqlite [2]. Although my own experience is not very great because the memory usage is quite high and does not fit my need (because the embedded device only has 512MB on it, and every byte counts, sorry), I guess that's the price to pay if you want to turn a non-multiuser, non-concurrently acccess database into one...Another honorable mention would be LiteFS [3] but I haven't used it yet so I have no say on it. [1]: https://litestream.io/ [2]: https://github.com/rqlite/rqlite [3]: https://github.com/superfly/litefs
In Database Review 2021
yencabulator·Sep 22, 2022
Looks like LiteFS invalidates the cached file contents on every update of position. This means there is never stale data to be read. (The client needs to make sure to consume that in a single pread/read syscall, or it could observe a sheared state.) Disclaimer: I wrote the FUSE framework LiteFS uses, https://bazil.org/fuse https://github.com/superfly/litefs/blob/52e269d4b04070690ce2... https://github.com/superfly/litefs/blob/52e269d4b04070690ce2... https://github.com/superfly/litefs/blob/a5cf33d1a3a91873d4ad...
In LiteFS
benbjohnson·Sep 22, 2022
The TH3 test is proprietary and, IIRC, it might only be available to SQLite Consortium members and that's $125k/year. We do pay for SQLite support at Fly.io but not quite to that level. We do have plans to run against the Tcl test suite[1] although most of that test suite is not applicable to LiteFS since it tests higher level constructs. Since LiteFS acts on the raw pages, it really just functions similar to a VFS. Out of the 130K source lines of code in SQLite, only 4.8k are for the Unix VFS. As such, the testing coverage from the SQLite test suite mostly tests non-VFS code. [1]: https://github.com/superfly/litefs/issues/17
In LiteFS
no_wizard·Sep 21, 2022
This is distributed SQLite 3, running (I assume at least partially managed?) LiteFS[5] for you. Which is pretty cool! What I'd like to have seen is how this compares to things like rqlite[1] or Cloudflare's D1[2] addressed directly in the article That said, I think this is pretty good for things like read replica's. I know the sales pitch here is as a full database, and I don't disagree with it, and if I was starting from scratch today and could use this, I totally would give it a try and benchmark / test accordingly, however I can't speak to that use case directly. What I find however and what I can speak to, is that most workloads already have database of some kind setup, typically not SQLite as their main database (MySQL or PostgreSQL seem most common). This is a great way to make very - insanely, really - fast read replica's across re
Read the rest
gions of your data. You can use an independent raft[3][4] implementation to do this on write. If your database supports it, you can even trigger a replication directly from a write to the database itself (I think Aurora has this ability, and I think - don't quote me! - PostgreSQL can do this natively via an extension to kick off a background job) To that point, in my experience one thing SQLite is actually really good at is storing JSON blobs. I have successfully used it for replicating JSON representations of read only data in the past to great success, cutting down on read times significantly for APIs as the data is "pre-baked" and the lightweight nature of SQLite allows you to - if you wanted to naively do this - just spawn a new database for each customer and transform their data accordingly ahead of time. Its like AOT compilation for your data. if you want to avoid some complexity with sharding (you can't always avoid it outright, but this can help cap its complexity) this approach helps enormously in my experience. Do try before you buy! EDIT: Looks like its running LiteFS[5] not LiteStream[0]. This is my error of understanding. [0]: https://litestream.io/ [1]: https://github.com/rqlite/rqlite [2]: https://blog.cloudflare.com/introducing-d1/ [3]: https://raft.github.io/ [4]: https://raft.github.io/#implementations [5]: https://github.com/superfly/litefs
In LiteFS
yencabulator·Aug 21, 2022
Relevant reading about FoundationDB building a SQL database on top of a distributed key-value store: https://www.voltactivedata.com/blog/2015/04/foundationdbs-le... (That one replaced SQLite's btree, this one puts pages of the btree as values in the key-value store.) Another approach using FUSE, making arbitrary SQLite-using applications leader-replica style distributed for HA: https://github.com/superfly/litefs (see also https://litestream.io/ for WAL-streaming backups, that's the foundation of this)
In Turning SQLite into a Distributed Database

Showing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.