SQLite에서 Postgres로 옮기기 전에 먼저 본 차이

왜 바로 마이그레이션하지 않았나

작은 서비스를 만들 때 SQLite로 시작하면 편하다. 파일 하나로 끝나고 로컬 개발도 빠르다. 그런데 배포 서버에서 쓰기 요청이 늘어나자 백업, 동시성, 접속 관리가 신경 쓰이기 시작했다.

처음에는 "Postgres로 바꾸면 더 안정적이겠지"라고 생각했지만, 바로 옮기기 전에 차이를 적어 보니 코드 수정 외에도 볼 게 많았다.

비교해 본 기준

기준	SQLite	Postgres
실행 방식	앱 근처의 파일	별도 서버 프로세스
백업	파일 복사 중심	dump 또는 관리형 백업
동시 쓰기	작을 때는 단순	여러 연결 처리에 유리
배포	파일 경로가 중요	연결 문자열과 권한이 중요

여기서 내가 가장 헷갈린 부분은 성능보다 운영 방식이었다. SQLite는 파일 위치와 권한이 중요했고, Postgres는 네트워크 접속과 계정 권한이 중요했다.

옮기기 전에 찍어 본 정보

현재 DB 크기와 테이블 목록부터 확인했다.

sqlite3 app.db '.tables'
sqlite3 app.db 'select count(*) from posts;'
du -h app.db

Postgres 쪽은 접속 문자열을 앱에 넣기 전에 터미널에서 먼저 연결했다.

psql "$DATABASE_URL" -c '\dt'
psql "$DATABASE_URL" -c 'select now();'

이 두 단계만 해도 "코드가 문제인지, DB 접속이 문제인지"를 꽤 빨리 나눌 수 있었다.

코드에서 조심한 부분

SQL 문법은 대부분 비슷해 보여도 타입과 기본값에서 차이가 났다. 특히 날짜 저장 방식과 불리언 값, 자동 증가 ID를 확인했다.

• 날짜를 문자열로 저장할지 timestamp로 저장할지 정한다.
• 개발 DB와 운영 DB의 마이그레이션 순서를 맞춘다.
• 연결 풀을 너무 크게 잡지 않는다.
• 실패하면 되돌릴 수 있게 SQLite 원본을 보관한다.

내 결론

사용자가 적고 서버도 하나라면 SQLite가 나쁜 선택은 아니었다. 다만 운영 중에 백업과 동시 접속을 직접 챙기기 버거워지는 순간이 오면 Postgres가 편해진다. 나는 "더 멋진 DB"가 아니라 "복구와 운영이 덜 불안한 구조"를 기준으로 옮길지 결정하는 게 맞다고 느꼈다.