사이드 프로젝트를 Supabase로 시작하면 처음 몇 달은 돈 얘기가 나올 일이 없습니다. 문제는 그다음입니다. 무료 티어가 어디서 끊기는지 모르는 채로 운영하다가, 트래픽이 붙은 날 아침에 egress 초과 메일을 받거나 — 더 흔하게는 — 한동안 안 들여다본 프로젝트가 멈춰 있는 걸 발견합니다.
“무료로 되나요”보다 중요한 건 “언제부터 돈을 내야 하나”입니다. 그 선을 숫자로 정리해 봤습니다.
무료 티어 한도 (2026년 9월 기준)
| 항목 | Free | Pro ($25/월) |
|---|---|---|
| DB 용량 | 500 MB | 8 GB 포함, 초과 $0.125/GB |
| Egress | 5 GB | 250 GB 포함, 초과 $0.09/GB |
| MAU | 50,000 | 100,000, 초과 $0.00325/MAU |
| 파일 스토리지 | 1 GB | 100 GB 포함, 초과 $0.0213/GB |
| 활성 프로젝트 | 2개 | 무제한 |
| 백업 | 없음 | 일 단위, 7일 보관 |
| 로그 보관 | 1일 | 7일 |
| 일시정지 | 7일 미사용 시 | 없음 |
요금제 수치는 개정이 잦습니다. 실제 결제 결정 전에 공식 pricing 페이지를 한 번 더 확인하세요.
표에서 눈여겨볼 건 마지막 두 줄입니다. 백업이 없다는 것과 안 쓰면 멈춘다는 것. 용량 한도보다 이쪽이 먼저 사람을 괴롭힙니다.
어떤 한도가 먼저 터지는가
한도 여섯 개를 다 걱정할 필요는 없습니다. 서비스 성격에 따라 터지는 순서가 정해져 있습니다.
이미지·파일을 올리는 앱이면 스토리지가 먼저입니다. 1 GB는 원본 사진 기준 300~500장입니다. 사용자 100명이 프로필 사진 한 장씩만 올려도 리사이즈 안 하면 절반이 찹니다.
목록 조회가 많은 앱이면 egress가 먼저입니다. 5 GB를 한 응답 50 KB로 나누면 10만 요청입니다. 넉넉해 보이지만 이미지를 Supabase Storage에서 직접 서빙하면 얘기가 완전히 달라집니다. 이미지 한 장이 200 KB면 2만 5천 뷰에서 끝납니다.
텍스트 위주 앱이면 DB 용량이 마지막까지 안 터집니다. 500 MB는 로우 수십만 건입니다. 대신 인덱스와 로그 테이블이 조용히 갉아먹으니 주기적으로 봐야 합니다.
MAU 5만은 사실상 안 터집니다. 개인 프로젝트에서 월 활성 사용자 5만이면 이미 수익화를 고민할 단계입니다. 다만 익명 로그인을 쓰면 카운트가 예상보다 빨리 오릅니다. 소셜 로그인 설정을 붙일 때 익명 세션을 어떻게 처리할지 같이 정해두는 게 좋습니다.
진짜 함정은 7일 자동 일시정지
무료 티어에서 실제로 가장 많이 당하는 건 용량이 아니라 이겁니다. 7일 동안 DB 활동이 거의 없으면 프로젝트가 일시정지됩니다.
- 정지 약 1주일 전에 경고 메일이 옵니다. 스팸함에 들어가면 그대로 끝입니다.
- 하루에 요청 몇 건 수준이면 정지를 피하기에 충분합니다. 대시보드 접속도 활동으로 잡힙니다.
- 데이터는 사라지지 않습니다. 대시보드에서 Resume를 누르면 이전 상태로 돌아옵니다. 복구 가능한 기간은 1년입니다.
정지 자체보다 무서운 건 타이밍입니다. 포트폴리오로 올려둔 데모를 채용 담당자가 열었을 때, 로그인 화면에서 무한 로딩이 도는 상황. 복구에 몇 분 걸리는데 그 몇 분이 없습니다.
핑으로 살려두는 건 괜찮은가
GitHub Actions로 하루 한 번 쿼리를 던져 프로젝트를 깨워두는 방법을 쓰는 사람이 많습니다. 크론에 select 1 하나면 끝나는 일입니다.
이게 정당한지는 케이스를 나눠서 봐야 합니다. 실제로 쓰는 서비스인데 트래픽이 아직 적어서 정지되는 경우라면 핑을 거는 게 맞습니다. 정지 정책의 목적은 방치된 프로젝트의 자원 회수지, 트래픽 적은 서비스를 벌주는 게 아닙니다.
반대로 쓰지도 않는 프로젝트를 좀비로 유지하려고 더미 데이터를 계속 넣는 건 다른 얘기입니다. 그건 정책이 막으려는 바로 그 행동입니다. 안 쓰는 프로젝트는 스키마만 SQL로 덤프해두고 지우는 편이 낫습니다. 어차피 활성 프로젝트는 2개까지입니다. 그 두 자리는 진짜 쓰는 것에 써야 합니다.
Pro로 넘어가야 하는 신호 3가지
용량이 찼다는 이유만으로 결제하는 건 이릅니다. 아래 셋 중 하나라도 해당되면 그때가 $25를 낼 때입니다.
- 데이터가 날아가면 곤란해지는 순간. 무료 티어는 백업이 없습니다. 남의 데이터가 들어오기 시작했다면 용량이 얼마든 Pro입니다. 이게 1순위입니다.
- 장애를 사후에 못 쫓게 됐을 때. 로그 보관이 1일이라 주말에 터진 문제를 월요일에 보면 흔적이 없습니다. 원인을 로그 없이 찾고 있다면 이미 늦었습니다.
- 정지가 서비스 사고가 될 때. 외부에 URL을 공유했고 그게 언제 열릴지 모른다면 핑으로 버티지 말고 정지 없는 요금제로 가야 합니다.
용량 초과는 대부분 4순위입니다. 아래 방법으로 상당 부분 미룰 수 있어서요.
결제 전에 줄일 수 있는 것들
이미지는 업로드 시점에 리사이즈합니다. 원본 4 MB를 그대로 올리면 스토리지와 egress를 동시에 씁니다. 클라이언트에서 긴 변 1200px, WebP로 변환해 올리면 대개 10분의 1이 됩니다. 스토리지와 egress 한도를 한 번에 미루는 가장 효과 큰 조치입니다.
select *를 없앱니다. 목록 화면에서 본문 컬럼까지 통째로 받아오는 코드가 생각보다 많습니다. 필요한 컬럼만 지정하면 egress가 눈에 띄게 줄어듭니다.
이미지는 CDN 뒤에 둡니다. Supabase Storage에서 직접 서빙하면 조회 한 번이 곧 egress입니다. Cloudflare를 앞에 세우면 두 번째 조회부터는 Supabase에 닿지 않습니다.
안 쓰는 인덱스와 로그 테이블을 정리합니다. DB 용량이 차는 원인은 보통 로우가 아니라 인덱스입니다. pg_stat_user_indexes로 스캔 0회짜리를 찾아 지우면 됩니다.
이 네 가지를 하고 나면 대부분의 개인 프로젝트는 무료 티어에서 한참 더 버팁니다. 그러다 위의 신호 3가지 중 하나가 오면, 그때는 고민 없이 결제하면 됩니다.
전체 인프라 구성을 어떻게 잡았는지는 Vercel + Supabase 최소 인프라 구성에 정리해 뒀습니다.