Database

SQLite가 프로덕션용으로 적합한 워크로드 SQLite를 프로덕션에서 쓴다는 말을 꺼내면 종종 이런 반응이 돌아옵니다. "그거 테스트용 아닌가요?" 2026년 현재, 이 인식은 현실과 상당히 멀어져 있습니다. SQLite는 전 세계에서 가장 많이 배포된 데이터베이스 엔진이고, Android 기기, iO

인덱스가 없으면 느리고, 잘못 만들면 더 느리다 MongoDB를 프로덕션에서 처음 운영해보는 팀은 대개 비슷한 경험을 합니다. 로컬에서는 순식간에 응답하던 쿼리가 실 데이터가 수백만 건을 넘어서면서 갑자기 수 초씩 걸리기 시작하고, "인덱스를 추가하면 되겠지"라는 생각에 db.collection.crea

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

새벽 2시에 울린 알럿: 명절 정산 배치가 멈췄던 그 밤 설 연휴 직전이었습니다. 평소 새벽 1시에 시작해 1시간 안에 끝나던 정산 배치가 그날따라 2시가 넘어도 돌아가고 있었습니다. PagerDuty 알럿이 울렸고, 슬랙에는 SRE 온콜 담당자의 메시지가 쏟아졌습니다. 우리 팀은 급하게 접속해 APM

\n\n백엔드 개발자 면접 단골 질문이자, 서비스 성능 튜닝의 첫 번째 단추인 데이터베이스 인덱싱(Indexing) . 우리는 흔히 "느리면 인덱스 걸어"라고 말하지만, 인덱스가 내부적으로 어떻게 동작하는지, 왜 B Tree를 쓰는지, 많이 걸면 어떤 부작용이 있는지 깊이 있게 이해하는 개발자는 많지 않

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