1인 개발자가 겪은 Supabase 무료 플랜 한계와 실제 트래픽 도달 시점, 대안 비교

사이드 프로젝트 배포하고 두 달 됐을 때였어요. DAU 200명 정도 됐을 때, Supabase 대시보드에 경고 메시지가 뜨기 시작했죠. “Database egress 90% 도달.” 무료로 쓸 수 있다고 해서 시작했는데, 서비스가 조금 커지니 바로 벽에 부딪히는 느낌. 1인 개발자들 사이에서 이 패턴이 반복되고 있어요.
그래서 직접 파봤어요. Supabase 무료 플랜이 실제로 어느 시점에서 한계에 도달하는지, 대안은 뭐가 있는지.
핵심 요약
- Supabase 무료 플랜은 MAU 약 500명, DB 500MB, 월 egress 5GB 제한이 있고, 보통 DAU 150-200명 수준에서 첫 제한에 도달한다.
- 7일 이상 비활성 상태면 프로젝트가 자동 일시정지(pause)되는 정책이 1인 개발자를 가장 많이 괴롭히는 요소다.
- Pro 플랜($25/월)은 무제한 MAU와 8GB DB, 250GB egress를 제공하며, MVP를 넘어설 때 가장 먼저 고려할 옵션이다.
- PlanetScale, Neon, Firebase 등 대안 각각이 비용·기술 스택·확장성 면에서 뚜렷한 트레이드오프를 갖는다.
- 트래픽이 MAU 1,000명을 넘기 전에 아키텍처 결정을 내려야 이전 비용을 최소화할 수 있다.
Supabase 무료 플랜, 정확히 무엇이 제한되나
먼저 숫자부터 봐요. Supabase 공식 문서(2026년 3월 기준) 기준으로 무료 플랜의 핵심 한도는 이렇게 정리돼요.
- DB 용량: 500MB
- 월간 egress: 5GB
- 스토리지: 1GB
- Edge Function 실행: 월 50만 회
- Auth MAU: 50,000명
- 비활성 일시정지: 7일 이상 요청 없으면 자동 pause
Auth MAU 50,000명은 1인 개발자 기준으로 한참 여유 있어요. 문제는 다른 곳에서 터져요.
DB 용량 500MB, 이게 생각보다 빠르게 차요. 유저 프로필, 로그 데이터, 이미지 메타데이터 같은 걸 쌓다 보면 MAU 300-400명짜리 서비스도 3-4개월 안에 한계에 도달하는 경우가 많아요. AI 기능 탑재 서비스는 벡터 데이터(pgvector)를 같이 저장하기 때문에 이 속도가 두 배 이상 빨라진다고 해요.
월 egress 5GB도 빠르게 소진돼요. 이미지가 많은 앱이라면 MAU 200명 수준에서도 한 달 안에 초과할 수 있어요. 유저당 평균 3MB 이미지를 5개 조회한다고 하면, 300명이면 이미 4.5GB죠.
그리고 7일 비활성 pause 정책. 사이드 프로젝트 운영자들한테 가장 황당한 경험이에요. 잠깐 작업 안 했더니 서비스가 꺼져있는 상황. 개발 기간이 길어지는 프로젝트거나 테스트 환경으로 쓰는 경우엔 특히 문제가 돼요.
실제 트래픽, 어느 시점이 임계점인가
추상적인 숫자보다 실제 패턴이 더 유용해요. 국내 개발자 커뮤니티와 Supabase GitHub Discussions를 종합하면 패턴이 보여요.
- DAU 50명 이하: 사실상 아무 문제 없어요. 이 단계는 무료 플랜으로 6개월도 거뜬해요.
- DAU 100-200명: egress가 제일 먼저 경고선에 걸려요. 이미지·파일 많은 서비스는 이 구간에서 초과.
- DAU 200-400명: DB 크기 한계가 가시권에 들어와요. 로그를 쌓거나 벡터 데이터가 있으면 더 빨리.
- DAU 400명 이상: 복합 초과가 시작돼요. 이 시점이면 Pro 플랜 업그레이드를 진지하게 고민해야 해요.
한 줄 요약하면? DAU 150-200명이 실질적인 경계선이에요.
대안 비교: 그래서 뭐로 갈아탈까
Supabase Pro로 올리는 게 답이 될 수도 있고, 아예 다른 스택으로 갈 수도 있어요. 선택지를 직접 비교해볼게요.
| 항목 | Supabase Free | Supabase Pro | Neon (Free) | Firebase Spark | PlanetScale (Hobby) |
|---|---|---|---|---|---|
| 월 비용 | $0 | $25 | $0 | $0 | $0 |
| DB 크기 | 500MB | 8GB | 512MB | 1GB | 5GB |
| Egress | 5GB | 250GB | 3GB | 10GB | 1GB |
| 비활성 pause | 7일 | 없음 | 없음 | 없음 | 없음 |
| Auth 포함 | ✅ | ✅ | ❌ | ✅ | ❌ |
| 실시간 기능 | ✅ | ✅ | ❌ | ✅ | ❌ |
| pgvector | ✅ | ✅ | ✅ | ❌ | ❌ |
| 오픈소스 | ✅ | ✅ | ✅ | ❌ | ❌ (일부) |
무료 티어들끼리는 사실 큰 차이가 없어요. 그런데 비활성 pause가 없다는 점에서 Neon이 개발 환경으로는 더 편해요. Firebase는 NoSQL이라 PostgreSQL 기반 스택을 쓰던 팀이 이전하기엔 아키텍처를 통째로 바꿔야 해요.
트레이드오프를 정리하면 이렇게 돼요.
Supabase Pro ($25/월): Auth·실시간·스토리지가 한 번에 묶여 있어서 1인 개발자한테 가성비가 제일 좋아요. 단, 트래픽이 크게 튀면 추가 비용이 붙어요.
Neon: serverless PostgreSQL이라 콜드 스타트가 있고 실시간 기능은 직접 구현해야 해요. 하지만 auto-scaling이 되고 pay-per-use 구조라 트래픽이 불규칙한 서비스엔 유리해요.
Firebase: 프론트엔드 중심의 빠른 프로토타이핑엔 여전히 강해요. 안정성은 보장되는데, 벤더 종속이 강하고 복잡한 관계형 쿼리가 필요한 서비스엔 맞지 않아요.
지금 당장 해야 할 것들
시나리오 1: 사이드 프로젝트가 이제 막 DAU 100명을 넘겼을 때
egress 사용량부터 확인해요. Supabase 대시보드 → Settings → Usage에서 볼 수 있어요. 이미지를 직접 Supabase Storage에서 서빙하고 있다면, CDN 레이어(Cloudflare R2 또는 Cloudflare Images)를 앞에 붙이는 것만으로 egress를 절반 이하로 줄일 수 있어요. 비용 들이기 전에 구조 먼저 바꿔보는 거예요.
시나리오 2: 비활성 pause 때문에 개발 흐름이 끊길 때
두 가지 방법이 있어요. 하나는 GitHub Actions로 하루 한 번 헬스체크 요청을 자동 전송하는 것(실제로 많이 쓰는 방법이에요). 다른 하나는 개발 환경만 Neon으로 분리하는 거예요. 프로덕션은 Supabase, 개발 DB는 Neon으로 두면 pause 걱정 없이 작업할 수 있어요.
시나리오 3: MAU 1,000명을 앞두고 있을 때
이 시점이 진짜 결정의 순간이에요. Supabase Pro로 그냥 올릴지, 아니면 백엔드를 분리하고 DB는 별도 관리할지. 서비스가 계속 성장한다는 가정 하에, 이 시점 이후 이전 비용이 급격히 올라가요. DB 스키마, Auth 로직, Storage 파일까지 모두 이전해야 하니까요. MAU 500-800명 사이가 의사결정 적기예요.
결론: 무료 플랜은 MVP까지만
Supabase 무료 플랜은 잘 만든 제품이에요. 그런데 “무료로 오래 쓸 수 있다"는 기대와 현실 사이엔 꽤 큰 간격이 있어요.
- DAU 150명이 첫 경고선. egress가 제일 먼저 걸려요.
- 7일 pause 정책은 개발 흐름에 생각보다 큰 방해가 돼요.
- **Pro ($25/월)**는 MAU 수천 명까지 커버하는 가성비 좋은 선택이에요.
- 대안 전환은 MAU 500-800명 구간에서 결정해야 비용을 최소화할 수 있어요.
앞으로 6-12개월 안에 Supabase는 무료 플랜 정책을 한 번 더 조정할 가능성이 있어요. 경쟁 서비스들이 더 넉넉한 무료 티어를 들고 나오고 있으니까요. 이 흐름을 보면서 자신의 서비스가 어느 단계에 있는지 분기마다 점검하는 게 현실적인 방법이에요.
지금 Supabase를 쓰고 있다면, 대시보드 Usage 탭을 한번 열어보세요. 지금 어디쯤 와있는지 숫자로 확인하는 것부터가 시작이에요.
참고자료
- Supabase 입문 가이드: 오픈소스 Firebase 대안의 모든 것 - [루닥스 블로그] 연습만이 살길이다
- [Supabase 시작하기] - 회원 가입부터 기초 CRUD, RAG를 위한 pgvector 활성화 하기 :: 갓대희의 작은공간
- Why AI startups choose Supabase and where it falls short · Logto blog
Photo by Ales Nesetril on Unsplash


