Loading…
Topic
LiteFS
6 posts about LiteFS. Every summary links to the original.
- 6 posts
- 1 company
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
Operationalizing Macaroons
Operationalizing Macaroons at Fly.io requires treating them as online-stateful bearer tokens whose nonces must be checked against database state, while keeping root secrets away from the primary API cluster. The team built tkdb, a roughly 5,000-line Go service backed by encrypted SQLite managed with LiteFS and Litestream, deployed on isolated hardware across the US, Europe, and Australia. Its HTTP/Noise interface supports verification and restricted signing, while FlyCast routing, retries, and client-side caching reduce the impact of unreliable global connectivity; verification caching exceeds 98%. Revocation uses blacklist state, and third-party caveats let services such as flyd obtain narrowly scoped secret-reading authority through tkdb rather than holding broad credentials. OpenTelemetry, standard metrics, and a retained OpenSearch audit trail provide visibility, while the post concludes that Macaroons’ internal infrastructure benefits outweigh limited user adoption.
Skip the API, Ship Your Database
The post describes an unexpected use for LiteFS, a distributed SQLite database: replacing service-to-service APIs with read-only database replicas. Typical APIs require anticipating access patterns; shipping the full database lets clients use SQL joins, aggregation, and windowing locally, while one-way LiteFS replication avoids chatty gossip and is simple to configure with an upstream primary hostname. Moving queries to client hardware removes shared service compute contention and the need for tenant rate limiting and timeouts, but replicas cannot handle mutations and raw schema changes create looser contracts, mitigated by backward-compatible changes and views. Data access is harder to restrict in multi-tenant databases, so per-tenant SQLite files are a suggested workaround. The approach is positioned for specific read-heavy use cases, potentially including local copies of Stripe or GitHub data, with event buses such as Kafka generating per-tenant databases.
Tracking Application-Level Consistency with LiteFS
LiteFS must keep an application’s view consistent when a write reaches a primary and a subsequent read is served by a lagging replica. The project first considered making applications track each database’s replication position—a TXID paired with a post-apply checksum—and wait for replicas to catch up, but rejected that complexity and abandoned language-specific libraries. It instead introduces a thin HTTP proxy in front of the application: method-based request inspection routes writes to the primary, attaches the committed TXID in a cookie, and delays reads until the local replica reaches that position or times out. The proxy also exposes lag through health checks, allowing Fly.io to remove unhealthy replicas from rotation and restore them after reconnection. This design provides read-your-writes guarantees with little application change, but depends on cookies and conventional HTTP request/response traffic, limiting use with some applications and websocket-heavy frameworks.
LiteFS Cloud: Distributed SQLite with Managed Backups
LiteFS Cloud, launched in preview, adds managed backups and restores to LiteFS, an open-source distributed SQLite database that replicates data across application-cluster nodes. Existing LiteFS users had to create snapshots, choose retention, and accept restoration points limited by snapshot frequency; the service instead provides an equivalent snapshot every five minutes and restores within the last 30 days at five-minute granularity. Setup requires LiteFS 0.5.1 or later, a dashboard-created cluster, and an auth token, after which backups are automatic and dashboard restores use the latest snapshot before a selected timestamp. Its LTX format stores changed database pages, while multi-level compactions combine daily snapshots, hourly changes, and five-minute intervals so a restore can stream-merge a minimal set of files. To improve async replication’s durability trade-offs, the primary batches changes, LiteFS Cloud persists them in S3, and a high water mark prevents local transaction files from being removed before storage confirmation.
WAL Mode in LiteFS
LiteFS v0.3.0 adds support for SQLite’s write-ahead log (WAL) alongside the previously supported rollback journal, allowing its distributed file system to replicate transactions from either journaling mode. The post explains how rollback journals and WAL differ, then shows how LiteFS observes filesystem calls, identifies changed pages, and emits a common LTX change-set format; in WAL mode, the final frame’s commit field marks transaction completion. Replica nodes validate LTX files, acquire SQLite-compatible locks, and apply the changes, while the new litefs import command transactionally replaces a database for bootstrapping or snapshot reversion. Version 0.3.0 also replaces previous-page checksum tracking with a per-page checksum map, costing about 3 MB of RAM per gigabyte and roughly 5 ms of CPU time per gigabyte per commit, and adds a trace log whose enabled use can double disk I/O.
Introducing LiteFS
LiteFS is an open-source distributed file system for SQLite that addresses the durability, replication, availability, and latency limitations of deploying SQLite on a single server. LiteFS interposes a FUSE pass-through filesystem between an application and its database, identifies transactions from SQLite’s journal files, packages page changes into LTX files, and ships them to replicas without requiring application-code changes. A Consul-backed, time-based lease elects a primary writer, while local replicas serve reads; checksum state embedded in each LTX file helps detect out-of-order application and preserve byte-for-byte consistency. Because replication is asynchronous, the design trades some durability guarantees for performance and operational simplicity, while defensive checksum checks address potential split-brain failure modes. The project is described as beta-ready, with WAL-mode support, write forwarding, S3 replication, and encryption listed as planned features.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.