SQLite의 확장은 더 큰 DB가 아니라 더 많은 DB

사실 Postgres 하나면 대부분의 애플리케이션을 만들 수 있습니다. 여러 사용자가 동시에 데이터를 수정하고, 여러 서버와 도구가 하나의 상태를 공유하는 데 이미 검증된 선택입니다. 저도 특별한 이유가 없다면 Postgres로 시작하는 게 자연스럽다고 생각합니다. 그런데 대부분의 일을 잘한다는 것과, 모든 상황에서 가장 간단한 선택이라는 것은 조금 다릅니다. 사용자마다 작은 데이터를 따로 보관하거나, 잠깐 쓰고 말 프로그램에 DB를 붙이는 일에도 같은 구성이 필요할까요? SQLite는 오랫동안 모바일 앱, 데스크톱 프로그램, 개인용 도구에 포함되는 로컬 DB로 여겨졌습니다. 서버에서도 쓸 수는 있지만, 사람이 많이 몰리지 않는 작은 서비스나 개발 환경에 어울린다는 인식이 강했습니다. 하지만 그동안 긱뉴스에 올라온 SQLite 글들을 이어보면 조금 다른 흐름이 보입니다. 서비스의 주 DB로 사용하고, 다른 머신으로 데이터를 복제하며, 이제는 사용자나 프로젝트마다 별도의 DB를 제공하는 사례까지 나오고 있습니다. iMessage 개인 비서 Poke는 AI가 만든 웹사이트마다 Turso(SQLite 호환 클라우드 DB)를 하나씩 붙여서, 사례 공개 당시 생성한 DB가 약 1만 개에 이르렀습니다. 그리고 2026년 10월 2일에는 Postgres를 중심으로 성장한 Supabase가 Turso 인수를 발표했습니다. SQLite의 현재를 이해하려면 하나의 파일로 얼마나 많은 트래픽을 감당할 수 있는지만 봐서는 안 됩니다. 작은 DB를 얼마나 가볍게 만들고, 필요한 곳마다 제공할 수 있는지도 확장의 기준이 되고 있습니다. SQLite는 언제부터 서버에서 진지한 선택지가 됐을까요 SQLite를 서버에서 쓰자는 이야기가 최근에 갑자기 나온 것은 아닙니다. 2019년 긱뉴스에 소개된 Dqlite는 SQLite에 Raft를 결합해 여러 노드에 데이터를 복제하는 프로젝트였습니다. 2021년에 소개한 rqlite도 SQLite 위에 분산 합의와 HTTP API를 추가했습니다. 이미 그때부터 SQLite를 단일 머신 밖에서 활용하려는 시도가 이어지고 있었던 것입니다. 2022년에는 SQLite를 Primary DB로 사용해보신 분?이라는 질문이 올라왔습니다. 운영 서버의 주 DB로 쓰는 사례가 있었지만, 여전히 경험을 따로 물어볼 만큼 낯선 선택이기도 했습니다. 같은 해 Fly.io에 합류한 Ben Johnson은 저는 서버사이드 S...