Supabase vs Firebase 비용 비교 2026: 무료 한도와 프로젝트별 선택 기준

1. 한 줄 문제 정의: 싼 백엔드가 아니라 비용이 커지는 축을 고르는 문제다

핵심 한 줄: Supabase와 Firebase의 가격표는 같은 단위를 비교하지 않기 때문에 월 기본료만 보면 잘못 고르기 쉽다.

Supabase는 PostgreSQL 컴퓨트와 조직 단위 사용량을 중심으로 과금하고, Firebase의 대표 데이터베이스인 Firestore는 문서 읽기·쓰기·삭제와 네트워크 사용량을 중심으로 과금한다. 따라서 “사용자 1만 명이면 얼마”라는 질문에는 화면당 쿼리 수, 실시간 리스너, 파일 전송량, 데이터 관계를 함께 넣어야 답할 수 있다.

이 글은 2026년 7월 공식 가격 페이지를 기준으로 웹 SaaS, 모바일 앱, 관리자 도구의 선택을 돕는다. 특정 리전의 세금·환율·Cloud Functions 같은 부가 서비스까지 확정 견적을 내는 글은 아니다. 실제 결제 전에는 반드시 각 사 계산기로 다시 확인해야 한다.

2. 먼저 결론: 관계형 웹 SaaS는 Supabase, 오프라인 모바일은 Firebase가 유리하다

핵심 한 줄: 데이터 관계와 SQL이 핵심이면 Supabase, 모바일 오프라인 동기화와 Google 생태계가 핵심이면 Firebase를 우선 검토하라.

• Supabase 추천: 고객·조직·구독·주문처럼 조인이 많은 SaaS, SQL 보고서, 행 단위 권한, 비용 예측 가능성이 중요한 팀.
• Firebase 추천: 채팅·피드·현장 앱처럼 실시간 동기화와 오프라인 재연결이 중요한 모바일 제품, Crashlytics·FCM·Google Analytics를 한 생태계에서 쓰는 팀.
• 둘 다 과한 경우: 읽기 위주의 단순 콘텐츠 사이트는 정적 생성과 가벼운 호스팅이 더 싸고 단순하다.

무료 구간만 보면 둘 다 강하다. Supabase Free는 프로젝트당 데이터베이스 500MB, 저장소 1GB, 월간 활성 사용자 5만 명, 송신 5GB를 제공한다. Firebase Spark의 Firestore는 하루 문서 읽기 5만 회, 쓰기 2만 회, 삭제 2만 회를 제공하고 Firebase Authentication은 월간 활성 사용자 5만 명까지 무료다. 그러나 무료 한도의 단위가 월·일·프로젝트로 섞여 있으므로 숫자를 그대로 우열로 해석하면 안 된다.

3. 핵심 구조 분해: 데이터·인증·파일·함수 네 장의 청구서

핵심 한 줄: BaaS 비용은 데이터베이스 하나가 아니라 네 개의 사용량 축이 합쳐진 결과다.

1. 데이터 계층: Supabase는 한 프로젝트의 PostgreSQL 컴퓨트와 디스크가 중심이다. Firebase Firestore는 문서 연산 수가 중심이며 쿼리의 인덱스 엔트리 읽기도 과금에 영향을 줄 수 있다.
2. 인증 계층: 두 서비스 모두 일반 인증은 월간 활성 사용자 수를 본다. 전화 인증, SAML/OIDC 같은 기업 기능은 별도 단가와 조건을 확인해야 한다.
3. 파일·네트워크 계층: 이미지와 동영상은 저장 용량보다 다운로드 송신량이 더 빨리 비용을 키울 수 있다. CDN 캐시 여부도 함께 측정해야 한다.
4. 실행 계층: Edge Functions 또는 Cloud Functions는 호출, 실행 시간, 메모리와 외부 네트워크를 따로 본다. 데이터베이스가 무료여도 함수가 무료라는 뜻은 아니다.

