# Litestream v0.5.0

> Clean Markdown view of GeekNews topic #23422. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23422](https://news.hada.io/topic?id=23422)
- GeekNews Markdown: [https://news.hada.io/topic/23422.md](https://news.hada.io/topic/23422.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-10-04T08:33:09+09:00
- Updated: 2025-10-04T08:33:09+09:00
- Original source: [fly.io](https://fly.io/blog/litestream-v050-is-here/)
- Points: 1
- Comments: 1

## Topic Body

- **Litestream v0.5.0**는 **SQLite 기반 애플리케이션의 복원력**을 크게 향상시키는 업데이트  
- 새로운 **LTX 파일 포맷**을 도입하여 **효율적인 시점 복구(PITR)** 및 데이터 압축 기능을 지원  
- 여러 Litestream 인스턴스 간 **세대(generation)** 개념을 제거하여 관리 및 운용을 간소화  
- JetStream 지원 및 **모던 Go SQLite 드라이버로의 전환** 등 개발과 통합 환경이 더 편리해짐  
- 향후 **VFS 기반 읽기 복제본** 등 더 강력한 기능 추가 예정  
  
---  
  
### 개요 및 주요 업데이트  
  
- Litestream은 **SQLite 애플리케이션을 위한 백업 및 복구 도구**로, 오픈소스이며 어디서나 실행 가능한 점이 특징임  
- **서버 장애 복구**가 간편하여, SQLite를 기반으로 한 전체 스택 애플리케이션 구축에 안전성을 보장함  
- 최신 버전(v0.5.0)은 **속도 개선**과 **시점 복구(Point-In-Time Recovery, PITR)** 를 지원함  
  
### LiteFS와 Litestream의 발전 흐름  
  
- Fly.io의 Ben Johnson이 개발한 주요 SQLite 관련 프로젝트는 **Litestream**과 **LiteFS**임  
- **LiteFS**는 FUSE 파일 시스템을 활용해 데이터베이스 내부 트랜잭션 수준의 라이브 복제를 지향함  
- 그러나 시장의 수요는 **운용이 더 간단한 Litestream**에 집중되어, LiteFS에서 얻은 기술적 교훈을 Litestream에 다시 적용하게 되었음  
  
### LTX 파일 포맷 도입  
  
- 기존의 SQLite **페이지 단위 백업 방식**의 한계와 비효율성 해소를 위해 **LTX(트랜잭션 기반 포맷)** 를 도입함  
- LTX는 **트랜잭션 순서에 따른 페이지 범위 관리** 및 **중복 페이지 압축(compaction)** 기능을 제공함  
  
  - 예시: 여러 LTX 파일을 최신순으로 적용, 중복된 페이지는 최신 버전만 반영하여 최종 데이터베이스 상태를 빠르게 복원 가능함  
  - 파일 계층 구조를 통해 30초, 5분, 1시간 단위로 LTX 파일을 통합하여 **복원에 필요한 파일 수를 대폭 줄임**  
  
- **데이터 복구 속도**는 오직 I/O 처리량에 의해 제한됨  
  
### 세대(generation) 개념 제거  
  
- Litestream은 **일반적인 유닉스 프로세스**처럼 실행 및 충돌 가능하며, 동작 중단 시 데이터 동기화에 불일치 현상이 발생함  
- 이전에는 여러 인스턴스 간 충돌 방지를 위해 **세대(generation)** 라는 관리 방식을 도입했으나,  
- LTX로 전환하면서 **트랜잭션 ID 기반 복구**가 가능해져, 복잡한 세대 관리가 불필요해짐  
  
### Litestream v0.5.0 업그레이드  
  
- 워낙 파일 포맷이 변경되어, v0.3.x WAL 세그먼트에서 직접 복구가 불가능함  
- 업그레이드는 단순하게 **새 버전 실행 → 신 LTX 파일 생성** 방식이고, 이전 WAL 파일도 그대로 보존됨  
- 구성 파일 호환성도 유지됨  
- 주요 변경점: 이제 **데이터베이스 당 단일 복제 대상만 허용**되며, 이는 개발 용이성과 복제 충돌 회피를 위한 결정임  
- 명령어는 기존과 같으나, 트랜잭션 ID(TXID) 기반 참조 방식으로 변경됨  
  
### 기타 개선점  
  
- LTX 파일 포맷 라이브러리의 **페이지 단위 압축** 및 **인덱스 추가**로 대용량 파일 내 선택적 페이지 접근 및 기능 확장 가능함  
- 향후 **특정 시점 데이터 쿼리** 등 추가 기능이 구현 가능해짐  
- **CGO 의존성 제거** 및 Go SQLite 드라이버를 modernc.org/sqlite로 전환하여 **자동 빌드와 크로스 컴파일 환경에 이점**이 생김  
- **JetStream 지원** 복제본 타입과, S3/Google Storage/Azure Blob Storage 클라이언트 최신화 및 S3 API 신버전 지원이 포함됨  
  
### 향후 계획  
  
- 읽기 복제(target) 환경을 위한 **Litestream VFS** 기능 개발이 진행되고 있음  
- 이 기능을 통해 **S3에서 필요한 페이지만 즉시 읽어서 빠른 복제 생성**이 가능해질 예정임  
- 프로토타입이 이미 존재하며, 공개를 앞두고 있음

## Comments



### Comment 44529

- Author: neo
- Created: 2025-10-04T08:33:11+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45453936) 
* Fly.io에 SQLite 앱을 배포하는 과정에서 개발자 경험이 다소 아쉬움, 프로덕션 Rails 앱을 실행하려고 몇 시간 동안 시도했지만 데이터베이스 초기화, 마이그레이션, 쓰기 가능 상태 등 다양한 문제에 부딪혔음, 문제의 근원은 자신이 만든 gem의 eager loading이었지만, 그 위에 여러 레이어의 runner가 있어서 진단이 어려웠음, DX 개선에 좀 더 힘을 써줬으면 하는 바람이 있지만, 큰 고객들이 이런 워크로드를 쓰지 않기 때문에 Fly.io 입장에서는 우선순위가 아닐 것으로 생각함, 프로덕션에서 SQLite 앱을 배포해본 사람들이 어떤 호스트를 쓰고 있는지 궁금함

  * 작년에 Fly에서 Rails 8 앱을 새로 세팅했고, 메인 데이터 저장소로 PG를 쓰고 있지만 보조 solid stack db들은 SQLite를 사용함, solid queue 마이그레이션과 관련해 Rails단에서 약간의 문제가 있었으나 Fly 쪽 문제는 아니었음, 메인 PG를 SQLite로 이전하는 것도 고려 중이며 현재는 일부에서 SQLite를 잘 활용하고 있음

  * 나는 프로덕션 환경에서 콘솔 앱에 SQLite를 사용하고 있음, DB는 파일 공유 드라이브에 위치함

* Fly가 2년간의 개발 중단 끝에 다시 Litestream 개발을 재개해서 매우 반가움, Litestream을 매번 사용하는데 너무 만족함, “하루에 몇 페니 정도”라는 광고 문구보다 실사용 비용이 훨씬 저렴함, 실제 프로덕션 앱에서 S3로 Litestream 복제를 썼을 때 월 실제 비용이 2~3센트(0.02~0.03달러) 수준이었음 [관련 경험담](https://mtlynch.io/litestream/#using-logpaste-in-production) 링크 공유

* 곧 Litestream이 모든 s3-호환 목적지 지원 예정이라는 사실이 신기함, 지금까지는 SFTP 솔루션을 사용 중인데 이유는 하드코딩된 클라우드 오브젝트 스토리지 서비스를 쓰지 않기 때문임, 개발자들에게 감사의 말을 전함 [PR 링크](https://github.com/benbjohnson/litestream/pull/731) 및 [가이드 링크](https://litestream.io/guides/#replica-guides)

* Litestream을 곧 사용해보고 싶음, 실제 복원 시간이 얼마나 걸리는지에 대한 벤치마크나 데모가 궁금함, 예전에는 직접 S3 백업을 구현했는데 당시에는 Litestream으로 1,000개 행을 복원하는 데 20분이나 걸렸음, 꽤 비최적화된 느낌이었음, 요즘 복원 속도가 얼마나 개선됐는지 궁금함

* Litestream이 [sqlite.org/rsync](https://sqlite.org/rsync.html) 대비 갖는 장점이 무엇인지 궁금함

  * Litestream의 차별점은 다른 쪽 끝에 “서버”가 필요 없고 오브젝트 스토리지만 있으면 된다는 점임, 이게 비용상 더 저렴하게 작용할 수 있음

  * Litestream에서는 시점 복구(Point In Time Recovery)가 가능함, 현재 시점 레플리카만 있는 것이 아니라 아무 시점 스냅샷으로 복원이 가능함

* LiteFS와 Litestream에 관련된 흥미로운 이야기로, “시장 반응이 답이다! 사용자들은 Litestream을 더 선호한다”, 솔직히 Litestream이 더 쉽게 운용되고 이해하기 쉬워서 이쪽에 다시 집중하게 됐음

  * 내 생각에도 말이 됨, LiteFS는 FUSE를 기반으로 커스텀 파일시스템을 실행하고 마운트해야 했지만, Litestream은 SQLite DB 파일과 관련된 WAL 파일을 가리키는 Go 바이너리 하나만 있으면 됨

* Litestream Revamped 관련 링크와 Hacker News 토론글을 공유함  
  [블로그](https://fly.io/blog/litestream-revamped/)  
  [HN 토론글](https://news.ycombinator.com/item?id=44045292)

* 우리는 사내 애플리케이션을 외부 원격 플릿에 배포하고 있는데 인터넷이 불안정해서 데이터 수집 시스템을 제대로 만들기 힘듦, Litestream이 이런 불안정한 환경에서 백업을 어떻게 처리하는지, 그리고 여러 백업을 중앙 DB로 통합해서 쿼리할 수 있는지 궁금함

* 소규모 경고로, 한 번은 레거시 비즈니스 앱을 Azure로 이전할 때 앱과 함께 로컬 MSSQL 서버가 동작하는 구조(마치 Litestream 패턴처럼)를 다루게 됐음, 앱이 로컬(1ms 미만 지연) 접근을 가정하고 개발되어서 모든 곳에 N+1 쿼리가 심각하게 있던 경험이 있음, 이로 인해 다른 구조로 전환하는 것이 거의 불가능해졌음, 만약 이런 형태의 호스팅을 썼다가 스케일 한계에 부딪힐까봐 걱정된다면 추천하지 않음, 다만 단일 머신만으로도 상당히 큰 규모까지 갈 수 있으니 현실적으로는 별 문제 아닐 수도 있다고 봄

  * 단일 인스턴스가 20TB 이상의 RAM과 수백 개의 코어를 지원하는 요즘, 이 옵션은 충분히 경쟁력이 있다고 생각함, 사용자/테넌트 단위로 셀 아키텍처와 결합하면 더 효율적인 방식이 될 수 있음

  * 나도 예전에 앱 서버와 데이터베이스가 같은 랙에 있던 제품을 작업했었는데, 비슷하게 저지연 구조였음, 그 제품이 성공해서 N+1 쿼리가 수천 개로 늘어나면 1ms가 곧 500ms 이상이 되곤 했음, 두 달마다 NewRelic에서 느린 구간 찾아 고치는 작업이 반복됐음, Rails 앱이라 N+1 문제가 쉽게 발생하지만 고치기도 비교적 쉬웠음

  * 잘못된 쿼리 관행은 언젠가는 반드시 문제를 일으킴, 이 접근 방식 자체의 단점이라고 보기는 어려움

  * 사실 결국 이런 서비스를 쓰면 자신의 코드가 얼마나 문제가 있는지 드러나는 것뿐이라는 점에서 큰 트레이드오프가 아니라고 생각함, 코드 탓이지 서비스 탓이 아님

  * N+1이 무엇인지 질문함

* Litestream을 정말 좋아함, 사용이 쉽고 한 번도 크래시가 없었음, systemd 유닛 서비스로 쓰는 것을 추천함, 백업 툴로만 쓰는 게 아니라 데이터베이스 미러링에도 사용 중임, 앞으로 나올 read-replica 기능도 기대 중임