Next.js 데이터베이스 선택 가이드: PostgreSQL, MySQL, MongoDB 및 클라우드 서비스 완전 비교

프로젝트 출시까지 48시간밖에 남지 않은 상황에서 Vercel 콘솔의 “Add Database” 옵션을 바라보며 커서를 Postgres, MySQL, MongoDB 사이에서 계속 움직이고 있었습니다. 브라우저에 띄운 탭 10개는 모두 기술 글이었습니다. 어떤 글은 Supabase의 무료 한도가 넉넉하다고 했고, 어떤 글은 PlanetScale의 성능이 압도적이라고 했으며, 또 다른 글은 MongoDB가 Next.js에 가장 잘 맞는다고 주장했습니다.

선택지가 너무 많았습니다. 모두 좋아 보이지만 저마다 한계도 분명했습니다. 더 큰 문제는 잘못 선택하면 나중의 마이그레이션 비용이 코드를 다시 작성하는 비용보다 더 커질 수 있다는 점입니다.

여러분도 같은 고민을 하고 있다면 이 글이 도움이 될 것입니다. PostgreSQL, MySQL, MongoDB라는 세 가지 대표 데이터베이스의 본질적인 차이와 Vercel Postgres, Supabase, PlanetScale, MongoDB Atlas 같은 클라우드 서비스를 어떻게 선택해야 하는지 가장 이해하기 쉬운 방식으로 정리하겠습니다.

뜬구름 잡는 이야기는 하지 않겠습니다.

이 글을 다 읽고 나면 세 가지 질문에 답하는 것만으로 빠르게 결정을 내릴 수 있습니다.

먼저 기본부터 이해하기 — 세 가지 데이터베이스의 본질적인 차이

PostgreSQL vs MySQL vs MongoDB: 관계형과 비관계형의 차이가 전부는 아닙니다

보통 PostgreSQL과 MySQL은 관계형 데이터베이스이고 MongoDB는 NoSQL이라고 설명합니다. 틀린 말은 아니지만, 이런 분류만으로는 무엇을 선택해야 할지 알기 어렵습니다.

이번에는 각각의 성격이라는 관점에서 살펴보겠습니다.

PostgreSQL은 기능이 풍부한 스위스 아미 나이프와 같습니다. 전통적인 관계형 데이터뿐 아니라 JSON, 전문 검색, 지리 공간 데이터도 처리할 수 있고 복잡한 저장 프로시저까지 작성할 수 있습니다. 생각할 수 있는 고급 기능은 대부분 갖추고 있습니다. 다만 기능과 선택지가 많은 만큼 학습 곡선이 조금 가파르며 초보자가 혼란을 느끼기 쉽습니다.

성능 면에서 PostgreSQL은 복잡한 쿼리에 강합니다. 여러 테이블을 조인하는 상황에서 PostgreSQL이 동급 데이터베이스보다 약 30% 빠르다는 테스트 결과도 있습니다. 물론 대가도 있습니다. 설정이 적절하지 않으면 MySQL보다 리소스를 더 많이 사용할 수 있습니다.

MySQL은 안정적이고 믿을 만한 오랜 동료와 같습니다. 가볍고 성숙했으며 문서가 잘 갖춰져 있고 커뮤니티 자료도 넘쳐납니다. 문제가 생겨도 검색만 하면 해결책을 찾을 수 있는 경우가 많습니다. 많은 오래된 프로젝트가 MySQL을 사용하는 이유도 관리가 편하기 때문입니다.

하지만 MySQL에도 약점은 있습니다. 수직 확장 방식이므로, 쉽게 말해 서버 성능이 한계에 도달하면 더 강력한 서버로 바꿔야 합니다. MongoDB처럼 서버를 추가해 수평 확장하기는 어렵습니다. 트래픽이 많지 않은 프로젝트에서는 문제가 아니지만, 고동시성 애플리케이션이라면 병목이 될 수 있습니다.

MongoDB는 완전히 다릅니다. 테이블이 아니라 JSON 형식의 문서를 저장합니다. 덕분에 유연성이 매우 높습니다. 관계형 데이터베이스처럼 먼저 테이블 구조를 변경하지 않아도 언제든 특정 문서에 필드를 추가할 수 있습니다. 요구 사항이 빠르게 바뀌는 프로젝트에는 정말 큰 도움이 됩니다.

