분산 SQLite 12년사: rqlite부터 Litestream, Turso까지 한눈에 정리
들어가며
'SQLite는 로컬에서만 쓰는 가벼운 DB'라는 생각, 이제는 바꿔도 될 것 같습니다. 2014년 rqlite가 SQLite 앞에 Raft 로그를 두고 모든 쓰기를 클러스터에 복제하는 방식으로 처음 등장했는데요. 그로부터 12년이 지난 지금, 분산 SQLite는 약 12개 프로젝트가 경쟁하는 하나의 분야가 되었습니다.
이번 글에서는 rqlite 개발자가 직접 돌아본 분산 SQLite의 역사를 따라가면서, 어떤 설계가 어떤 문제를 풀려고 나왔는지 정리해 보겠습니다.
핵심 요약
- 분산 SQLite 설계는 합의(Consensus), 스트리밍(Streaming), 병합(Merge) 세 갈래로 발전했습니다.
- rqlite는 CP 시스템입니다. 리더와 과반수 노드가 승인해야 쓰기가 처리되고, 네트워크 분할로 고립된 소수 노드의 쓰기는 거부합니다.
- Litestream은 합의 없이 SQLite WAL을 S3로 스트리밍해서 단일 노드의 재해 복구를 지원합니다.
- 이 분야는 '직접 운영하는 소프트웨어'에서 '돈 내고 쓰는 관리형 서비스'로까지 넓어졌습니다.
- 투자와 인수는 유료 플랫폼 쪽에 몰렸고, rqlite·dqlite·Litestream은 지금도 무료 오픈소스입니다.
2014년: rqlite의 출발
rqlite는 2014년 9월 첫 공개 글과 같은 주말에 소스 코드도 함께 공개됐습니다.
- 출발점: jut.io의 클러스터 시스템에 작은 관계형 저장소가 필요했습니다. 그런데 데이터를 어느 노드에 둘지 마땅한 답이 없었고, 합의 프로토콜로 SQLite를 복제하면 이 문제가 풀렸습니다.
- 회사는 결국 다른 방식을 골랐지만, 개발자는 범용적인 문제를 작은 해법으로 풀 수 있다고 보고 rqlite 개발을 계속했습니다.
- Raft 구현의 변화: 처음에는 당시 InfluxDB와 etcd도 쓰던
goraft를 사용했고, 2016년 초 Hashicorp의 Raft 구현으로 바꿔 지금까지 쓰고 있습니다. - 그동안 바뀌지 않은 것이 있습니다. 가장 중요한 설계 결정인 CP 시스템이라는 성격입니다.
선행 사례와 동시대의 시도
rqlite보다 먼저, 또는 비슷한 시기에 같은 아이디어를 시도한 곳도 있었습니다.
- Expensify Bedrock: Expensify는 수년 전부터 내부 인프라에서 Paxos 계열 프로토콜로 SQLite를 복제해 왔고, 2016년에 이를 Bedrock으로 공개했습니다.
- ActorDB: 액터마다 Raft로 복제되는 SQLite DB를 하나씩 붙이는 Erlang 시스템입니다.
두 시스템 모두 처음 만들어진 환경 밖에서는 널리 쓰이지 못했습니다. rqlite의 의미는 이 아이디어를 누구나 실행할 수 있는 독립형 범용 오픈소스로 만들었다는 데 있습니다.
2017년: 내장형 라이브러리 dqlite
Canonical은 LXD와 이후 MicroK8s에서 etcd를 따로 띄우지 않고 내장형 복제 저장소를 쓰려고 dqlite를 만들었습니다.
- Mark Shuttleworth와 rqlite 개발자가 rqlite를 쓸 수 있을지 논의했지만, 요구사항에 완전히 맞지는 않았다고 해요.
- 처음엔 Go로 시작했다가, 자체 Raft 라이브러리를 포함한 C 구현으로 다시 작성했습니다.
💡 rqlite와 dqlite의 차이 두 프로젝트의 목적은 비슷하지만 배포 형태가 다릅니다.
- dqlite: 제품 안에 넣는 라이브러리
- rqlite: 제품 옆에서 따로 실행하는 서버
2021년: Litestream과 '복구 중심' 접근
2021년 초 Ben Johnson이 Litestream을 공개했습니다. '많은 애플리케이션에는 클러스터가 아니라 머신 한 대와 확실한 복구 수단이면 충분하다'는 생각이었고, 이후 블로그와 콘퍼런스에서 퍼진 "SQLite면 충분하다" 흐름에 큰 영향을 줬습니다.
Litestream과 rqlite는 장애가 난 뒤에 필요한 것이 서로 다릅니다.
| 구분 | Litestream | rqlite | |---|---|---| | 답하는 질문 | 머신이 죽으면 어떻게 복구하지? | 머신이 죽었는데 복원될 때까지 기다릴 수 없다면? | | 클러스터 | 없음 | 있음 | | 수요 | 더 흔함 | 특정 요구가 있는 사용자 |
Fly.io와 LiteFS
- Fly.io는 2022년 Ben Johnson을 채용하고 LiteFS를 출시했습니다.
- LiteFS는 Consul 리스를 이용해 파일시스템 수준에서 SQLite를 복제합니다.
- 복제 SQLite를 사용자가 직접 배포하는 소프트웨어가 아니라 플랫폼 기능으로 만들려는 첫 시도였습니다.
참고로 Litestream은 rqlite v8.0의 SQLite WAL 처리 방식에도 영향을 줬다고 합니다.
2022년: 확장, 포크, 클라우드 서비스
2022년에는 접근 방식이 훨씬 다양해졌습니다.
cr-sqlite: CRDT로 병합하기
- SQLite 확장으로 CRDT를 추가했습니다. 여러 쓰기 주체가 리더 없이 각자 다른 상태로 진행한 뒤 나중에 병합할 수 있습니다.
- AP 계열 설계라서, rqlite의 CP 보장이 오히려 걸림돌이 되는 로컬 우선(local-first) 애플리케이션에 잘 맞습니다.
libSQL과 Turso: SQLite 포크
- SQLite 프로젝트는 외부 기여를 받지 않습니다. ChiselStrike(이후 Turso)는 SQLite가 바꾸지 않을 엔진 내부를 고치고 싶어서 SQLite 자체를 포크해 libSQL을 만들었습니다.
- 이 포크 위에 엣지 복제본을 갖춘 호스팅 서비스를 만들어 벤처 투자를 받았습니다.
- 그리고 2026년, Supabase가 Turso를 인수했습니다.
SQLite Cloud
- Raft로 복제하는 호스팅 SQLite를 제공합니다.
- rqlite의 원래 설계와 가장 가까운 방식을 클라우드 서비스로 감싼 형태라고 볼 수 있습니다.
2022년 이후: 플랫폼이 된 SQLite
- Cloudflare D1: 2022년 Cloudflare가 엣지 네트워크 안에서 SQLite를 서버리스 데이터베이스로 제공하는 D1을 발표했습니다.
- 이후 Durable Objects 내부에도 SQLite 저장소가 들어갔습니다.
Cloudflare나 Turso 같은 서비스는 내부 동작을 몰라도 그냥 사서 쓰는 관리형 복제 SQLite입니다. 이 분야가 '직접 실행하는 것'에서 '구매하는 것'으로까지 넓어진 셈이죠.
12년이 보여준 세 가지 흐름
1. 같은 아이디어를 계속 새로 만든다
SQLite 저장 엔진 바깥에 복제 계층을 얹는 구조는, 요구사항과 프로토콜이 서로 다른 최소 8개 팀이 각자 다시 만들어 왔습니다. 그리고 이 흐름은 지금도 이어지고 있습니다.
2. 설계 공간의 세 가지 축
세 축은 아래 순서대로 등장했습니다.
- 합의 (rqlite, dqlite): 단일 리더 + 강한 일관성 + 클러스터
- 스트리밍 (Litestream): 단일 쓰기 주체 + 저비용 복구, 클러스터 없음
- 병합 (cr-sqlite, 일부 로컬 우선 시스템): 여러 쓰기 주체 + 최종 일관성
어느 방식이 더 좋다기보다 각자 답하는 질문이 다릅니다. 사용자들 사이의 논쟁도 대부분 결국 '어떤 문제를 풀려는가'를 두고 벌어집니다.
3. 자본은 플랫폼으로 간다
- rqlite, dqlite, Litestream은 무료 오픈소스입니다.
- 투자나 인수로 이어진 쪽은 복제 SQLite를 유료 서비스로 만든 프로젝트들이었습니다.
- 이 아이디어는 돈이 되기 전까지 8년 동안 오픈소스로 존재했습니다.
마치며: 어떤 분산 SQLite를 골라야 할까?
간단히 정리해 보면 이렇습니다.
- 머신 한 대로 충분하고 백업·복구만 확실하면 된다 → Litestream
- 장애가 나도 서비스가 멈추면 안 되고 강한 일관성이 필요하다 → rqlite 또는 dqlite(제품 안에 넣어야 한다면)
- 여러 기기에서 오프라인으로 쓰고 나중에 합쳐야 한다 → cr-sqlite
- 운영은 맡기고 관리형 서비스로 쓰고 싶다 → Cloudflare D1, Turso, SQLite Cloud
rqlite는 2014년과 같은 문제를 더 나은 방식으로 풀며 지금도 개발되고 있습니다. 직접 운영하고, 속속들이 이해할 수 있고, 누구에게도 비용을 내지 않는 내결함성 관계형 DB가 필요하다면 여전히 좋은 선택지입니다.