SQLite가 잘 맞는 상황
SQLite가 잘 맞는 상황 (내장 DB로서의 위치)
SQLite는 MySQL·Oracle·PostgreSQL·SQL Server 같은 클라이언트/서버 데이터베이스와 직접 비교하기 어려워요. 둘은 풀려고 하는 문제가 다르기 때문이에요. 클라이언트/서버 엔진은 기업 데이터의 공유 저장소를 지향하며 확장성·동시성·중앙화·통제를 강조해요. 반면 SQLite는 개별 애플리케이션과 기기의 로컬 데이터 저장을 지향하고, 경제성·효율성·신뢰성·독립성·단순함을 강조해요. 그래서 SQLite가 경쟁하는 대상은 사실 fopen() 같은 파일 입출력이에요.
SQLite가 잘 맞는 상황
- 임베디드 기기와 사물인터넷(IoT): SQLite 데이터베이스는 관리가 필요 없어서 전문가의 지원 없이 동작해야 하는 기기에 잘 맞아요. 휴대폰, 셋톱박스, TV, 게임기, 카메라, 시계, 주방 가전, 온도조절기, 자동차, 공작기계, 비행기, 원격 센서, 드론, 의료기기, 로봇 등 "사물인터넷" 전체가 해당돼요. 클라이언트/서버 엔진은 네트워크 중심의 잘 관리되는 데이터센터에 살도록 설계됐지만, SQLite는 네트워크 끝단(edge)에서도 스스로 알아서 빠르고 안정적인 데이터 서비스를 제공해요.
- 애플리케이션 파일 형식: SQLite는 버전 관리, 금융 분석 도구, 미디어 카탈로그, CAD 패키지, 기록 관리 프로그램 같은 데스크톱 애플리케이션의 디스크 파일 형식으로 자주 쓰여요. 전통적인 File/Open은
sqlite3_open()으로 데이터베이스 파일을 여는 방식이고, 내용이 갱신되면 자동으로 저장돼서 File/Save 메뉴가 불필요해질 정도예요. File/Save As는 백업 API로 구현할 수 있어요. - 웹사이트: SQLite는 대부분의 저
중 트래픽 웹사이트(즉 대부분의 웹사이트)의 데이터베이스로 훌륭해요. 하루 100K 히트 미만인 사이트는 대개 문제없이 동작한다고 보면 되고, 이 수치는 보수적 추정이지 상한이 아니에요. 실제로 10배 트래픽까지도 동작이 확인됐어요. SQLite 웹사이트 자체도 SQLite로 돌면서 하루 약 40만50만 HTTP 요청을 처리해요. - 데이터 분석: SQL을 아는 사람은
sqlite3커맨드라인 셸로 대용량 데이터셋을 분석할 수 있어요. CSV 파일에서 원시 데이터를 가져와 원하는 대로 자르고 합쳐 다양한 요약 보고서를 만들죠. 더 복잡한 분석은 Tcl이나 Python(둘 다 SQLite 내장), R 등의 스크립트로 할 수 있어요. 웹 로그 분석, 스포츠 통계 분석, 실험 결과 분석 등에 두루 쓰여요. - 엔터프라이즈 데이터 캐시: 많은 애플리케이션이 엔터프라이즈 RDBMS 콘텐츠의 캐시로 SQLite를 써요. 대부분의 쿼리가 로컬 캐시에서 이뤄져 네트워크 왕복을 줄여 지연을 낮추고, 네트워크와 중앙 DB의 부하를 덜어주며, 네트워크 장애 중에도 클라이언트가 계속 동작하게 해줘요.
- 서버사이드 데이터베이스: 데이터센터의 서버 애플리케이션에서 특정 애플리케이션 전용 저장 엔진으로 SQLite를 쓰는 사례도 성공적이에요. 전체적으로는 여전히 클라이언트/서버 구조지만, 클라이언트가 원시 SQL 대신 고수준의 애플리케이션 전용 요청을 보내고 서버가 그걸 여러 SQL로 변환해 처리하는 방식이에요. 이 시나리오에서는 SQLite가 클라이언트/서버 엔진보다 오히려 빠른 경우가 많다고 해요. "샤딩"(사용자별로 별도 SQLite 파일)으로 동시성을 높이기도 해요.
- 데이터 전송 형식: SQLite 데이터베이스는 하나의 작고 잘 정의된 크로스플랫폼 파일이라, 한 시스템에서 다른 시스템으로 콘텐츠를 옮기는 컨테이너로 자주 쓰여요. 수신자는 전체를 한 번에 파싱하지 않고 필요한 만큼 SQL로 조회할 수 있어요.
- 파일 아카이브/데이터 컨테이너: SQLite Archive(SQLAR)는 ZIP이나 Tarball을 대체하는 아이디어예요. SQLite에 저장된 파일 아카이브는 ZIP과 크기가 거의 같거나 오히려 작을 수 있고, 증분·원자적 갱신과 더 풍부한 메타데이터를 지원해요. 3.22.0 이후
sqlite3.exe셸은.archive명령으로 SQL 아카이브를 만들고 풀 수 있어요. - 임시(ad hoc) 디스크 파일 대체: 많은 프로그램이
fopen()·fread()·fwrite()로 자체 형식의 데이터 파일을 만들고 관리해요. SQLite는 이런 임시 데이터 파일의 대체재로 특히 잘 맞아요. 직관과 달리 디스크 읽기·쓰기에서 파일시스템보다 SQLite가 더 빠를 수 있어요. - 내부/임시 데이터베이스: 많은 데이터를 다양한 방식으로 정렬·선별해야 하는 프로그램에서, 데이터를 메모리 내 SQLite 데이터베이스에 로드해 조인과
ORDER BY를 쓰는 게 같은 작업을 직접 코딩하는 것보다 쉽고 빠른 경우가 많아요. 새 컬럼·인덱스를 추가할 때도 모든 쿼리를 다시 코딩하지 않아도 돼서 유연해요. - 데모나 테스트에서 엔터프라이즈 DB 대역: 클라이언트 애플리케이션이 여러 SQL 엔진을 지원하는 범용 인터페이스를 쓴다면, 지원 DB 목록에 SQLite를 포함하고 엔진을 정적으로 링크해 두는 게 좋아요. 그러면 SQLite 데이터 파일만으로 테스트·데모를 위해 단독 실행할 수 있어요.
- 교육과 훈련: 설치는 단순히
sqlite3(또는sqlite3.exe) 실행 파일을 복사하면 끝이라, SQL을 가르치기에 좋은 엔진이에요. 학생이 마음껏 데이터베이스를 만들고 강사에게 이메일로 보내 채점받을 수도 있어요. - 실험적 SQL 확장: 단순하고 모듈화된 설계 덕분에 SQLite는 새롭고 실험적인 데이터베이스 언어 기능을 프로토타이핑하기 좋은 플랫폼이에요.
클라이언트/서버 RDBMS가 더 나은 상황
- 클라이언트/서버 애플리케이션: 데이터가 애플리케이션과 네트워크로 분리되어 있다면 클라이언트/서버가 낫다는 체크리스트 원칙과 이어져요.
- 매우 큰 데이터셋: SQLite 데이터베이스는 281TB(256TiB)로 제한돼요. 게다가 모든 데이터를 단일 디스크 파일에 저장하므로 파일시스템의 파일 크기 제한에도 걸려요. 이런 규모를 염두에 둔다면 여러 파일(어쩌면 여러 볼륨)에 분산하는 클라이언트/서버 엔진을 고려하는 게 좋아요.
- 높은 동시성: SQLite는 읽는 쪽은 무제한 동시 지원하지만 쓰는 쪽은 어느 순간에 하나만 허용해요. 대부분의 상황에서는 문제가 되지 않아요. 쓰기가 큐에 쌓여 순서대로 처리되고 각 잠금은 수십 밀리초를 넘지 않기 때문이에요. 하지만 더 많은 동시성을 요구하는 애플리케이션은 다른 해결책을 찾아야 할 수 있어요.
데이터베이스 엔진 선택 체크리스트
- 데이터가 애플리케이션과 네트워크로 분리되어 있나요? → 클라이언트/서버를 선택하세요. 데이터가 별도 기기에 있으면 고대역폭의 엔진-디스크 링크가 네트워크를 건너야 해서 비효율적이에요.
- 동시에 쓰는 쪽이 많나요? → 클라이언트/서버를 선택하세요. 한 데이터베이스 파일에 SQLite는 한 번에 하나의 쓰기만 허용하지만, 보통 쓰기 트랜잭션은 수 밀리초라 여러 작성자가 차례로 번갈아 쓸 수 있어요. 그래도 긴 실행 서버가 있는 클라이언트/서버가 훨씬 많은 쓰기 동시성을 처리할 수 있어요.
- 빅데이터인가요? → 클라이언트/서버를 선택하세요. 데이터가 단일 디스크 파일 하나에 안 들어갈 크기가 되거나 테라바이트에 육박한다면 중앙 클라이언트/서버 데이터베이스를 고려하세요.
- 그 외에는 → SQLite를 선택하세요! 기기 로컬 저장에 쓰기 동시성이 낮고 콘텐츠가 1TB 미만이라면 SQLite가 거의 언제나 더 나은 선택이에요. 빠르고 안정적이며 설정·유지보수가 필요 없어요.