예전에 콘텐츠 관리 시스템을 개발한 적이 있는데, 글의 사용자 정의 필드가 자주 바뀌었습니다. 오늘은 “읽는 데 걸리는 시간”을 추가하고, 다음 날에는 “관련 추천”을 추가해야 했습니다. MySQL을 사용했다면 요구 사항이 바뀔 때마다 ALTER TABLE을 실행하고 기존 데이터와의 호환성까지 고려해야 했을 것입니다. MongoDB로 바꾼 뒤에는 코드에 필드를 바로 추가할 수 있었습니다.

물론 MongoDB도 만능은 아닙니다. 복잡한 다중 테이블 조인 쿼리는 지원하지 않거나 구현하기가 매우 번거롭습니다. 엄격한 트랜잭션 일관성이 필요할 때도 기능 자체는 지원하지만 관계형 데이터베이스만큼 자연스럽지는 않습니다.

결국 데이터베이스 선택은 “좋은가 나쁜가”의 문제가 아니라 “프로젝트에 잘 맞는가”의 문제입니다.

언제 무엇을 써야 할까요? 세 가지 판단 기준

절대적으로 “가장 좋은” 데이터베이스가 없다면 어떻게 판단해야 할까요? 실용적인 기준 세 가지를 제안하겠습니다.

기준 1: 데이터 관계가 얼마나 복잡한가

가장 핵심적인 기준입니다.

프로젝트에 “이것이 저것과 연결되는” 로직이 많이 있나요? 예를 들어 전자상거래 시스템에서는 사용자에게 주문이 있고, 주문에는 상품이 있으며, 상품에는 카테고리가 있고, 카테고리에는 다시 태그가 있습니다. 이런 다층 중첩 구조를 자주 JOIN으로 조회해야 한다면 PostgreSQL이나 MySQL이 우선 선택지입니다. 관계형 데이터베이스는 바로 이런 상황을 위해 만들어졌으며 외래 키 제약 조건과 트랜잭션 일관성도 기본으로 제공합니다.

반대로 데이터 구조가 비교적 평면적이거나 각 데이터가 독립적이라면 MongoDB가 훨씬 편할 수 있습니다. 대표적인 예가 블로그 시스템의 글과 댓글입니다. 각 글을 하나의 완전한 JSON 문서로 저장하고, 댓글은 글 안에 바로 중첩하거나 별도로 저장한 뒤 단순한 관계만 맺을 수 있습니다. 이런 경우에는 MongoDB의 유연성이 장점이 됩니다.

기준 2: 요구 사항이 얼마나 자주 바뀌는가

제품 관리자가 며칠에 한 번씩 요구 사항을 바꾸나요? 그렇다면 MongoDB가 큰 도움이 될 수 있습니다.

처음에는 관계형 데이터베이스에 필드와 인덱스, 제약 조건을 완벽하게 설계했지만 2주 뒤 제품 담당자가 “사용자 태그 기능을 추가해야 합니다”라고 말하는 프로젝트를 많이 봤습니다. 다시 2주 뒤에는 “태그는 다중 선택을 지원해야 합니다”, 또 2주 뒤에는 “태그에 계층 관계가 있어야 합니다”라는 요구가 이어집니다. 요구 사항이 바뀔 때마다 데이터베이스도 바뀌고 마이그레이션 스크립트 작성은 끝이 없습니다.

MongoDB를 사용하면 이런 변경은 큰 문제가 아닙니다. 코드에 필드를 바로 추가하고, 기존 데이터와의 호환성은 코드 로직으로 처리하면 됩니다. 물론 이는 코드 계층에서 더 많은 데이터 검증을 수행해야 한다는 뜻이기도 합니다. 데이터베이스가 대신 안전망 역할을 해주지는 않기 때문입니다.

하지만 비즈니스 로직이 이미 안정적이거나 재무 소프트웨어나 ERP처럼 규칙과 프로세스가 명확하고 고정된 시스템이라면 관계형 데이터베이스의 제약 조건이 오히려 장점입니다. 잘못된 데이터가 기록되는 것을 데이터베이스 계층에서 막아 주므로 코드에서 신경 쓸 일이 줄어듭니다.

기준 3: 팀이 익숙하게 사용하는 것은 무엇인가

이 점을 과소평가하면 안 됩니다.

기술 스택에 절대적인 우열은 없지만 팀의 숙련도 차이는 분명히 존재합니다. 팀원 모두가 SQL에 익숙한데 억지로 MongoDB를 사용한다면 학습 비용과 시행착오에 드는 시간이 프로젝트 자체보다 길어질 수도 있습니다. 반대의 경우도 마찬가지입니다.