비용 모델을 식으로 단순화하면 월 비용 = 기본 컴퓨트 + 초과 저장소 + 초과 송신 + 인증 초과 + 함수 실행 + 데이터 연산이다. Supabase에서는 앞쪽의 고정비 비중이, Firestore에서는 마지막 데이터 연산의 변동비 비중이 상대적으로 크다.

4. 설계 의도 해설: 고정 용량과 사용량 종량제의 교환

핵심 한 줄: Supabase는 서버를 빌리는 감각에 가깝고, Firestore는 API 호출을 사는 감각에 가깝다.

Supabase가 PostgreSQL을 중심에 둔 이유는 관계, 트랜잭션, SQL, Row Level Security를 하나의 데이터 엔진에서 처리하기 위해서다. 복잡한 조회를 한 번의 SQL로 묶고 실행 계획과 인덱스를 튜닝할 수 있는 대신, 트래픽이 거의 없어도 유료 프로젝트의 컴퓨트 비용은 존재한다.

Firestore는 문서 단위 분산과 클라이언트 동기화를 우선한다. 필요한 문서를 SDK가 직접 구독하고 자동 확장하기 쉬운 대신, 화면 재렌더링이나 잘못 설계한 실시간 리스너가 문서 읽기를 반복하면 비용이 사용자 수보다 빠르게 커질 수 있다. 즉 Supabase는 용량 계획과 SQL 운영 능력을 요구하고, Firebase는 접근 패턴과 연산 수 설계를 요구한다.

Firebase Data Connect는 Cloud SQL for PostgreSQL을 제공해 “Firebase는 NoSQL뿐”이라는 오래된 비교를 약화했다. 공식 가격 페이지상 3개월 무료 체험 뒤 구성에 따라 월 9.37달러부터 시작할 수 있다. 다만 이는 Firestore와 다른 청구 구조이므로, Data Connect를 선택했다면 Supabase와 관계형 데이터베이스 기준으로 다시 비교해야 한다.

5. 근거 및 비교: 무료보다 초과 단가와 운영 방식을 보라

핵심 한 줄: 초기 0원보다 “어떤 행동이 다음 1달러를 만드는가”가 더 중요한 비교 기준이다.

판단 기준	Supabase	Firebase/Firestore	실무 해석
무료 데이터	DB 500MB/프로젝트	저장 1GiB	관계형 스키마와 문서 구조라 단순 용량 비교 금지
무료 인증	월 5만 MAU	월 5만 MAU	전화·기업 인증은 별도 확인
무료 읽기/쓰기	API 요청 수보다 DB 자원 중심	읽기 5만/일, 쓰기·삭제 각 2만/일	Firestore는 화면당 문서 읽기 수가 핵심
유료 진입	Pro 조직 구독과 프로젝트 컴퓨트, 공식 비교표 기준 Pro 25달러부터	Blaze 종량제	저사용량은 Firebase, 예측성은 Supabase가 편할 수 있음
Pro 포함량 예시	DB 8GB/프로젝트, 저장소 100GB, 송신 250GB, 10만 MAU	서비스·리전별 무료 구간 후 종량제	Firebase는 계산기 입력이 필수
데이터 모델	PostgreSQL, SQL, 조인, 트랜잭션	Firestore 문서 또는 Data Connect PostgreSQL	요구사항을 먼저 고정
오프라인 모바일	직접 보완 필요	성숙한 SDK 캐시·동기화	현장 앱은 개발비 절감 효과가 큼
이탈 경로	Postgres 덤프·자체 호스팅 가능	Google 관리형 서비스 중심	마이그레이션 비용도 총비용에 포함

Supabase 공식 문서는 Pro의 초과 사용량을 데이터베이스 디스크 GB당 0.125달러, 저장소 GB당 0.021달러, 송신 GB당 0.09달러, 10만 명 초과 MAU당 0.00325달러로 설명한다. Firebase는 리전과 서비스에 따라 단가가 달라지므로 Firestore 가격표와 Blaze 계산기를 사용해야 한다. 가격은 바뀔 수 있으므로 이 글의 숫자는 견적의 출발점이지 계약 금액이 아니다.

