SQLite vs PostgreSQL, 사이드 프로젝트엔 뭐 쓸까

저도 새 프로젝트를 시작할 때마다 매번 같은 자리에서 멈칫합니다. "이번엔 그냥 SQLite로 빨리 갈까, 아니면 처음부터 PostgreSQL을 깔아둘까."

둘 다 써본 입장에서 솔직히 말하면, 정답은 없고 상황별 정답만 있습니다. 다만 "사이드 프로젝트"라는 맥락에서는 꽤 명확한 기준이 생깁니다.

이 글은 데이터베이스를 한두 번 만져본 분, ORM(Object-Relational Mapping, 데이터베이스를 코드처럼 다루게 해주는 도구) 정도는 들어본 분을 기준으로 썼습니다. 처음 듣는 용어는 그때그때 풀어드립니다.

두 데이터베이스 한눈에 보기

SQLite는 파일 하나로 동작하는 내장형 데이터베이스이고, PostgreSQL은 별도 서버로 돌아가는 본격적인 관계형 데이터베이스입니다.

이 한 줄에 거의 모든 차이가 압축돼 있습니다. SQLite는 mydb.sqlite 같은 파일이 곧 데이터베이스입니다. 앱이 그 파일을 직접 열어 읽고 씁니다.

반면 PostgreSQL은 컴퓨터 안에서 별도의 프로그램(서버)이 항상 켜져 있고, 앱은 네트워크로 그 서버에게 "이거 저장해줘"라고 부탁하는 구조입니다.

항목	SQLite	PostgreSQL
형태	파일 하나	별도 서버 프로세스
설치	사실상 불필요	별도 설치·실행 필요
동시 쓰기	1명씩 (짧은 락)	수백~수천 동시 가능
데이터 타입	느슨함	엄격하고 풍부함
백업	파일 복사	전용 도구(pg_dump 등)
운영 난이도	매우 낮음	중간 이상

공식 문서 기준으로 SQLite는 세계에서 가장 많이 배포된 DB입니다. 스마트폰, 브라우저, 비행기 블랙박스에까지 들어가 있습니다. "장난감"이 절대 아닙니다.

SQLite가 잘 맞는 경우

쓰기 동시성이 낮고, 배포를 단순하게 가져가고 싶을 때 SQLite가 압도적으로 편합니다.

제가 최근 만든 개인용 가계부 웹앱은 SQLite로 끝까지 갔습니다. 사용자가 저 한 명이고, 데이터가 몇만 행 수준이라 굳이 PostgreSQL을 띄울 이유가 없었거든요.

이런 시나리오에 잘 어울립니다.

• 1인 또는 소수가 쓰는 도구 (개인 가계부, 독서 기록앱)
• 데이터를 주로 읽고, 가끔 쓰는 블로그·문서 사이트
• 프로토타입·MVP — 일단 빠르게 만들고 검증하는 단계
• 데이터 양이 수십 GB 이하

💡 SQLite 공식 권장에 따르면 데이터베이스 크기 281TB까지, 동시 읽기는 사실상 무제한, 동시 쓰기는 한 번에 1건이 한계입니다.

배포도 단순합니다. 서버에 앱 파일과 SQLite 파일만 올리면 끝입니다. 별도 DB 서버 띄울 필요도, 비밀번호 관리할 필요도 없습니다.

[내 노트북]              [배포 서버]
 app.py        →         app.py
 mydb.sqlite   →         mydb.sqlite
                          (이게 전부)

PostgreSQL 환경에서는 이게 이렇게 바뀝니다.

[배포 서버]
 app.py
   ↓ (네트워크)
 PostgreSQL 서버 프로세스
   ↓
 데이터 파일들

볼 게 두 배입니다. 백업도, 인증도, 포트 설정도 다 따로 챙겨야 합니다.

PostgreSQL이 필요해지는 순간

여러 사람이 동시에 데이터를 쓰거나, 복잡한 데이터 타입·조회가 필요해지면 PostgreSQL로 가야 합니다.

SQLite의 가장 큰 약점은 동시 쓰기입니다. 한 사람이 데이터를 쓰는 동안 다른 사람은 잠깐 기다려야 합니다. 보통은 밀리초 단위라 티가 안 나지만, 트래픽이 늘면 큐가 쌓이기 시작합니다.

대략 이런 신호가 보이면 옮길 때입니다.

• 동시 접속 사용자가 수십 명을 넘어서고 글쓰기가 많음 (채팅, 협업 도구, 댓글)
• JSON 데이터를 통째로 검색·인덱싱하고 싶음
• 위치 데이터(PostGIS), 전문 검색, 배열 같은 고급 타입이 필요함
• 여러 앱 서버가 같은 데이터를 공유해야 함 (수평 확장)
• 실시간 통계 쿼리가 점점 무거워짐

PostgreSQL은 데이터 타입이 훨씬 풍부합니다. SQLite에서 텍스트로 욱여넣던 JSON을 PostgreSQL에서는 jsonb 타입으로 저장하고 그 안의 특정 필드로 인덱스까지 걸 수 있습니다.

예를 들어 사용자가 작성한 설문 응답을 JSON으로 저장한다고 해봅시다. SQLite는 응답 전체를 문자열로 보관해서 "나이가 30 이상인 응답"을 찾으려면 모든 행을 훑어야 합니다. PostgreSQL은 JSON 안의 age 필드에 인덱스를 걸어 즉시 찾아냅니다.

마이그레이션은 정말 쉬운가

"일단 SQLite로 시작하고 나중에 PostgreSQL로 옮기면 된다"는 조언, 절반만 맞습니다.