예전에 함께했던 스타트업 팀은 모두 JavaScript 배경이었고 SQL에는 익숙하지 않았습니다. 당시 PostgreSQL을 사용하면서 복잡한 쿼리를 작성할 때마다 문서를 찾아봐야 했고, 인덱스 최적화는 더 막막했습니다. 이후 MongoDB + Mongoose로 바꾸자 개발 효율이 바로 두 배로 높아졌습니다. Mongoose API가 JavaScript 객체 조작과 거의 같아 사고방식을 전환할 필요가 없었기 때문입니다.

물론 팀의 익숙한 방식에 무조건 맞춰야 한다는 뜻은 아닙니다. 프로젝트에 관계형 데이터베이스가 꼭 필요하다면 배워야 합니다. 하지만 두 솔루션 모두 요구 사항을 충족할 수 있다면 팀이 더 익숙한 것을 선택하는 편이 틀림없이 좋습니다.

Vultr - 고성능 NVMe 클라우드 서버, 전 세계 32개 노드, Docker 원클릭 배포

요금 보기 →광고

클라우드 서비스 대전 — Vercel Postgres, Supabase, PlanetScale, MongoDB Atlas 중 무엇을 선택할까요?

클라우드 서비스 비교: 가격만 보면 안 됩니다

데이터베이스를 정했다면 다음은 클라우드 서비스 선택입니다.

Vercel Postgres, Supabase, PlanetScale, MongoDB Atlas 모두 매력적으로 보이지만 중요한 차이는 세부 사항에 숨어 있습니다. 하나씩 살펴보겠습니다.

Vercel Postgres: 원클릭 배포의 매력

프로젝트가 이미 Vercel에 배포되어 있다면 Vercel Postgres는 거의 가장 간편한 선택입니다. 몇 번 클릭하면 데이터베이스 설정이 끝나고 환경 변수도 자동으로 주입되며, 지연 시간도 놀랄 만큼 짧습니다. 벤치마크에서는 흔히 <10ms로 나타납니다.

하지만 분명한 단점도 있습니다. 기능이 비교적 단순합니다. 내장 사용자 인증 시스템, 저장소 서비스, 실시간 구독 기능이 없습니다. 단순한 PostgreSQL 데이터베이스만 필요하다면 완벽하지만 통합 패키지가 필요하다면 다른 서비스를 직접 조합해야 합니다.

가격 면에서 무료 플랜은 256MB 저장 공간을 제공해 소규모 프로젝트에는 충분합니다. 유료 플랜은 월 $20부터 시작하므로 저렴하지는 않지만 Vercel 배포와 긴밀하게 통합된다는 점을 고려하면 값을 합니다.

Supabase: 오픈 소스 생태계의 만능 선수

Supabase는 제가 개인적으로 가장 좋아하는 선택지 중 하나입니다. 이유는 단순합니다. PostgreSQL 데이터베이스뿐 아니라 사용자 인증, 파일 저장소, 실시간 데이터 구독을 기본으로 제공하고 Supabase Studio라는 꽤 편리한 관리 화면도 갖췄기 때문입니다.

무료 한도도 넉넉합니다. 데이터베이스 500MB + 저장소 1GB를 제공하므로 개인 프로젝트와 MVP에는 충분합니다. 제품 전체를 Supabase 무료 플랜에서 문제없이 운영하는 독립 개발자도 많이 봤습니다.

성능은 어떨까요? 솔직히 PlanetScale보다는 떨어집니다. 한 벤치마크에서는 Supabase의 QPS(초당 쿼리 수)가 약 5000인 반면 PlanetScale은 17000에 달했습니다. 하지만 대부분의 중소형 애플리케이션에서는 이 차이를 크게 체감하기 어렵습니다. 게다가 Supabase는 표준 PostgreSQL을 사용하므로 마이그레이션도 편리합니다.

한 가지 주의할 점은 트래픽이 갑자기 폭증하면 Supabase의 커넥션 풀이 병목이 될 수 있다는 것입니다. 다만 Serverless 환경의 연결 수 문제를 해결하는 Pooler 기능을 제공하므로 설정만 해 주면 됩니다.

PlanetScale: 성능 괴물이지만 대가가 있습니다

PlanetScale의 성능은 확실히 강력합니다. 앞에서 언급한 벤치마크에 따르면 QPS는 혼합 읽기/쓰기에서 약 17000, 읽기 전용에서는 약 35000에 이르며 Supabase의 거의 세 배입니다. 고동시성 애플리케이션이라면 차이가 분명합니다.

