---
title: "Litestream: Revamped"
description: "Litestream’s redesign aims to make SQLite suitable for more deployment scenarios while preserving its embedded, application-oblivious model. The original tool continuously streamed WAL pages to S3-compatible object storage, but restores could be slow because they replayed every change since the last snapshot. The new design adopts LiteFS’s transaction-aware LTX format, sorted changesets, and compaction, enabling faster point-in-time restores with fewer duplicate pages; conditional writes provide time-based leases that prevent overlapping instances from confusing a destination. Planned additions include a VFS-based read-replica layer that fetches and caches pages from object storage, plus replication across hundreds or thousands of database files. The remote read path may be less efficient than local SQLite, but caching and prefetching are expected to provide strong performance for suitable use cases."
---

# Litestream: Revamped

[Fly.io](https://yomu.fyi/company/fly-io) · May 20, 2025

**Type:** Announcement

## Summary

Litestream’s redesign aims to make SQLite suitable for more deployment scenarios while preserving its embedded, application-oblivious model. The original tool continuously streamed WAL pages to S3-compatible object storage, but restores could be slow because they replayed every change since the last snapshot. The new design adopts LiteFS’s transaction-aware LTX format, sorted changesets, and compaction, enabling faster point-in-time restores with fewer duplicate pages; conditional writes provide time-based leases that prevent overlapping instances from confusing a destination. Planned additions include a VFS-based read-replica layer that fetches and caches pages from object storage, plus replication across hundreds or thousands of database files. The remote read path may be less efficient than local SQLite, but caching and prefetching are expected to provide strong performance for suitable use cases.

## Context

Litestream was created to let full-stack applications use SQLite without tying their data to a single server. Its original WAL streaming and restore design made frequent-write databases slow to restore and made replicating large numbers of databases from one process infeasible.

## Approach / What changed

The redesign applies LiteFS learnings through transaction-aware LTX changesets and compaction, conditional object-store writes for time-based leases, and a planned VFS-based read-replica layer that fetches and caches pages from S3-compatible storage. It also enables replication across database files matching patterns such as /data/\*.db.

## Takeaways

- LTX stores sorted, transaction-associated page ranges, allowing multiple time ranges to be compacted into a changeset containing only the latest version of each page.
- Conditional writes from modern object stores can provide Litestream with a time-based lease, avoiding a Consul dependency while preventing overlapping instances from confusing one destination.
- The planned VFS read-replica layer trades local SQLite efficiency for remote reads from Tigris or S3, with caching and prefetching intended to improve performance for suitable use cases.

**Tags:** [Object Storage](https://yomu.fyi/topic/object-storage), [Replication](https://yomu.fyi/topic/replication), [SQLite](https://yomu.fyi/topic/sqlite)

- Source: [Fly.io](https://fly.io/blog/litestream-revamped)
- Source URL: https://fly.io/blog/litestream-revamped
- Ingested by Yomu: 2026-09-02T12:00:09.525Z

[Read original post](https://fly.io/blog/litestream-revamped)