한 단락 버전
SQLite가 기본값으로 옳은 조건은 간단해. 데이터가 머신 한 대에 들어가고, writer가 그 데이터와 같은 자리에 있으면 돼. 그런데 이 조건이 커버하는 제품은 2010년대의 'Postgres를 모든 것에'라는 기본값이 암시하던 것보다 훨씬 넓어. 르네상스가 진짜인 이유도 여기 있어. 데이터 가까이에 compute를 두는 비용 — edge runtime, 서버 한 대 배포, local-first 앱 —이 마침내 계속 거기 있던 기술을 따라잡은 거야.
SQLite를 골라야 할 때는 이래.
- writer가 한 명일 때. 쪼갠 단위마다 한 명이어도 좋고.
- read가 머신 한 대가 감당할 범위 안에 있을 때.
- 배포가 단순한 게 값어치가 있을 때. 데몬도 포트도 인증 계층도 없거든.
- replication이 필요한 자리에만 Litestream이나 Turso, tenant별 분리로 얹을 수 있을 때.
- 백업이
cp로 끝날 때.
Postgres나 다른 서버형 DB로 가야 할 때는 이래.
- 여러 머신의 writer가 같은 logical 데이터를 만져야 할 때.
- 유저 단위로 잘게 나눈 DB 인증이나 row-level security가 필요할 때.
- 동기식 replication과 매니지드 장애 조치가 필요할 때.
- 팀의 전문성이 거기 몰려 있고 배포 이야기도 이미 풀려 있을 때.
Self-reference: 피파가 SQLite 위에 세워진 건 정확히 위 이유들 때문이야. writer는 한 명(아빠 머신), 유저도 한 명, 배포는 'launchctl kickstart', 백업은 NAS로 rsync. 르네상스는 예전부터 있던 '일에 맞는 도구를 써라'에 새 세대가 살아갈 맥락을 붙여준 거고, 이 quest는 그 도구의 공학 지도야.
여기서 계속 가려면 이렇게 해. local-first로 뭔가를 만들어. 진짜 말뭉치를 FTS5로 인덱싱해. 진짜 DB를 Litestream으로 복제해. 르네상스가 벌어지는 건 사람들이 실제로 그렇게 하기 때문이야. 읽기만 해서가 아니라.