6. 실제 동작 흐름: 20분 비용 시뮬레이션

핵심 한 줄: 사용자 수 대신 대표 화면 세 개의 읽기·쓰기·송신을 세면 견적 오차가 크게 줄어든다.

1. 대표 행동을 고른다. 로그인, 대시보드 열기, 주문 생성처럼 트래픽의 80%를 만드는 행동 세 개를 적는다.
2. 행동당 데이터 연산을 센다. 대시보드가 고객 1건, 주문 20건, 알림 10건을 별도 문서로 읽으면 한 번에 최대 31회 읽기다. 캐시와 쿼리 결과에 따라 실제 값은 달라진다.
3. 월 사용량을 계산한다. 행동당 읽기 × 일 사용자 × 사용자당 실행 횟수 × 30을 기본식으로 쓴다.
4. 송신량을 분리한다. 썸네일 300KB를 월 10만 번 내려주면 약 30GB다. 원본 이미지를 그대로 보내면 데이터베이스보다 네트워크가 먼저 비용 병목이 된다.
5. 두 계산기에 같은 가정을 넣는다. 무료 한도를 뺀 뒤 정상 월, 이벤트 월 3배, 장애성 재시도 월 10배를 비교한다.

예시 가정
DAU: 1,000명
대시보드: 사용자당 하루 3회
Firestore 문서 읽기: 화면당 25회
월 읽기: 1,000 × 3 × 25 × 30 = 2,250,000회
이미지 송신: 0.3MB × 100,000회 ≈ 30GB

검증할 것: 캐시 적중률, 실시간 재연결, 중복 쿼리, 리전 단가

Supabase를 시험한다면 로컬에서 supabase start로 스키마와 RLS 정책을 검증하고, Firebase를 시험한다면 Emulator Suite에서 읽기 횟수와 Security Rules를 확인한다. 운영 전에는 실제 SDK 계측으로 가정값을 교체해야 한다.

7. 실수/함정: 무료 한도를 믿고 운영 계측을 늦추는 패턴

핵심 한 줄: 비용 사고는 대개 가격이 비싸서가 아니라, 어떤 코드가 사용량을 만들었는지 모를 때 발생한다.

함정 1. Firestore 실시간 리스너를 화면 생명주기와 분리하지 않는다

중복 구독과 재연결이 읽기를 늘릴 수 있다. 구독 해제를 테스트하고, 화면별 동시 리스너 수를 대시보드에 기록한다. 비용이 튀면 실시간이 꼭 필요한 필드만 좁혀 복구한다.

함정 2. Supabase RLS 없이 anon 키를 안전하다고 오해한다

공개 키 자체가 보안 경계가 아니다. 모든 노출 테이블에 RLS를 켜고 사용자·조직 경계 테스트를 작성한다. 유출 가능성이 확인되면 정책을 먼저 차단하고 서비스 역할 키 로그를 회전한다.

함정 3. 개발·스테이징 프로젝트 수를 견적에서 뺀다

Supabase 유료 프로젝트의 컴퓨트, Firebase 추가 데이터베이스와 Cloud SQL은 환경 수에 따라 비용이 늘 수 있다. 운영·스테이징·PR 미리보기의 보존 기간을 정하고 자동 종료한다.

함정 4. 파일 원본을 앱에서 직접 반복 다운로드한다

이미지 리사이즈와 캐시 헤더가 없으면 송신량이 급증한다. 썸네일 파이프라인, CDN 캐시, 최대 업로드 크기를 먼저 설정한다.

함정 5. 무료 플랜에서 유료 플랜으로 넘어가는 조건을 테스트하지 않는다

결제 계정 연결 순간 사용 가능한 서비스와 과금 방식이 달라질 수 있다. 예산 알림만 믿지 말고 일별 사용량 한도, 비정상 호출 차단, 앱 기능 저하 모드를 준비한다.

