사이드 프로젝트 DB로 Supabase를 선택한 이유

DB를 어디에 둘까

사이드 프로젝트를 시작할 때 가장 먼저 부딪히는 질문이 있다. DB를 어디에 둘 것인가.

선택지는 크게 두 가지다. 서버에 직접 PostgreSQL을 설치하거나, 관리형 서비스를 쓰거나.

직접 설치하면 비용은 아끼지만 백업, 모니터링, 버전 업그레이드를 전부 직접 해야 한다. 사이드 프로젝트는 본업 끝나고 틈틈이 하는 건데, DB 관리까지 신경 쓰고 싶지 않았다.

관리형 서비스로 방향을 잡았다.

 

선택지 비교

PostgreSQL을 지원하는 관리형 서비스 중 무료 티어가 있는 것들을 추렸다.

 

서비스	DB 엔진	무료 티어	Prisma 호환	특징
Supabase	PostgreSQL	500MB, 무제한	✅	Auth, Storage 등 부가 기능
PlanetScale	MySQL	Hobby 플랜 종료	✅	Vitess 기반, 브랜칭 기능
Neon	PostgreSQL	512MB, 무제한	✅	Serverless, 자동 스케일링
Railway	PostgreSQL	$5 크레딧/월	✅	간편한 배포, 크레딧 소진 시 중단

 

PlanetScale은 MySQL 기반이라 제외했다. Prisma는 PostgreSQL과 MySQL 모두 지원하지만, 이미 PostgreSQL에 익숙했고 굳이 바꿀 이유가 없었다.

Railway는 무료 크레딧이 소진되면 서비스가 멈춘다. 사이드 프로젝트라 트래픽 예측이 어려워서 불안했다.

Neon과 Supabase가 남았다. 둘 다 PostgreSQL 기반이고 무료 티어도 비슷하다.

 

Supabase를 선택한 이유

솔직히 말하면 Neon과 Supabase는 큰 차이가 없다. 둘 다 PostgreSQL이고, 무료 티어 용량도 비슷하고, Prisma도 잘 붙는다.

결정적인 건 레퍼런스 양이었다.

"Supabase Prisma 연결" "Supabase 마이그레이션 오류"로 검색하면 스택오버플로우, 블로그, GitHub 이슈가 많이 나온다. Neon은 상대적으로 적다. 사이드 프로젝트는 삽질 시간을 줄이는 게 중요하다. 문제가 생겼을 때 빠르게 해결책을 찾을 수 있는 쪽을 택했다.

부가적인 이유도 있다:

• Auth, Storage 확장 가능성: 지금은 DB만 쓰지만, 나중에 소셜 로그인이나 파일 업로드가 필요하면 같은 프로젝트 안에서 추가할 수 있다.
• 대시보드 UI: 테이블 구조 확인, 데이터 조회, SQL 실행을 웹에서 바로 할 수 있다. Neon도 가능하지만 Supabase 쪽이 조금 더 익숙했다.

 

실제 운영: Dev/Prod 분리

Supabase 프로젝트를 두 개 만들어서 Dev와 Prod를 분리했다.

 

환경	리전	용도
Development	Seoul (ap-northeast-2)	로컬 개발, 테스트
Production	Singapore (ap-southeast-1)	실서비스

 

Prod를 싱가포르에 둔 이유는 웹 서버가 DigitalOcean 싱가포르 리전에 있어서다. DB와 서버가 같은 리전에 있어야 레이턴시가 낮다.

Dev는 서울에 뒀다. 로컬에서 개발할 때 응답이 빨라야 작업이 편하다.

 

연결 방식: Session Pooler

Supabase Free Tier에서는 Direct Connection(포트 5432 직접 연결)이 방화벽으로 막혀 있다. IPv4 Add-on($4/월)을 붙여야 열린다.

대신 Session Pooler를 통해 연결한다. Pooler는 DB 앞단에서 연결을 관리해주는 프록시다. 클라이언트가 많아져도 DB 연결 수를 일정하게 유지해준다.

Prisma에서는 이렇게 설정한다.

 

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  // directUrl = env("DIRECT_URL")  // Free Tier에서는 사용 불가
}

 

DATABASE_URL에는 Pooler URL을 넣는다.

 

postgresql://postgres.[project-ref]:[password]@aws-0-[region].pooler.supabase.com:5432/postgres

 

마이그레이션도 이 URL로 잘 돌아간다. 처음엔 Direct Connection이 필요한 줄 알았는데 아니었다.

 

여담: 데이터를 날린 이야기

Supabase를 1년 가까이 잘 쓰다가 한 번 크게 데이터를 날렸다.

테이블 두 개를 하나로 통합하는 마이그레이션을 진행했다. Dev DB에서는 데이터 이관 스크립트를 돌리고 기존 테이블을 DROP했다. 잘 됐다.

문제는 Production이었다. 마이그레이션 SQL만 배포하고, 데이터 이관 스크립트를 깜빡했다. DROP TABLE이 실행됐고, 데이터가 전부 날아갔다.

복구하려고 Supabase 대시보드를 열었다. Backups 메뉴로 들어갔는데 이런 문구가 떴다.

"Backups are available on the Pro plan."

Free Tier에는 백업이 없다. 복구 불가.

이 사고 이후로 두 가지를 바꿨다.

1. 데이터 이관은 SQL 마이그레이션 파일에 포함시킨다

별도 스크립트로 분리하면 Production에서 까먹을 수 있다. INSERT INTO ... SELECT를 마이그레이션 SQL에 직접 넣어야 한다.

 

-- migration.sql
-- 1. 새 테이블 생성
CREATE TABLE "Layer" (...);

-- 2. 기존 데이터 복사 (DROP 전에!)
INSERT INTO "Layer" (id, "projectId", source, ...)
SELECT id, "projectId", 'figma', ...
FROM "FigmaItem";

-- 3. 기존 테이블 삭제
DROP TABLE "FigmaItem";

 

2. 위험한 마이그레이션 전에는 수동 백업

Free Tier라도 pg_dump로 백업할 수 있다. 귀찮지만 데이터 날리는 것보다 낫다.

 

pg_dump "postgresql://..." > backup_$(date +%Y%m%d).sql

 

 

 

언제 Supabase가 적합한가

정리하면 이렇다.

 

Supabase가 맞는 경우:

• PostgreSQL + Prisma 조합을 쓴다
• DB 관리에 시간 쓰고 싶지 않다
• 무료로 시작하고 싶다
• 나중에 Auth/Storage 확장 가능성을 열어두고 싶다

 

다른 선택이 나은 경우:

• MySQL이 필요하다 → PlanetScale (유료) 또는 직접 설치
• Serverless 스케일링이 중요하다 → Neon
• 자동 백업이 필수다 → Supabase Pro($25/월) 또는 다른 서비스

 

Free Tier로 시작해서 서비스가 커지면 Pro로 올리면 된다. 다만 "Free Tier에는 백업이 없다"는 건 꼭 기억해두자.

 

 

---

 

 

 

프런트엔드 엔지니어, QA 엔지니어 그리고 디자이너를 위한
" ALL IN ONE "   QA 서비스

 

PixelDIff

 

https://pixeldiff.turtle-tail.com