데이터베이스 6종 선택 가이드
이 토픽을 마치면
프로젝트 규모와 데이터 성격에 따라 어떤 DB를 선택해야 하는지 판단할 수 있습니다.
개인 프로젝트를 시작했는데
게시판을 만들려고 합니다. 구글에 검색하면 MySQL, PostgreSQL, MongoDB, Firebase, Supabase, Redis, CockroachDB... 선택지가 10개가 넘습니다.
뭘 써야 하는지 모르겠어서 일단 제일 많이 보이는 MySQL을 설치합니다. 한참 뒤에 "아 이건 PostgreSQL이 낫겠는데..." 하면서 마이그레이션 지옥이 시작됩니다.
처음에 잘 고르면 이런 일이 없습니다. 핵심 질문은 하나입니다 — "내 데이터는 표 형태인가, 아닌가?"
표 형태 데이터 → SQL (관계형)
사용자, 게시글, 댓글, 주문 — 행과 열로 정리되는 데이터는 관계형 DB가 맞습니다.
사용자 테이블
┌────┬────────┬──────────────────┐
│ id │ name │ email │
├────┼────────┼──────────────────┤
│ 1 │ 철수 │ cs@email.com │
│ 2 │ 영희 │ yh@email.com │
└────┴────────┴──────────────────┘MySQL
가장 많이 쓰이는 관계형 DB. 웹 개발 입문에서 제일 먼저 만납니다. WordPress, 쇼핑몰, 대부분의 웹서비스가 MySQL입니다. 안정적이고 커뮤니티가 크지만, JSON 처리나 고급 기능에서 PostgreSQL에 밀립니다.
PostgreSQL
"고급 MySQL"이라고 생각하면 됩니다. JSON 타입 지원, 전문 검색, 지리 데이터(PostGIS), 배열 타입 — 기능이 훨씬 많습니다. 데이터가 복잡하거나 확장 가능성이 크다면 PostgreSQL이 더 나은 선택입니다. Supabase도 PostgreSQL 기반입니다.
SQLite
설치가 필요 없습니다. 파일 하나가 곧 DB입니다. 서버가 없어서 동시 접속이 많은 웹서비스에는 부적합하지만, 모바일 앱 내장 DB, 프로토타입, 테스트용으로는 최고입니다.
비정형 데이터 → NoSQL
채팅 메시지, IoT 센서 데이터, 사용자 활동 로그 — 구조가 일정하지 않거나 빠르게 변하는 데이터는 NoSQL이 맞습니다.
MongoDB
JSON(BSON) 문서를 그대로 저장합니다. 스키마가 유연해서 필드를 마음대로 추가/삭제할 수 있습니다. 프로토타이핑이 빠르지만, 복잡한 JOIN이 필요한 데이터에는 부적합합니다.
// MongoDB — 문서 하나에 관련 데이터를 다 넣음
{
"_id": "user_001",
"name": "철수",
"posts": [
{ "title": "첫 글", "date": "2026-07-01" },
{ "title": "두번째 글", "date": "2026-07-02" }
]
}Redis
메모리(RAM)에 저장합니다. 디스크가 아니라 메모리라서 읽기/쓰기가 극도로 빠릅니다. 캐시, 세션 저장, 실시간 랭킹에 씁니다. 영구 저장소가 아니라 보조 역할입니다.
BaaS — 서버 없이 DB를
Firebase / Supabase
백엔드 서버를 만들지 않고 프론트엔드에서 바로 DB에 접근합니다. 인증, 실시간 동기화, 파일 저장까지 제공합니다. 1인 개발이나 프로토타입에 적합합니다.
- Firebase → NoSQL (Firestore), 구글 생태계
- Supabase → PostgreSQL, 오픈소스, SQL 지원
선택 치트시트
| 질문 | 추천 |
|---|---|
| 첫 프로젝트, 빨리 만들고 싶다 | Supabase or Firebase |
| 웹서비스, 표 형태 데이터 | PostgreSQL (MySQL도 OK) |
| 데이터 구조가 자주 바뀐다 | MongoDB |
| 캐시/세션/실시간 랭킹 | Redis (+ 메인 DB 별도) |
| 모바일 앱 내장 | SQLite |
| 이미 서비스가 크고 복잡하다 | PostgreSQL |
정답은 없습니다. 하지만 **"일단 모르겠으면 PostgreSQL"**이라는 말이 있을 정도로 PostgreSQL은 범용성이 높습니다.
하나만 쓰라는 법은 없다
실제 서비스에서는 여러 DB를 조합합니다:
PostgreSQL (메인 데이터)
+ Redis (캐시/세션)
+ S3 (파일/이미지)이것을 폴리글랏 퍼시스턴스(Polyglot Persistence)라고 합니다. 각 데이터의 성격에 맞는 DB를 쓰는 것이 가장 효율적입니다. 하지만 처음부터 이렇게 하지 마세요 — 하나로 시작하고, 병목이 생기면 그때 추가하는 게 현실적입니다.
핵심
표 형태 데이터 → SQL (PostgreSQL 추천), 비정형/유연한 데이터 → NoSQL (MongoDB). 빠른 프로토타입 → Supabase/Firebase, 캐시 → Redis, 내장 → SQLite. 모르겠으면 PostgreSQL — 나중에 바꾸는 게 처음부터 잘 고르는 것보다 훨씬 비쌉니다.