Database

SQLite를 프로덕션에서 쓴다는 말을 꺼내면 종종 이런 반응이 돌아옵니다. "그거 테스트용 아닌가요?" 2026년 현재, 이 인식은 현실과 상당히 멀어져 있습니다. SQLite는 전 세계에서 가장 많이 배포된 데이터베이스 엔진이고, Android 기기, iOS 앱, 브라우저의 Web Storage, 항공기 시스템까지 광범위하게 쓰입니다.

MongoDB의 모든 인덱스 구조는 B-tree(정확히는 B+-tree)를 기반으로 합니다. MongoDB 공식 인덱스 문서에서는 기본 인덱스 타입을 "B-tree data structure"로 명시하고 있습니다. B+-tree에서 리프 노드는 실제 인덱스 키와 함께 도큐먼트의 위치 정보인 RecordId 를 보관합니다.

PostgreSQL에서 테이블이 수천만 행을 넘어가면 단순 인덱스 추가만으로 해결되지 않는 문제가 생깁니다. 최근 7일 데이터만 자주 보는데도 인덱스와 통계는 전체 테이블 크기의 영향을 받고, 오래된 데이터를 삭제하려면 VACUUM이 길게 돌고, 월말 집계 배치가 실행 계획을 흔듭니다.

설 연휴 직전이었습니다. 평소 새벽 1시에 시작해 1시간 안에 끝나던 정산 배치가 그날따라 2시가 넘어도 돌아가고 있었습니다. PagerDuty 알럿이 울렸고, 슬랙에는 SRE 온콜 담당자의 메시지가 쏟아졌습니다. 필자의 경험으로는 급하게 접속해 APM 대시보드를 열었습니다.

데이터베이스 테이블은 책의 본문과 같습니다. 인덱스는 책의 맨 뒤에 있는 '색인' 입니다. 특정 단어를 찾고 싶을 때 책을 첫 페이지부터 한 장씩 넘기며 찾는 것(Full Table Scan)과, 색인에서 단어를 찾아 페이지 번호로 바로 이동하는 것(Index Seek)의 속도 차이는 데이터가 많을수록 어마어마해집니다.

애플리케이션 코드는 잘못 배포해도 이전 버전으로 되돌릴 수 있습니다. 하지만 데이터베이스 스키마 변경은 되돌리기 어렵습니다. 컬럼을 삭제했는데 이전 버전 서버가 아직 그 컬럼을 읽고 있다면 즉시 장애가 납니다. 타입을 바꿨는데 오래 떠 있는 워커가 예전 형식으로 쓰기를 계속하면 데이터가 섞입니다.