사실 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은 저는 서버사이드 SQLite에 올인합니다라는 글을 썼습니다.
Litestream으로 SQLite의 변경 내용을 외부 스토리지에 계속 백업하면, 애플리케이션과 DB를 같은 서버에 두면서도 서버 장애에 대비할 수 있다는 이야기였습니다.
LiteFS는 파일 시스템 계층에서 SQLite DB를 다른 머신으로 복제하는 방향으로 이어졌습니다.
데이터를 애플리케이션 가까이에 두고 읽되, 쓰기는 정해진 노드에서 처리하는 구조입니다.
이 시기에 채워지기 시작한 것은 새로운 SQL 문법보다 백업, 복제, 복구 같은 운영 도구였습니다.
애플리케이션 가까이에 DB를 두면서도, 데이터를 다른 곳에 보관하고 여러 머신에서 활용할 수 있는 선택지가 늘어난 것입니다.
물론 이 도구들이 보장하는 범위는 다릅니다.
백업이 있다고 다른 서버가 즉시 쓰기를 이어받는 것은 아니고, 읽기 복제본이 있다고 어디서나 최신 데이터를 읽을 수 있는 것도 아닙니다.
SQLite의 제약을 한꺼번에 없애기보다, 서비스에 필요한 기능을 보완하는 방법이 늘어났다고 보는 편이 맞습니다.
단일 서버에서는 이미 충분히 실용적입니다
SQLite는 애플리케이션 프로세스 안에서 함수 호출로 쿼리를 실행합니다.
다른 DB 서버로 요청을 보내고 응답을 기다리는 과정이 없습니다.
데이터와 애플리케이션을 같은 머신에 둘 수 있다면, 네트워크 왕복과 별도 서버 운영에 드는 비용을 줄일 수 있습니다.
당신이 아마도 SQLite를 사용해야 하는 이유는 이 차이가 쿼리 작성 방식에도 영향을 준다고 이야기합니다.
서버 DB에서 흔히 피하라고 하는 N+1 쿼리도 네트워크 왕복이 없어지면 비용이 달라집니다.
쿼리 자체의 비용은 남지만, 매번 네트워크를 건너야 한다는 전제가 사라지는 것입니다.
실제 서비스의 전환 사례도 있습니다.
lobste.rs는 MariaDB에서 SQLite로 전환하는 과정에서 성능 문제로 한 차례 롤백했지만, 쿼리를 개선한 뒤 다시 전환했습니다.
2026년 7월 운영진은 CPU와 메모리 사용량이 줄었고, 별도 MariaDB 서버를 없애면 서버 비용도 낮출 수 있다고 전했습니다.
전환 이후에도 데이터 복구 작업 뒤에 성능 문제가 생겨 추가 조사와 개선을 거쳤습니다.
운영 중 쿼리를 조정해야 하는 일은 남았지만, 실제 서비스의 부하를 더 단순한 구성으로 감당할 수 있었다는 사례입니다.
Julia Evans가 같은 달에 적은 SQLite를 운영하며 새롭게 배운 몇 가지는 그 과정에서 어떤 운영 지식이 필요한지 보여줍니다.
4천 행을 대상으로 한 FTS5 검색에 5초가 걸렸는데, ANALYZE로 통계 정보를 갱신하자 약 0.05초로 줄었습니다.
대량 삭제에서는 작업이 길어지는 동안 다른 쓰기가 대기하다 시간 초과됐고, 정리 작업을 작은 배치로 나눠 대응했습니다.
작은 DB에서도 쿼리 플랜과 쓰기 잠금을 알아야 했던 것입니다.
DB 서버를 없애도 DB 운영 지식까지 없어지지는 않습니다.
다만 별도 서버의 설치와 연결, 자원 관리를 덜어내는 것만으로도 단일 서버에서 운영하는 서비스에는 충분히 매력적인 선택이 될 수 있습니다.
서버 하나에서 잘 쓰는 것과, DB를 많이 쓰는 것은 다른 이야기입니다
여기까지는 SQLite를 서비스의 주 DB로 쓰고, 장애에도 대비하는 이야기입니다.
그런데 SQLite의 활용은 DB 하나를 안정적으로 운영하는 데서 끝나지 않습니다.
최근에는 서비스 전체의 데이터를 어떤 단위로 나눠 담을지에도 SQLite의 가벼운 구조를 활용하고 있습니다.
서로 독립적인 데이터를 처음부터 다른 DB에 두고, 사용자나 테넌트, 프로젝트마다 작은 DB를 하나씩 제공하는 것입니다.
2025년의 SQLite-on-the-Server에 대한 오해는 SQLite를 작은 서비스용 DB로만 보면 왜 부족한지 설명합니다.
전체 서비스가 크더라도, 각각의 DB가 감당해야 할 범위는 작을 수 있기 때문입니다.
이 방식은 플랫폼에서도 제공됩니다.
Cloudflare Durable Objects의 SQLite 기반 저장소에서는 객체마다 독립된 DB를 사용합니다.
애플리케이션이 큰 DB 하나를 나눠 쓰는 대신, 작업 단위마다 데이터와 실행 코드를 함께 두는 구조입니다.
애플리케이션 가까이에 데이터를 둔다는 SQLite의 장점을, 작업 단위별로 활용하는 셈이죠.
SQLite에는 DB 하나에 한 번에 하나의 쓰기 작업만 진행할 수 있다는 제약이 있습니다.
하지만 서로 관계없는 사용자까지 같은 파일에 쓰게 할 필요는 없습니다.
DB를 나누면 각 DB의 쓰기는 별도로 진행할 수 있습니다.
단일 writer라는 제약이 사라지는 것은 아닙니다.
그 제약을 공유해야 하는 범위를 작게 만드는 것입니다.
Poke는 사이트마다 DB를 하나씩 만듭니다
Turso는 SQLite를 Rust로 재구현한 호환 DB 엔진과, 작은 DB를 대량으로 운영하는 클라우드 서비스를 만드는 회사입니다.
개발자가 API로 DB를 필요할 때마다 생성하고 원격으로 사용할 수 있어, 사용자나 프로젝트별로 DB를 나누는 구성을 만들기 쉽습니다.
앞에서 소개한 Poke는 Turso의 클라우드 서비스를 AI가 생성한 웹사이트에 활용했습니다.
핵심 계정과 에이전트 상태, 내부 운영 데이터는 기존 PlanetScale에 남겨두고, 새로 생성한 사이트마다 별도의 Turso DB를 붙입니다.
각 사이트가 Vercel에 배포될 때 DB 접속 URL도 환경변수로 전달됩니다.
AI가 만든 사이트에는 비효율적인 SQL이 들어갈 수도 있고, 공개된 뒤 갑자기 트래픽이 몰릴 수도 있습니다.
Poke는 이런 사이트들이 하나의 공유 DB를 사용하며 서로 영향을 주는 상황을 피하려 했습니다.
비용도 중요합니다.
잠깐 쓰고 방치되는 사이트마다 DB 서버를 계속 실행해 두기는 어렵습니다.
Turso의 서버리스 비용 구조에서는 유휴 DB를 유지하는 부담도 낮습니다.
이 사례에서 흥미로운 것은 DB 개수만이 아닙니다.
웹사이트를 하나 만드는 과정에 DB 생성이 자연스럽게 포함됐다는 점입니다.
사용자는 문자로 사이트를 요청할 뿐, DB를 따로 설치하거나 설정하지 않습니다.
DB를 나누는 것만으로 성능과 보안이 완전히 격리되지는 않습니다.
공유 자원에 대한 제한과 DB별 접근 권한도 필요합니다.
작은 DB를 생성하는 데서 끝나지 않고, 이런 운영까지 제공하는 플랫폼의 역할도 중요합니다.
데이터를 나누지 않는 편이 나을 때도 있습니다
공유 테이블에서는 보통 user_id나 tenant_id로 사용자의 데이터를 구분합니다.
사이트별 DB에서는 먼저 올바른 DB를 선택하고, 그 안의 데이터만 다룹니다.
격리 기준을 테이블 안의 조건뿐 아니라 DB 경계 자체에 둘 수 있는 것입니다.
한 사용자의 데이터를 따로 옮기거나 복원하기는 쉬워질 수 있습니다.
반대로 같은 앱을 사용하는 수천 개 DB의 스키마를 바꾸고, 백업과 삭제를 관리하는 일은 새로 생깁니다.
전체 사용자의 데이터를 한꺼번에 검색하거나 집계하는 일도 더 번거로워질 수 있습니다.
이처럼 데이터를 나눈 뒤에도 계속 함께 처리해야 한다면, Postgres 같은 중앙 DB가 더 편할 수 있습니다.
- 여러 애플리케이션에서 같은 데이터를 자주 갱신할 때
- 사용자나 테넌트를 가로지르는 조인과 집계가 핵심 기능일 때
- 서로 다른 소유자의 데이터를 하나의 트랜잭션으로 자주 변경해야 할 때
SQLite도 트랜잭션을 지원합니다.
문제는 트랜잭션의 유무보다 함께 바뀌어야 하는 데이터를 서로 다른 DB로 나눴는지에 있습니다.
기능 하나를 처리할 때마다 여러 DB를 오가야 한다면, 나눈 경계부터 다시 살펴봐야 합니다.
Poke도 시스템 전체를 하나의 방식으로 통일하지 않았습니다.
공유해야 하는 핵심 상태는 중앙 DB에 두고, 독립적으로 운영할 수 있는 생성 사이트만 별도 DB로 나눴습니다.
원래 함께 바뀔 필요가 없는 데이터를 나눌 때 작은 DB를 많이 쓰는 장점이 살아납니다.
Postgres 중심의 Supabase는 왜 Turso를 인수할까요
이런 흐름에서 Supabase의 Turso 인수 발표는 눈여겨볼 만합니다.
Postgres를 중심으로 앱 백엔드를 제공하던 회사가 SQLite 쪽 기술과 서비스를 함께 가져가기로 한 것입니다.
Supabase는 오픈소스 Firebase 대체제로 출발한 앱 백엔드 플랫폼입니다.
Postgres DB에 인증과 회원 관리, 파일 저장, 실시간 데이터 갱신, 서버 함수 등을 함께 제공합니다.
앱 화면을 만든 뒤 실제로 사용자가 로그인하고 데이터를 저장할 수 있도록, 뒤에서 필요한 기능을 묶어주는 서비스입니다.
Supabase는 인수 발표에서 이미 매주 100만 개 이상의 DB를 생성하고 있다고 밝혔습니다.
에이전트가 앱과 프로토타입을 더 많이 만들수록, 작은 작업마다 전용 머신을 준비하는 방식으로는 부담이 커진다는 것입니다.
목표로 내세운 것은 파일을 만들듯 쉽고 비용 부담 없이 DB를 생성하는 환경입니다.
예를 들어 AI에게 동호회 출석 앱을 만들어 달라고 했다고 해보죠.
화면은 금방 만들 수 있어도, 회원 로그인과 출석 기록 저장은 필요합니다.
몇 명만 쓰는 앱이라고 이런 기능까지 없어지는 것은 아닙니다.
앞으로 Turso의 가벼운 DB가 Supabase의 인증과 스토리지 등에 잘 연결된다면, 작은 앱도 익숙한 백엔드 기능을 쓰면서 운영 부담을 줄일 여지가 있습니다.
한 가지 아이디어만 고르는 대신 여러 앱을 만들어 시험하고, 실제로 쓰이는 앱을 남기기도 쉬워질 수 있겠죠.
Supabase가 발표한 방향은 작은 작업을 SQLite로 시작하고, 필요해지면 Postgres와 더 넓은 Supabase 생태계로 이어지는 개발 경험을 만들겠다는 것입니다.
기존 Supabase는 Postgres 중심으로, Turso는 SQLite 개발과 서비스 운영을 계속합니다.
SQLite에서 Postgres로 자동 전환하는 기능이 이번에 출시됐다는 뜻은 아닙니다.
또한 앱이 커지면 반드시 SQLite를 떠나야 한다는 뜻으로 볼 필요도 없습니다.
앞에서 본 것처럼, 규모보다 데이터가 함께 바뀌어야 하는 범위와 접근 방식이 중요하기 때문입니다.
이번 인수는 Postgres와 SQLite 중 하나를 고르는 문제에서, 작게 시작한 앱에 필요한 백엔드를 어떻게 제공하고 다음 단계까지 이어갈지로 관심이 넓어지는 움직임으로 읽힙니다.
AI로 작은 프로그램을 많이 만드는 시대에는 어떨까요
SQLite를 검토할 때 전체 트래픽만큼 중요한 질문이 있습니다.
누가 같은 데이터를 함께 읽고, 동시에 바꿔야 할까요?
데이터의 소유자가 분명하고 대부분의 작업이 그 안에서 끝난다면, 서비스가 커져도 모든 쓰기를 한 DB에 모을 필요는 없습니다.
AI로 프로그램을 만드는 일이 쉬워지면서 이런 구조가 어울리는 곳도 많아지고 있습니다.
예전 같으면 굳이 개발하지 않았을 도구도 직접 만들게 됩니다.
나만 쓰는 업무 도구, 팀에서 잠깐 사용할 웹앱, 특정 작업을 수행하는 에이전트처럼 작고 목적이 분명한 프로그램들입니다.
이때 프로그램을 만드는 것보다 DB를 준비하고 계속 운영하는 일이 더 번거롭다면, 빠르게 만들 수 있다는 장점도 줄어듭니다.
필요할 때 바로 붙이고, 사용하지 않을 때는 유지 부담이 작은 DB가 이런 환경에 잘 어울립니다.
Poke는 이미 사이트를 만드는 과정에 DB 생성을 포함했습니다.
Supabase와 Turso는 그 작은 DB를 앱 백엔드와 연결하고, 필요할 때 더 큰 서비스로 이어갈 경로를 만들려 합니다.
프로그램을 쉽게 만드는 변화에 맞춰, 그 프로그램의 데이터를 다루는 방식도 바뀌고 있는 것입니다.
중요한 데이터를 다룬다면 권한과 백업, 복구는 여전히 챙겨야 합니다.
다만 모든 작은 프로그램이 하나의 큰 공유 DB에 들어가거나, 별도 DB 서버를 운영하는 방식으로 시작할 필요는 없습니다.
SQLite는 작은 프로그램에 어울리는 DB였고, 이제는 그런 프로그램을 수없이 만들어내는 환경에서도 장점이 드러나고 있습니다.
코딩 에이전트로 개인용 도구나 작은 웹앱을 만들고 계시다면, SQLite도 한번 고려해보시면 좋겠습니다.
익숙한 서버 DB부터 준비하기 전에, 이 프로그램에 필요한 데이터를 가까이에 가볍게 두는 것으로 충분하지 않을지 살펴보는 거죠.