- 많은 개발자들이 서버에서 SQLite를 사용하는 것은 소규모 애플리케이션에나 어울린다고 생각
- 그 이유는 다음과 같음:
- 낮은 인프라 비용: 별도의 데이터베이스 서버가 필요하지 않음 (단일 파일로 운영)
- 개발 및 테스트 용이: 동일한 DB 파일을 클라이언트와 서버에서 활용 가능
- 관리 부담 최소화: 복잡한 설정이나 데몬 관리가 불필요
- 높은 신뢰성: SQLite는 전 세계에서 가장 많이 배포된 DB이며, 강력한 내구성을 가짐
- LiteFS, Litestream, rqlite, Dqlite, Bedrock 등의 도구가 SQLite에 복제(replication) 및 고가용성(HA)을 추가하여 소규모 배포에 적합하게 만들어줌
하지만 이 글에서는 소규모가 아닌 초대형 애플리케이션(Hyper-Scale)에 적합한 SQLite의 가능성을 탐구함
기존의 대형 데이터베이스 확장 문제
- 대형 애플리케이션은 보통 PostgreSQL, MySQL을 단일 DB로 유지하기 어려워 샤딩(Sharding)된 데이터베이스를 사용
- 예: Cassandra, ScyllaDB, DynamoDB, Vitess(샤딩된 MySQL), Citus(샤딩된 Postgres)
- 샤딩된 DB는 다음과 같은 장점을 가짐:
- 데이터 파티션을 통해 배치 읽기(Batch Read) 최적화
- 수평적 확장(Scalability) 가능
- 고속 쓰기 성능 제공
하지만 현재의 파티셔닝 솔루션에는 다음과 같은 단점이 존재
- 고정된 스키마(Rigid Schemas): MySQL이나 Postgres처럼 유연한 쿼리를 지원하지 않음
- 스키마 변경이 어려움: 인덱스 추가나 관계 변경 시 운영 부담이 큼
- 복잡한 크로스 파티션 연산: ACID 트랜잭션을 유지하기 어렵고, 두 단계 커밋(2PC) 같은 복잡한 기법 필요
- 데이터 불일치 문제: 파티션 간 강력한 데이터 제약 조건을 적용하기 어렵고, 데이터 정합성이 깨질 가능성이 높음
SQLite 기반 하이퍼스케일 데이터베이스의 가능성
- Cloudflare Durable Objects와 Turso는 SQLite를 기반으로 하이퍼스케일 애플리케이션을 설계하는 방식을 보여줌
- 이들 시스템은 다음과 같은 강점을 제공함:
- 동적 확장(Dynamic Scaling): 엔터티(Entity)별로 데이터베이스를 생성하여 인프라 복잡성을 감소
- 무제한의 저비용 데이터베이스: 기존 샤딩처럼 데이터 파티션을 강제하지 않고, 필요할 때마다 새로운 SQLite 인스턴스를 생성 가능
- 글로벌 분산(Global Distribution): 데이터베이스를 사용자 가까운 위치에 배치하여 성능 향상
- 내장된 복제 및 내구성(Built-in Replication & Durability): 기존 SQLite와 달리 다중 지역에서 데이터를 복제하여 고가용성 유지
- SQLite를 활용한 샤딩 대체 방식 (Cloudflare Durable Objects & Turso 활용)
- 기존 샤딩 방식에서는 단일 데이터베이스 파티션에 여러 채팅 로그 저장
- SQLite를 사용하면 각 채널별로 독립적인 SQLite 데이터베이스를 생성하여 보다 유연한 스키마 활용 가능
- 예제 구조
- 기존 샤딩: 채팅 로그 테이블 + 파티션 키
- SQLite 기반: 채널별 개별 SQLite DB (채팅 로그, 참여자, 반응 정보 포함)
- SQLite를 사용한 이 방식의 장점은 다음과 같음:
- 로컬 ACID 트랜잭션 유지: 크로스 파티션 문제 없이 개별 DB 내에서 트랜잭션 수행 가능
- 고성능 I/O: SQLite는 단일 파일 DB이므로, 읽기 및 쓰기 성능이 매우 뛰어남
- SQL 확장 기능 활용 가능:
- FTS5(Full-Text Search): 검색 성능 향상
- JSON1: JSON 데이터 저장 및 쿼리 지원
- R*Tree, SpatiaLite: 공간 데이터 활용 가능
- SQL 마이그레이션 지원: Prisma, Drizzle 같은 기존 마이그레이션 도구와 호환 가능
- 느린(Lazy) 스키마 마이그레이션 지원:
- 마이그레이션 실행이 즉시 필요하지 않고, SQLite 인스턴스를 열 때 가벼운 마이그레이션을 수행하는 방식 사용 가능
서버에서 SQLite를 사용할 때의 한계점
- 오픈소스, 자체 호스팅 가능한 솔루션 부족
- 크로스 데이터베이스 쿼리 미지원 → 분석을 위해서는 별도의 데이터 레이크 필요
- 제한된 데이터베이스 툴링 (SQL 브라우저, ETL 파이프라인, 모니터링, 백업)
- StarbaseDB가 Cloudflare Durable Objects + SQLite 기반으로 이 문제 해결 중
- 통합된 표준 프로토콜 부족
- PostgreSQL, MySQL, Cassandra는 표준화된 프로토콜을 사용하지만, SQLite 서버는 아직 표준화된 네트워크 프로토콜이 부족
- 하이퍼스케일에서 SQLite를 사용한 대규모 사례 부족
- Cassandra, DynamoDB 같은 사례 연구가 부족하지만, 시간이 지나면서 변화할 가능성이 있음
결론: SQLite는 단순한 로컬 DB가 아닌, 초대형 애플리케이션에서도 강력한 옵션
- SQLite는 단순한 소규모 프로젝트용 DB가 아니라, 초대형 애플리케이션에서도 기존 샤딩 방식을 대체할 수 있는 강력한 도구
- Cloudflare Durable Objects & Turso를 활용하면, 데이터베이스를 엔터티 단위로 분할하여 SQL의 강력한 기능과 ACID 트랜잭션을 유지하면서 확장 가능
- 전통적인 샤딩된 데이터베이스보다 더 유연하고 관리가 쉬운 대안으로 자리 잡을 가능성이 높음
GeekNews Weekly에 포함된 글입니다.
에디터 코멘트 보기
댓글과 토론
Hacker News 의견
-
한 사용자가 SQL로 커스텀 데이터베이스를 교체하려고 고민 중임
- Sqlite3는 단일 서버에서 실행되기 때문에 후보로 고려됨
- 데이터베이스는 주로 읽기 작업이 많아 Sqlite3가 유리함
- 커스텀 데이터베이스는 특정 작업에서 매우 빠르지만 복잡한 결정임
- 벤치마크 테스트를 통해 Sqlite3와 Postgresql을 비교함
- Sqlite3가 모든 작업에서 Postgresql보다 약 두 배 빠름
- 커스텀 데이터베이스는 단일 레코드 접근에서 Sqlite3보다 100~1,000배 빠름
-
한 사용자는 로컬 우선 웹 앱을 개발 중이며 SQLite가 적합하다고 생각함
- SQLite 데이터베이스 상태를 클라우드 서비스로 쉽게 동기화하는 방법을 원함
- Turso와 SQLite Cloud가 유망한 옵션으로 보임
- 사용자가 S3 스토리지로 푸시할 수 있는 간단한 접근법을 고려 중임
-
SQLite-Per-Partition의 이점에 대해 논의함
- 글로벌 테이블이 필요한 상황에서는 한계가 있음
- SQLite를 사용한 다양한 프로젝트 경험을 공유함
-
다중 사용자 환경에서 SQLite는 MVCC 부족으로 인해 어려움을 겪음
- MVCC를 추가하는 sqlite 호환 구현 및 확장에 대해 궁금해함
-
Ruby on Rails의 8.0 릴리스에서 SQLite 지원을 확장함
- 캐시 및 작업 큐 구성 요소를 대체하고 일반적인 웹 앱에 적합하게 만듦
-
Vitess나 Citus에 익숙하지 않은 사용자가 기사 내용을 이해하기 어려워함
- Sharded Sqlite와 Sharded Postgres의 차이점에 대해 궁금해함
-
한 사용자는 VPS 호스팅을 원하지 않아 SQLite를 사용한 웹 페이지를 만듦
- 데이터베이스를 사용자의 장치로 다운로드하여 사용함
-
Ubiquiti 컨트롤러를 설정하는 데 어려움을 겪은 사용자가 SQLite 사용을 제안함
- MongoDB 대신 SQLite를 사용하면 더 나은 경험을 제공할 수 있다고 생각함
-
Apple이 2022년 기준으로 약 300,000개의 Cassandra/ScyllaDB 인스턴스를 운영함
- DB-per-tenant 접근 방식이 더 나은 방향으로 나아가고 있다고 평가함
-
TDLib(텔레그램 데이터베이스 라이브러리)가 SQLite를 사용함
- 각 TDLib 인스턴스가 24,000개 이상의 활성 봇을 동시에 처리함