또 하나 멋진 기능은 데이터베이스 브랜치 관리입니다. Git처럼 데이터베이스 브랜치를 만들고 해당 브랜치에서 스키마 변경을 테스트한 뒤 문제가 없을 때 메인 브랜치에 병합할 수 있습니다. 팀 협업에서는 매우 유용합니다.

하지만 뚜렷한 단점도 몇 가지 있습니다.

첫째, 외래 키를 지원하지 않습니다. 외래 키 제약 조건에 의존하는 프로젝트에는 큰 문제이며 애플리케이션 계층에서 데이터 일관성을 직접 처리해야 합니다.

둘째, 비쌉니다. PlanetScale은 2024년에 무료 플랜을 폐지했고 현재 시작 가격은 월 $34입니다. 예산이 빠듯한 개인 개발자나 스타트업 팀에는 적지 않은 금액입니다.

따라서 프로젝트에 정말 매우 높은 동시성 성능이 필요하거나 팀 규모가 커서 데이터베이스 브랜치 관리가 필요하다면 PlanetScale에 투자할 가치가 있습니다. 그렇지 않다면 비용 대비 효과가 더 좋은 선택지도 있습니다.

MongoDB Atlas: 유연성의 대가는 학습 곡선입니다

MongoDB의 공식 클라우드 서비스로, 무료 플랜에서 512MB를 제공합니다. Vercel Postgres의 두 배이며 Supabase와 비슷한 수준입니다. 배포가 편리하고 전 세계 여러 리전도 지원합니다.

데이터베이스로 MongoDB를 선택했다면 Atlas가 사실상 기본 선택입니다. 공식 서비스인 만큼 안정성과 기능 업데이트를 보장받을 수 있습니다.

하지만 NoSQL의 학습 곡선도 고려해야 합니다. 계속 SQL만 사용해 왔다면 MongoDB의 집계 쿼리(Aggregation Pipeline)가 다소 낯설 수 있습니다. 또한 MongoDB가 트랜잭션을 지원하기는 하지만 관계형 데이터베이스만큼 자연스럽지 않고 일부 상황에서는 성능이 저하될 수도 있습니다.

숨은 함정도 있습니다. 바로 대역폭 비용입니다. MongoDB Atlas는 저장 용량과 요청량에 따라 과금하므로 애플리케이션에서 쿼리를 자주 실행하면 대역폭 비용이 데이터베이스 자체 비용보다 더 커질 수 있습니다. 한 지인은 Atlas를 사용하다 월말 청구서에서 대역폭 비용이 60%를 차지한 것을 보고 깜짝 놀랐습니다. 쿼리 로직을 최적화하고 캐시를 추가한 뒤에야 비용을 낮출 수 있었습니다.

빠르게 비교할 수 있도록 성능 표를 정리하면 다음과 같습니다.

숨은 비용: 월 이용료가 전부는 아닙니다

많은 사람이 바로 이 부분에서 실수하기 때문에 특히 중요합니다.

청구서에 표시되는 데이터베이스 월 이용료는 빙산의 일각일 뿐입니다. 실제로 부담이 되는 것은 대개 숨겨진 비용입니다.

연결 수 제한: Serverless의 악몽

Next.js를 Vercel이나 다른 Serverless 플랫폼에 배포하면 각 요청이 새로운 함수 인스턴스를 시작합니다. 모든 인스턴스가 데이터베이스 연결을 하나씩 생성한다면 동시 요청 수가 수백 개만 되어도 데이터베이스 커넥션 풀이 가득 찰 수 있습니다.

전통적인 커넥션 풀 방식은 Serverless 환경에서 거의 제대로 작동하지 않습니다. “Too many connections”, “Connection pool exhausted” 같은 오류 메시지를 보게 됩니다. 새벽 세 시에 경고 알림 때문에 잠에서 깨는 경험은 다시 하고 싶지 않습니다.

다행히 대부분의 클라우드 서비스도 이 문제를 인지하고 있습니다. Supabase는 Pooler 모드를 제공하고, PlanetScale은 커넥션 풀이 내장되어 있으며, Vercel Postgres는 자체 서비스이므로 깊이 최적화되어 있습니다. 반면 MongoDB Atlas에서는 직접 처리해야 합니다. 커넥션 풀 라이브러리를 사용하거나 연결 수 경고를 감수해야 합니다.

대역폭 비용: 빈번한 쿼리의 보이지 않는 비용

데이터베이스와 애플리케이션이 같은 리전에 있지 않나요? 그렇다면 쿼리를 실행할 때마다 리전 간 데이터가 전송되어 대역폭 비용이 빠르게 늘어납니다.

