데이터베이스는 잘못 선택하면 나중에 바꾸기 매우 어렵습니다. 수백만 건의 데이터를 마이그레이션하는 작업은 며칠이 걸릴 수 있습니다. 처음부터 상황에 맞는 데이터베이스를 선택하는 것이 중요합니다.
관계형 데이터베이스 vs NoSQL
관계형 데이터베이스 (RDBMS)
테이블, 행, 열로 데이터를 구조화합니다. SQL로 쿼리합니다.
특징:
- 엄격한 스키마 (컬럼 타입, 제약 조건)
- ACID 트랜잭션 (원자성, 일관성, 격리성, 지속성)
- JOIN으로 여러 테이블 데이터를 결합
적합한 경우: 금융, 결제, 사용자 데이터처럼 일관성이 중요한 데이터
NoSQL 데이터베이스
스키마가 유연합니다. 다양한 데이터 모델을 지원합니다.
종류:
- 문서형 (MongoDB): JSON과 유사한 문서로 저장
- 키-값 (Redis): 단순 키-값 쌍으로 저장
- 컬럼형 (Cassandra): 대용량 쓰기에 최적화
- 그래프 (Neo4j): 관계(엣지)가 중요한 데이터
적합한 경우: 스키마가 자주 변하는 경우, 매우 큰 규모의 쓰기 작업
주요 데이터베이스 비교
PostgreSQL
가장 범용적이고 강력한 오픈소스 관계형 데이터베이스입니다.
장점:
- JSON 타입 지원 (NoSQL처럼 유연한 데이터 저장 가능)
- 강력한 인덱스 옵션 (B-tree, GIN, GiST, BRIN)
- 전문 검색(Full-text search) 내장
- 확장 생태계 풍부 (PostGIS로 지리 데이터, pgvector로 벡터 검색)
- ACID 완벽 지원
단점: MySQL보다 약간 무겁고, 설정이 더 복잡할 수 있음
추천 사용 사례: 대부분의 웹 서비스. 특별한 이유가 없으면 PostgreSQL을 선택하세요.
관리형 서비스: Supabase, Neon, Railway, AWS RDS
MySQL / MariaDB
전통적으로 웹 서비스에 많이 사용된 관계형 데이터베이스입니다.
장점:
- WordPress, Laravel 등 레거시 스택과 호환성이 높음
- 읽기 속도가 빠름
- 사용 사례와 문서가 풍부
단점: PostgreSQL보다 고급 기능이 부족, JSON 지원이 약함
추천 사용 사례: 기존 LAMP 스택 프로젝트, WordPress 기반 서비스
MongoDB
문서 지향 NoSQL 데이터베이스입니다.
장점:
- 스키마리스: 다양한 구조의 문서를 같은 컬렉션에 저장 가능
- JavaScript/JSON과 자연스럽게 어울림
- 수평 확장 용이
단점:
- JOIN 개념 없음 (애플리케이션 레벨에서 처리해야 함)
- 트랜잭션 지원이 PostgreSQL보다 약함
- 스키마 없는 유연성이 오히려 데이터 일관성 문제를 일으킬 수 있음
추천 사용 사례: 콘텐츠 관리, 이벤트 로그, 프로토타이핑
Redis
인메모리 키-값 스토어입니다.
장점:
- 초고속 (디스크 I/O 없이 메모리에서 처리)
- 다양한 자료 구조 지원 (String, Hash, List, Set, Sorted Set)
- TTL 설정으로 자동 만료 기능
단점:
- 메모리 크기가 한계
- 기본적으로 데이터 영속성이 낮음
추천 사용 사례: 세션 저장, 캐싱, 실시간 리더보드, 큐(Queue)
// Redis 캐싱 예시
const cacheKey = `user:${userId}`;
const cached = await redis.get(cacheKey);
if (cached) {
return JSON.parse(cached);
}
const user = await db.user.findUnique({ where: { id: userId } });
await redis.setex(cacheKey, 3600, JSON.stringify(user)); // 1시간 캐싱
return user;
관리형 서비스 선택
직접 데이터베이스 서버를 운영하는 것은 복잡합니다. 소규모 서비스에는 관리형 서비스를 사용하세요.
| 서비스 | DB | 무료 플랜 | 특징 |
|---|---|---|---|
| Supabase | PostgreSQL | 500MB | 인증, 스토리지 포함 |
| Neon | PostgreSQL | 0.5 GB | 서버리스, 자동 스케일 |
| PlanetScale | MySQL | 5GB | 브랜치 기반 스키마 관리 |
| MongoDB Atlas | MongoDB | 512MB | 가장 쉬운 MongoDB 관리 |
| Upstash | Redis | 10,000 req/일 | 서버리스 Redis |
인덱스 기초
데이터가 많아질수록 인덱스는 필수입니다.
-- 자주 조회하는 컬럼에 인덱스 추가
CREATE INDEX idx_users_email ON users(email);
CREATE INDEX idx_posts_user_id ON posts(user_id);
-- 인덱스 사용 여부 확인
EXPLAIN SELECT * FROM users WHERE email = 'test@example.com';
인덱스 없이 100만 건의 테이블에서 검색하면 전체 스캔이 발생해 수 초가 걸립니다. 인덱스가 있으면 밀리초 내에 결과가 나옵니다.
대부분의 사이드 프로젝트에서 PostgreSQL(Supabase나 Neon) + Redis(Upstash)의 조합이면 충분합니다. 먼저 잘 알고 있는 것으로 시작하고, 실제 문제가 생겼을 때 다른 도구를 고려하세요.