ORM을 잘 쓰면 코드 변경은 거의 없습니다. Django나 SQLAlchemy 같은 도구는 데이터베이스 종류만 설정에서 바꿔주면 끝나는 경우도 많습니다.

하지만 데이터 이전과 SQL 방언 차이는 따로 입니다. 제가 겪은 함정 몇 가지입니다.

함정	SQLite 동작	PostgreSQL 동작
컬럼 타입	느슨함 (숫자 자리에 문자 들어가도 통과)	엄격 (즉시 에러)
BOOLEAN	0/1 정수	true/false
날짜 비교	문자열로 비교돼도 통과	타입 안 맞으면 에러
자동 증가 ID	INTEGER PRIMARY KEY	SERIAL 또는 IDENTITY
대소문자	보통 무시	엄격하게 구분

SQLite에서 "어떻게든 굴러가던" 데이터가 PostgreSQL로 옮기는 순간 쏟아지는 에러로 드러나는 일이 흔합니다. 이게 꼭 나쁜 건 아닙니다 — PostgreSQL이 잡아준 덕분에 데이터 품질이 올라가니까요. 다만 이 작업에 반나절~하루 정도는 잡아둬야 합니다.

💡 마이그레이션 부담을 줄이고 싶다면, SQLite로 시작하더라도 컬럼 타입을 처음부터 엄격하게 지키고, ORM의 타입 검증 기능을 켜두세요. 나중에 옮길 때 훨씬 수월해집니다.

실제 선택 흐름

선택을 결정하는 가장 확실한 질문은 "동시에 글을 쓰는 사람이 몇 명인가"입니다.

제가 매번 따라가는 의사결정 흐름입니다.

시작
 │
 ├─ 혼자 쓰는 도구다           → SQLite
 │
 ├─ 읽기 위주 사이트다          → SQLite
 │  (블로그, 문서, 포트폴리오)
 │
 ├─ MVP·프로토타입 단계다       → SQLite
 │
 ├─ JSON·위치·전문검색 필요    → PostgreSQL
 │
 ├─ 동시 글쓰기 사용자 50+     → PostgreSQL
 │
 └─ 여러 서버에서 공유 필요    → PostgreSQL

비용 측면도 무시 못 합니다. 클라우드 환경에서 PostgreSQL 관리형 서비스(AWS RDS, Supabase 등)는 글 작성 시점 기준 가장 저렴한 등급도 월 1만 원대부터 시작합니다. SQLite는 앱 서버에 얹혀가니 추가 비용이 0원입니다.

반대로 트래픽이 본격적으로 붙기 시작하면 SQLite는 빠른 SSD가 달린 서버에 묶이게 되고, 결국 확장성에서 PostgreSQL이 다시 유리해집니다.

자주 막히는 부분

처음 PostgreSQL을 셋업할 때 거의 모두가 같은 자리에서 막힙니다.

1. 비밀번호 인증 에러

설치 직후 psql 명령어를 쳤더니 "peer authentication failed"가 뜨는 경우가 많습니다. 이건 PostgreSQL의 기본 인증 방식이 OS 사용자 이름과 DB 사용자 이름이 같아야 통과시키는 방식이라 그렇습니다. pg_hba.conf 파일에서 peer를 md5나 scram-sha-256으로 바꿔주면 비밀번호 방식으로 들어갈 수 있습니다.

2. 한글 깨짐

한글이 ?로 보인다면 데이터베이스 인코딩이 UTF-8이 아닐 가능성이 큽니다. CREATE DATABASE mydb ENCODING 'UTF8' LC_COLLATE='C' LC_CTYPE='C'; 형태로 새로 만들면 거의 해결됩니다.

3. SQLite 동시 접근 에러

database is locked 메시지가 뜨면 누군가 쓰는 동안 다른 요청이 들어왔다는 뜻입니다. WAL 모드(PRAGMA journal_mode=WAL;)를 켜면 읽기와 쓰기가 동시에 가능해져서 체감 성능이 크게 올라갑니다. 사이드 프로젝트라면 이거 하나로 대부분 해결됩니다.

4. 백업을 안 한다

가장 자주 보는 실수입니다. SQLite는 파일 하나니까 정기적으로 다른 곳에 복사만 해도 충분합니다. PostgreSQL은 pg_dump mydb > backup.sql 한 줄을 cron(예약 실행 도구)에 걸어두세요. 이 명령은 데이터베이스 전체를 SQL 파일로 떠내라는 뜻입니다.

마무리

저는 요즘 새 프로젝트를 시작할 때 일단 SQLite로 갑니다. WAL 모드만 켜두면 웬만한 개인 프로젝트는 끝까지 무리 없이 굴러갑니다.

PostgreSQL은 "필요해질 때" 옮기면 됩니다. 그 시점은 보통 동시 사용자가 늘거나, JSON·위치 같은 고급 데이터 타입이 필요해질 때입니다.

미리 PostgreSQL을 깔아두는 게 더 "프로답다"고 느껴질 수 있는데, 사이드 프로젝트는 출시되지 않으면 의미가 없습니다. 운영 부담을 줄이고 일단 만드는 데 집중하는 쪽이, 적어도 제 경험상 더 멀리 갔습니다.

다음 프로젝트에서 막히는 지점이 생기면 그때 옮기세요. 그게 가장 적은 비용으로 가는 길입니다.

함께 보면 좋은 글

• sql 입문
• AI에게 SQL 쿼리 짜달라고 잘 부탁하는 법 프롬프트 5선
• Vector DB 5분 정리 — Pinecone·Chroma·Weaviate 차이