MongoDB Atlas에서 이 문제가 특히 두드러집니다. 요청량과 데이터 전송량을 기준으로 과금하므로 애플리케이션의 쿼리가 잦고 반환 데이터도 많다면 대역폭 비용이 데이터베이스 자체 비용을 쉽게 넘어설 수 있습니다.

해결 방법:

1. 데이터베이스와 애플리케이션을 가급적 같은 리전에 배포합니다.
2. 쿼리할 때 필요한 필드만 반환하고 SELECT *는 사용하지 않습니다.
3. 캐시 계층을 추가해 반복 쿼리를 줄입니다.

확장 비용: 무시할 수 없는 장기 투자

PlanetScale과 Supabase는 모두 저장 용량과 연결 수에 따라 단계별로 과금합니다. 처음에는 무료 또는 저가 구간에 머물 수 있지만 데이터가 늘어나면 비용 구간이 올라갑니다.

예를 들어 Supabase 무료 플랜은 500MB를 제공합니다. 이를 초과하면 월 $25의 Pro 플랜에서 8GB를 제공합니다. 데이터가 10GB까지 증가하면 초과분을 더 내야 합니다. 차액 자체는 커 보이지 않지만 미리 계획하지 않았다가 월 청구액이 갑자기 두 배가 되면 부담스럽습니다.

PlanetScale은 더 극단적입니다. 행 수를 기준으로 과금하며 월 $34의 시작 플랜에는 100억 행 읽기와 5천만 행 쓰기가 포함됩니다. 이를 초과하면 사용량에 따라 추가 비용이 발생합니다. 쓰기 빈도가 높은 애플리케이션에서는 비용이 빠르게 증가할 수 있습니다.

마이그레이션 비용: 잘못 선택한 뒤 치러야 하는 대가

가장 쉽게 간과하는 비용입니다.

데이터베이스 마이그레이션은 단순히 데이터를 옮기는 작업이 아닙니다. 스키마 변환, 코드 조정, 테스트와 검증까지 필요합니다. 소규모 프로젝트라면 하루나 이틀 만에 끝낼 수 있지만 대규모 프로젝트는 몇 달이 걸릴 수도 있습니다.

예전에 한 프로젝트에서 편의성 때문에 MongoDB를 선택했다가 비즈니스가 복잡해지면서 복잡한 쿼리를 작성하기가 너무 어려워 PostgreSQL로 마이그레이션한 적이 있습니다. 새로운 관계형 스키마를 설계하는 데만 1주가 걸렸고, 마이그레이션 스크립트를 디버깅하는 데 보름이 들었습니다. 테스트 환경과 프로덕션 환경에 각각 배포하기까지 전체 과정은 거의 두 달이나 걸렸습니다.

그래서 확신이 없다면 주류이면서 마이그레이션하기 쉬운 솔루션을 우선 선택하라고 권합니다. 예를 들어 ORM 프레임워크(Prisma, Drizzle)로 데이터베이스를 추상화해 두면 나중에 데이터베이스를 바꾸더라도 적어도 코드 계층의 변경을 줄일 수 있습니다.

결정 프레임워크 — 세 가지 질문으로 솔루션 정하기

질문 1: 어떤 유형의 프로젝트인가요?

기술적인 세부 사항을 충분히 살펴봤으니 이제 가장 현실적인 질문으로 돌아가겠습니다. 결국 무엇을 선택해야 할까요?

간단하고 명확한 결정 프레임워크를 제시하겠습니다. 복잡한 성능 지표를 기억할 필요 없이 스스로에게 세 가지 질문만 하면 됩니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

첫 번째 질문: 어떤 유형의 프로젝트인가요?

이 질문 하나가 선택의 80%를 결정합니다.

개인 프로젝트 / 빠른 MVP 검증

예산은 제한적이지만 다양한 기능이 필요하다면? → Supabase

무료 한도로 데이터베이스 500MB + 저장소 1GB를 제공하며 사용자 인증과 실시간 구독까지 내장되어 있어 개인 개발자에게는 꿈 같은 구성입니다. 전체 SaaS 제품을 Supabase 무료 플랜에서 운영하면서 사용자 수가 수천 명이어도 문제없이 사용하는 독립 개발자를 많이 봤습니다.

NoSQL에 더 익숙하거나 프로젝트의 데이터 구조가 특히 유연하다면? → MongoDB Atlas

512MB 무료 플랜을 제공하며 콘텐츠 관리 시스템, 블로그, 로그 수집처럼 데이터 구조가 고정되지 않은 프로젝트에 적합합니다.

스타트업 / 소규모 팀 프로젝트

