마무리 — SQLite 가 옳은 default 일 때

한 단락 버전

SQLite 가 옳은 default 일 때 = 데이터가 한 머신에 맞고 writer 가 데이터와 co-located 일 때. 그게 2010 년대 'Postgres 가 모든 거에' default 가 시사한 것보다 훨씬 많은 제품 cover. 르네상스가 진짜인 이유 = 데이터 가까이 compute 두는 비용 — edge runtime, single-server deploy, local-first 앱 — 이 항상 거기 있던 기술과 마침내 캐치업.

SQLite 골라:

Writer 한 명 (또는 shard 마다 한 명).
Read 가 한 머신 reach 에 dominated.
배포 단순함 가치 (데몬 X, 포트 X, auth tier X).
Litestream/Turso/per-tenant 패턴으로 필요한 데 replication 추가.
백업이 cp 면.

Postgres (또는 다른 server DB) 골라:

여러 머신의 다중 writer 가 같은 logical 데이터 reach.
세분화된 per-user DB 인증 / row-level security 필요.
빌트인 synchronous replication + 매니지드 failover 필요.
팀 expertise 가 거기 집중 + 배포 스토리 풀림.

Self-reference: 피파가 정확히 위 이유로 SQLite 위 빌드 — writer 한 명 (아빠 머신), 유저 한 명, 배포가 'launchctl kickstart', 백업이 NAS 로 rsync. 르네상스가 기존 'right tool for the job' 에 살 새 generation context 줌. 이 quest 가 그 도구의 engineering 지도.

여기서 계속: local-first 빌드. 진짜 corpus 를 FTS5 로 인덱싱. 진짜 DB 를 Litestream 으로 replicate. 르네상스가 일어나는 이유 = 사람들이 그거 하니까, 읽으니까 X.

Code

다음 갈 곳·text

Quest 후 탐색 가치 있는 local-first frontier:

  Litestream / LiteFS  — 평범한 SQLite 위 replication
  Turso / libSQL       — 분산 SQLite-as-a-service
  Cloudflare D1        — Workers runtime 안 SQLite
  rqlite / dqlite      — Raft-replicated SQLite
  Inertia / TinyBase   — SQLite 백 local-first frontend state store
  Datasette            — 어떤 SQLite 파일 위에서도 즉각 API + UI

Ben Johnson, Simon Willison, SQLite docs 자체 (www.sqlite.org/changes.html
이 완전 history 유지) 읽기.

마무리 — SQLite 가 옳은 default 일 때

한 단락 버전

Code

External links

Exercise

Progress

댓글 0