8. 강점과 한계: 개발 속도도 총소유비용이다

핵심 한 줄: 인프라 청구액 10달러 차이보다 팀이 익숙하지 않은 권한 모델을 운영하는 인건비가 더 클 수 있다.

Supabase의 강점은 표준 PostgreSQL, SQL 마이그레이션, 복잡한 관계 조회와 데이터 이식성이다. 반대로 인덱스, 커넥션, 느린 쿼리와 RLS를 이해할 사람이 없으면 관리 부담이 생긴다. 무료에서 Pro로 넘어갈 때 낮은 사용량에도 고정비가 생기는 점도 1인 MVP에는 단점이다.

Firebase의 강점은 모바일 SDK, 오프라인 동기화, 자동 확장과 Google 제품 통합이다. 반대로 문서 모델에 관계형 요구를 억지로 넣으면 데이터 중복, 팬아웃 쓰기, 읽기 비용과 마이그레이션 비용이 늘어난다. Firestore가 항상 저렴하거나 Supabase가 항상 예측 가능하다는 식의 결론은 둘 다 틀리다.

관계형이 필요하지만 BaaS 기능이 적어도 된다면 Neon 같은 서버리스 Postgres도 비교 대상이다. 글로벌 엣지 읽기와 분산 SQL이 핵심이면 또 다른 데이터베이스가 맞을 수 있다. 선택지는 두 서비스로 닫혀 있지 않다.

9. 더 깊게 공부할 포인트와 내부 학습 경로

핵심 한 줄: 가격표 다음에는 권한·쿼리·관측성을 공부해야 실제 비용을 통제할 수 있다.

• Supabase 공식 가격표와 Supabase 공식 과금 구조 문서에서 최신 포함량과 조직 단위 합산 방식을 확인한다.
• Firebase 공식 가격표와 Cloud Firestore 공식 과금 문서에서 리스너, 인덱스 엔트리, 무료 데이터베이스 조건을 읽는다.
• 비교 글을 더 보려면 n8n·Make·Zapier 비용 비교에서 같은 비용 시뮬레이션 방식을 확인한다.
• 단계별 AI·개발 가이드는 AQ 가이드 허브에서 이어서 볼 수 있다.
• 도구 선택 전 자신의 AI 활용 수준은 AQ 테스트로 점검하고 맞는 학습 경로를 고른다.

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: 한 달 무료 데모가 아니라 트래픽 10배와 이탈 시나리오까지 통과한 쪽을 선택하라.

• 대표 사용자 행동 세 개와 행동당 읽기·쓰기 수를 측정했는가?
• 정상·3배·10배 트래픽의 월 비용을 같은 가정으로 계산했는가?
• 이미지·파일 송신량과 캐시 적중률을 별도로 계산했는가?
• 운영·스테이징·미리보기 환경의 프로젝트 수를 포함했는가?
• Supabase RLS 또는 Firebase Security Rules를 자동 테스트했는가?
• 실시간 구독 해제와 오프라인 재연결 시 중복 요청을 검증했는가?
• 예산 알림, 일별 사용량 관측, 비정상 호출 차단을 설정했는가?
• 데이터 내보내기와 다른 공급자로의 복구 시간을 실제로 재봤는가?

Definition of Done: 대표 화면의 실제 계측값으로 두 서비스의 정상·3배 트래픽 비용을 계산하고, 권한 테스트와 데이터 내보내기 복구까지 성공하면 선택 검토가 완료된 것이다.

작성자 관점: 새 웹 SaaS의 기본값으로는 Supabase를 추천한다. 고객·조직·결제 데이터는 시간이 갈수록 관계가 늘고, SQL과 표준 Postgres가 분석·이관에 유리하기 때문이다. 반면 네트워크가 끊기는 현장 모바일 앱, 채팅 중심 제품, FCM·Crashlytics가 중요한 팀이라면 Firebase가 개발비를 더 크게 줄인다. 가격표의 무료 숫자 하나만 보고 결정하는 선택은 추천하지 않는다.