이미 Vercel에 배포했고 개발 효율을 중시한다면? → Vercel Postgres

무료 플랜이 256MB에 불과하지만 Vercel과 긴밀하게 통합되어 환경 변수가 자동 주입되고 엣지 네트워크 가속도 이용할 수 있어 설정 시간을 크게 줄일 수 있습니다. 스타트업 팀에게 가장 비싼 것은 월 $20가 아니라 시간입니다.

사용자 인증과 파일 저장소 같은 통합 기능이 필요하다면? → Supabase

Supabase는 단순한 데이터베이스가 아니라 완전한 백엔드 솔루션입니다. Authentication, Storage, Edge Functions가 모두 준비되어 있어 개발 기간을 몇 주나 줄일 수 있습니다.

기업 애플리케이션 / 고동시성 환경

사용자가 많고 성능 요구 사항이 엄격하다면? → PlanetScale

QPS 약 17000은 결코 과장이 아니며, 데이터베이스 브랜치 관리도 대규모 팀에 정말 유용합니다. 안정적인 수익이 있는 기업이라면 월 $34의 시작 가격은 큰 부담이 아닙니다.

다만 PlanetScale은 외래 키를 지원하지 않습니다. 비즈니스 로직이 외래 키 제약 조건에 크게 의존한다면 다시 검토해야 합니다.

콘텐츠 사이트 / 블로그 / 미디어 플랫폼

데이터 구조가 유연하고 쿼리는 비교적 단순하다면? → MongoDB Atlas

글, 댓글, 태그 같은 콘텐츠 데이터는 문서형 데이터베이스에 매우 자연스럽게 저장할 수 있습니다. MongoDB의 전문 검색 기능도 관계형 데이터베이스보다 훨씬 편리합니다.

실시간 댓글이나 실시간 알림이 필요하다면? → Supabase

Realtime 기능은 PostgreSQL의 Change Data Capture를 기반으로 하며, 설정만 하면 WebSocket을 직접 구축하지 않고도 실시간 구독을 구현할 수 있습니다.

질문 2: 예산과 규모는 어느 정도인가요?

비용 문제는 결국 마주해야 합니다.

예산이 없는 단계(완전 무료 솔루션)

Supabase(데이터베이스 500MB + 저장소 1GB) 또는 MongoDB Atlas(512MB)가 사실상 유일한 선택지입니다.

Vercel Postgres에도 무료 플랜이 있지만 256MB에 불과해 성장 여지가 제한적입니다. PlanetScale은 무료 플랜 자체가 없으므로 제외합니다.

프로젝트에 사용자 인증이나 파일 업로드가 필요할 가능성이 있다면 Supabase를 우선 추천합니다. 순수하게 데이터만 저장한다면 MongoDB Atlas가 더 유연합니다.

소규모 예산 단계(월 예산 <$50)

Supabase Pro(월 $25)나 Vercel Postgres(월 $20부터)가 이 범위에 들어옵니다.

Supabase Pro는 8GB 데이터베이스 + 100GB 저장소 + 월간 활성 사용자 5만 명의 Auth를 제공해 비용 대비 효과가 좋습니다. Vercel Postgres는 조금 더 비싸지만 전체 애플리케이션 스택이 Vercel에 있다면 절약되는 운영 시간이 가격 차이를 상쇄합니다.

MongoDB Atlas는 사용량 기반 과금이라 소규모라면 월 몇 달러만 들 수도 있습니다. 다만 대역폭 비용이 통제되지 않도록 계속 확인해야 합니다.

중간 예산 단계(월 예산 $50-200)

이 단계에서는 PlanetScale(월 $34부터)과 Supabase Team(연 $599, 월 약 $50)을 모두 고려할 수 있습니다.

선택 기준은 성능 요구 사항입니다. QPS 요구가 높지 않다면 Supabase Team 플랜이 더 경제적이고 팀 협업 기능도 더 풍부합니다. 고동시성 환경이라면 PlanetScale의 성능 우위에 투자할 가치가 있습니다.

대규모 / 고동시성 단계

솔직히 이 단계에서는 클라우드 서비스의 비용 대비 효과가 떨어지기 시작합니다. 많은 회사가 AWS RDS, Google Cloud SQL을 사용하거나 PostgreSQL 클러스터를 직접 구축합니다.

하지만 팀 규모가 작고 전담 DBA가 없다면 PlanetScale이나 Supabase 엔터프라이즈 플랜을 계속 사용하는 것도 합리적입니다. 운영 비용을 외부에 맡기고 제품 개발에 집중할 수 있기 때문입니다.

