데이터베이스 PostgreSQL vs MySQL vs SQLite: 사이드 프로젝트 단계별 선택 기준

DB 선택은 기술 취향보다 단계 문제다

사이드 프로젝트에서 데이터베이스 선택은 “무엇이 더 좋은가”보다 “지금 단계에서 무엇이 덜 위험한가”에 가깝습니다. 혼자 만드는 제품은 기능보다 운영 부담이 먼저 병목이 되기 쉽습니다. 백업, 배포, 스키마 변경, 장애 복구, 로컬 개발 환경까지 모두 내가 책임져야 하기 때문입니다.

대체로 기준은 세 가지입니다. 첫째, 지금 필요한 데이터 모델이 단순한가. 둘째, 동시에 쓰는 사용자가 늘어날 가능성이 가까운가. 셋째, 나중에 바꾸기 어려운 기능에 이미 의존하고 있는가. 이 세 가지를 놓고 보면 SQLite, PostgreSQL, MySQL의 위치가 꽤 선명해집니다.

1. 프로토타입: SQLite로 속도를 우선한다

아이디어 검증 단계라면 SQLite가 가장 가볍습니다. 별도 서버 없이 파일 하나로 시작할 수 있고, 로컬 개발과 테스트가 단순합니다. 로그인, 게시글, 간단한 결제 상태, 관리자 메모처럼 데이터 구조가 크지 않은 MVP라면 충분한 경우가 많습니다.

특히 아직 고객이 없고, 스키마가 자주 바뀌며, 배포보다 학습과 검증이 중요한 시기라면 “운영 가능한 최소 복잡도”가 더 중요합니다. 이 단계에서 PostgreSQL 클러스터 설정이나 MySQL 운영 전략을 고민하다 보면 제품 검증보다 인프라가 먼저 커질 수 있습니다.

다만 SQLite를 고를 때는 경계를 알아야 합니다. 동시에 쓰기 작업이 자주 발생하거나, 여러 서버 인스턴스에서 같은 DB 파일을 안정적으로 공유해야 하거나, 복잡한 권한/검색/분석 요구가 빠르게 생긴다면 초기부터 서버형 DB를 고려하는 편이 낫습니다.

2. 초기 출시: PostgreSQL을 기본값으로 두기 좋다

초기 출시 이후 가입자, 결제, 알림, 검색, 관리자 기능이 붙기 시작하면 PostgreSQL이 무난한 기본 선택지가 됩니다. 관계형 모델이 탄탄하고, JSON 컬럼, 인덱스, 전문검색, 트랜잭션 기능이 균형 있게 갖춰져 있어 “지금은 단순하지만 나중에 복잡해질 수 있는” 제품에 잘 맞습니다.

예를 들어 사용자의 설정값은 JSON으로 유연하게 저장하되, 결제 상태나 권한은 정규화된 테이블로 관리할 수 있습니다. 검색도 외부 검색엔진을 붙이기 전까지는 PostgreSQL의 기본 전문검색으로 어느 정도 버틸 수 있습니다. 물론 검색 품질이 핵심 경쟁력인 서비스라면 별도 검색 도구를 검토해야 합니다.

1인 개발자에게 PostgreSQL의 장점은 선택지를 늦출 수 있다는 점입니다. 처음부터 모든 구조를 완벽히 설계하지 않아도, 제품이 조금 복잡해졌을 때 대응할 여지가 비교적 넓습니다.

3. MySQL은 익숙함과 생태계가 강점이다

MySQL은 여전히 많은 서비스와 호스팅 환경에서 익숙한 선택지입니다. 팀이나 외주, 기존 코드베이스, 특정 호스팅이 MySQL을 중심으로 되어 있다면 굳이 PostgreSQL로 바꿀 이유가 없을 수 있습니다. CRUD 중심의 웹 서비스, 커머스성 데이터, 전통적인 백오피스 구조에는 충분히 안정적인 선택입니다.

다만 혼자 새 프로젝트를 시작한다면 “내가 MySQL에 더 익숙한가”, “사용할 플랫폼이 MySQL을 더 잘 지원하는가”, “필요한 기능이 MySQL에서 자연스럽게 풀리는가”를 봐야 합니다. JSON이나 전문검색 같은 기능은 지원 여부만 볼 것이 아니라, 내가 쓰는 ORM, 배포 환경, 백업 방식과 함께 확인해야 합니다.

결국 MySQL은 나쁜 선택이 아니라 맥락형 선택입니다. 이미 익숙하고 운영 경로가 보인다면 강점이 큽니다. 반대로 특별한 이유가 없다면 PostgreSQL을 기본값으로 두는 쪽이 판단 비용을 줄이기 쉽습니다.

4. 요구사항별 빠른 판단표

이 표는 정답표가 아니라 질문표에 가깝습니다. 기능 하나만 보고 고르기보다, 운영 경험과 배포 환경까지 같이 봐야 합니다.

5. 마이그레이션 비용을 줄이는 습관

DB는 언젠가 바뀔 수 있습니다. 그래서 처음부터 “절대 안 바꿀 선택”을 하려 하기보다, 바꿔도 덜 아프게 만드는 습관이 중요합니다.

• ORM이나 쿼리 빌더를 쓰더라도 핵심 쿼리는 DB별 차이를 인식한다.
• JSON 컬럼에 모든 것을 넣지 말고, 검색·정렬·권한 판단에 쓰는 값은 컬럼으로 분리한다.
• 생성일, 수정일, 상태값, 외래키 같은 기본 설계를 초기에 정리한다.
• 마이그레이션 파일을 커밋하고, 운영 DB에 직접 수동 변경하지 않는다.
• 백업과 복구 절차를 출시 전에 한 번은 실제로 확인한다.

특히 SQLite에서 PostgreSQL로 옮길 가능성이 있다면 타입 차이, 날짜 저장 방식, boolean 처리, 자동 증가 ID 전략을 조심해야 합니다. 작은 차이가 나중에 데이터 이전 스크립트의 복잡도로 돌아올 수 있습니다.

6. 1인 빌더를 위한 결론

아직 검증 전이면 SQLite로 빠르게 만드세요. 출시를 준비하고 가입자 데이터와 결제가 들어간다면 PostgreSQL을 우선 검토하세요. MySQL은 기존 경험, 호스팅, 팀 협업 맥락이 있을 때 좋은 선택입니다.

가장 피해야 할 것은 “언젠가 커질 수도 있으니까”라는 이유로 지금 필요 없는 복잡도를 끌어오는 것입니다. 반대로 실제 사용자 데이터가 쌓이기 시작했는데도 백업, 마이그레이션, 동시성 문제를 미루는 것도 위험합니다.

좋은 DB 선택은 화려한 기술 선택이 아니라 다음 한 달의 제품 실험을 막지 않으면서, 다음 여섯 달의 운영 리스크를 너무 키우지 않는 균형입니다.