질문 3: 기술 부채를 얼마나 감당할 수 있나요?

마지막 질문은 자주 간과되지만 매우 중요합니다.

향후 마이그레이션 위험을 감수할 수 있는 경우

우선 무료 서비스를 사용해 제품을 빠르게 검증하세요. 프로젝트의 가능성을 확인한 뒤 마이그레이션이나 업그레이드를 검토하면 됩니다.

많은 성공적인 제품이 이 경로를 거쳤습니다. 처음에는 MongoDB Atlas 무료 플랜으로 사용자 수천 명을 확보하고, 더 복잡한 쿼리 로직이 필요해지면 PostgreSQL로 옮기며, 이후 트래픽이 급증하면 데이터베이스 클러스터를 직접 구축합니다.

핵심은 미리 준비하는 것입니다.

1. ORM 프레임워크(Prisma, Drizzle)를 추상화 계층으로 사용해 마이그레이션 비용을 낮춥니다.
2. 데이터베이스 접근 로직을 한곳에서 관리하고 여러 파일에 흩어 놓지 않습니다.
3. 데이터를 정기적으로 백업해 마이그레이션 실패에 대비합니다.

한 번에 제대로 선택해 시행착오를 줄이고 싶은 경우

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

검증된 주류 솔루션을 선택하세요. PostgreSQL + Supabase 또는 PostgreSQL + 자체 구축 조합입니다.

PostgreSQL은 현재 가장 성숙한 오픈 소스 데이터베이스로 생태계가 잘 갖춰져 있고 마이그레이션 경로도 명확합니다. 오늘 Supabase를 사용하다 내일 AWS RDS나 자체 서버로 옮겨도 SQL 문은 거의 변경할 필요가 없습니다.

MongoDB는 유연하지만 생태계가 상대적으로 폐쇄적입니다. MongoDB를 사용하다 나중에 관계형 데이터베이스로 바꾸는 작업은 사실상 리팩터링과 같습니다.

제 개인적인 경험

현재 새 프로젝트에서 기본으로 선택하는 조합은 Next.js + Prisma + Supabase입니다.

이유는 간단합니다.

• Supabase 무료 한도로 시작하고 수익이 생기면 업그레이드할 수 있습니다.
• Prisma의 타입 안전성과 마이그레이션 도구가 안심을 줍니다.
• PostgreSQL 생태계 덕분에 언제든 다른 클라우드 서비스로 옮길 수 있습니다.
• 프로젝트에 Auth나 Storage가 필요하면 Supabase에 이미 포함되어 있어 편리합니다.

하지만 고동시성 환경이거나 팀에 이미 성숙한 데이터베이스 운영 경험이 있다면 PlanetScale이나 자체 구축 솔루션을 바로 선택합니다.

실전 설정 체크리스트

빠른 시작 설정

이론은 충분히 살펴봤으니 이제 실전으로 넘어가겠습니다.

자주 사용하는 몇 가지 조합의 핵심 설정을 정리하겠습니다. 긴 코드를 붙여 넣지는 않지만 꼭 주의해야 할 사항을 설명하겠습니다.

솔루션 1: Vercel Postgres + Prisma

가장 빠르면 5분 안에 시작할 수 있습니다.

핵심 단계:

1. Vercel 프로젝트에서 “Storage” → “Create Database”를 클릭하고 Postgres를 선택합니다.
2. 환경 변수가 .env에 자동 주입되므로 process.env.POSTGRES_PRISMA_URL을 바로 사용합니다.
3. npx prisma generate로 Prisma 클라이언트를 생성합니다.
4. Serverless 환경에서 연결 수가 폭증하지 않도록 Prisma 커넥션 풀을 반드시 설정합니다.

주의 사항:

• 개발 환경과 프로덕션 환경의 데이터베이스를 분리해 실수로 프로덕션 데이터를 삭제하지 않도록 합니다.
• 팀 협업이 꼬이지 않도록 Prisma migration 파일을 git에 반드시 커밋합니다.

솔루션 2: Supabase + Prisma

기능이 가장 풍부하며 Auth가 필요한 프로젝트에 적합합니다.

핵심 단계:

1. Supabase 공식 사이트에서 프로젝트를 만들고 데이터베이스 연결 문자열을 가져옵니다.
2. 환경 변수에 DATABASE_URL과 DIRECT_URL을 설정합니다. 후자는 migration에 사용합니다.
3. 연결 수 문제를 피하도록 Supabase의 Pooler 모드를 활성화합니다.
4. Auth가 필요하면 Next.js와 매끄럽게 통합되는 @supabase/auth-helpers-nextjs 라이브러리를 사용합니다.

주의 사항:

• 데이터 보안 문제가 생기지 않도록 Row Level Security(RLS)를 올바르게 설정합니다.
• Supabase의 Realtime 기능은 기본적으로 꺼져 있으므로 테이블 설정에서 직접 활성화해야 합니다.

솔루션 3: MongoDB Atlas + Mongoose

JavaScript 배경의 팀에 적합합니다.

핵심 단계:

1. MongoDB Atlas에서 클러스터를 만들고 연결 문자열을 가져옵니다. <password>를 실제 비밀번호로 교체해야 합니다.
2. Mongoose로 Schema를 정의합니다. MongoDB가 schemaless라고 해도 코드 계층의 타입 제약은 여전히 필요합니다.
3. 콜드 스타트 타임아웃을 방지하도록 연결 시 serverSelectionTimeoutMS를 설정합니다.
4. 쿼리할 때 .lean()을 사용해 순수 JavaScript 객체를 반환하면 성능이 더 좋아집니다.

주의 사항:

• 비밀번호가 포함된 데이터베이스 연결 문자열을 절대로 git에 커밋하지 마세요. .env.local을 사용하고 .gitignore에 추가합니다.
• MongoDB 인덱스는 직접 만들어야 합니다. 그렇지 않으면 믿기 어려울 정도로 쿼리가 느려집니다.
• 집계 쿼리(Aggregation)는 학습 곡선이 다소 가파르므로 문서를 미리 읽어 두세요.

공통 권장 사항

어떤 솔루션을 사용하든 다음 사항은 꼭 지켜야 합니다.

1. 환경 변수 관리: .env.local(로컬)과 .env.production(프로덕션)을 구분해 사용합니다.
2. 커넥션 풀 설정: Serverless 환경에서는 필수입니다. 설정하지 않으면 연결 수가 폭증합니다.
3. 오류 처리: 데이터베이스 쿼리는 반드시 try-catch로 처리하고 데이터베이스 오류를 사용자에게 그대로 노출하지 않습니다.
4. 백업 전략: 정기적으로 백업합니다. 클라우드 서비스에도 문제가 생길 수 있습니다.
5. 모니터링 알림: 데이터베이스 성능 모니터링을 설정하고 연결 수, 쿼리 소요 시간 같은 지표를 확인합니다.

결론

지금까지 살펴본 내용을 바탕으로 처음의 질문으로 돌아가 보겠습니다. Next.js 프로젝트에는 어떤 데이터베이스를 선택해야 할까요?

정답은 표준 답안은 없지만 결정 프레임워크는 있다는 것입니다.

스스로에게 세 가지 질문을 해보세요.

1. 프로젝트 유형: 개인 프로젝트인가요? 스타트업인가요? 기업 애플리케이션인가요?
2. 예산 규모: 예산이 없나요? 소규모 예산(<$50)인가요? 중대형 예산인가요?
3. 기술 부채 감내 수준: 향후 마이그레이션을 받아들일 수 있나요? 아니면 처음부터 확실한 선택을 원하나요?

그래도 결정하기 어렵다면 보수적인 선택으로 Supabase + Prisma + PostgreSQL을 추천합니다.

이유는 다음과 같습니다.

• 무료 한도가 있어 개인 프로젝트가 수익을 내기 시작할 때까지 사용할 수 있습니다.
• Database + Auth + Storage를 모두 제공해 개발 시간을 절약할 수 있습니다.
• PostgreSQL 생태계가 성숙하고 마이그레이션 경로가 다양합니다.
• Prisma의 타입 안전성으로 코드의 신뢰성을 높일 수 있습니다.

물론 프로젝트에 매우 높은 성능(PlanetScale), 유연한 스키마(MongoDB Atlas), Vercel과의 긴밀한 통합(Vercel Postgres) 같은 특별한 요구가 있다면 그에 맞춰 선택하세요.

마지막으로 한마디만 하겠습니다. 데이터베이스 선택은 한 번으로 끝나는 결정이 아니라 진화하는 과정입니다. 먼저 빠르게 출시해 제품을 검증하고 실제 상황에 따라 최적화하세요. 기술 방안을 고민하느라 제품 출시 시기를 놓치지 마세요.

지금 프로젝트를 열고 스스로에게 이 세 가지 질문을 던져 보세요. 10분 안에 결정한 뒤 코드 작성을 시작하면 됩니다.

문제가 생기면 댓글에서 이야기해 주세요.