Supabase Firebase 비교, 데이터 모델과 요금 차이

TL;DR

• Supabase Firebase 비교의 출발점은 데이터 모델이다. Supabase는 관계형 Postgres, Firebase의 Firestore는 문서형 NoSQL이다. 이 선택이 이후 모든 설계를 끌고 간다.
• 요금 구조도 다르다. Supabase는 월 구독에 사용량이 붙고, Firebase는 무료 한도 뒤에 구글 클라우드 종량 요금이 붙는다.
• Supabase는 오픈소스라 자체 호스팅 경로가 열려 있고, Firebase는 모바일 SDK와 오프라인 동기화가 강하다.

Supabase Firebase 비교는 개인 프로젝트를 넘어서는 순간 한 번은 하게 되는 판단이다.
둘 다 서버를 직접 굴리지 않고 인증과 데이터베이스, 파일 저장, 서버 함수를 한 번에 준다.
여기까지는 같다.

갈리는 지점은 그 아래다.
데이터를 어떻게 모델링하는지, 요금이 어떤 단위로 붙는지, 그리고 나중에 다른 곳으로 옮길 수 있는지.
Supabase가 공개한 비교 문서도 선택 기준을 “애플리케이션이 데이터를 어떻게 모델링하는지, 어떻게 확장할 계획인지, 벤더 종속을 얼마나 감내할 수 있는지”로 정리한다.
아래는 그 세 축을 각 서비스의 공식 문서와 요금표로 대조한 것이다.

데이터 모델이 갈리는 지점

Supabase는 프로젝트마다 전용 Postgres 데이터베이스를 준다.
테이블과 관계, 외래 키, 조인이 그대로 쓰인다.
SQL로 질의하고, 접근 제어도 SQL로 쓴다.
행 수준 보안 정책을 데이터와 같은 언어로 쓴다는 게 이 구조의 특징이다.

Firebase의 Firestore는 문서형이다.
JSON 비슷한 문서를 컬렉션으로 묶어 저장한다.
스키마를 미리 정하지 않아도 되고, 중첩된 구조를 그대로 넣을 수 있다.
대신 여러 컬렉션을 가로질러 조인하는 질의는 관계형 데이터베이스처럼 되지 않는다.

판단 기준은 데이터의 성격이다.
사용자와 주문과 상품처럼 관계가 뚜렷하고 집계 질의가 많으면 관계형이 편하다.
채팅 메시지나 활동 로그처럼 한 덩어리씩 읽고 쓰는 데이터가 대부분이면 문서형이 자연스럽다.

두 서비스의 구성 요소

Firebase 쪽에는 모바일 앱 운영 도구가 함께 붙는다.
크래시 리포팅, 원격 설정, 앱 배포, A/B 테스트, 애널리틱스가 같은 콘솔 안에 있다.
애플 플랫폼과 안드로이드, 웹, 플러터, 유니티, C++용 SDK를 제공한다.

Supabase 쪽은 데이터베이스를 확장하는 방향이 강하다.
벡터 검색, 크론, 큐 같은 기능이 데이터베이스 위에 얹혀 있어서 AI 기능을 붙일 때 별도 저장소를 추가하지 않아도 되는 구성이 나온다.

오프라인 동작이 필요한 경우

모바일 앱을 만든다면 이 항목을 먼저 본다.
Firestore SDK는 문서를 기기에 자동으로 캐시한다.
네트워크가 끊겨도 읽고 쓰고 변경을 구독할 수 있고, 다시 연결되면 동기화된다.

지하철이나 엘리베이터에서 앱이 멈추지 않아야 하는 서비스라면 이 기능이 크게 작동한다.
직접 구현하려면 로컬 저장소와 충돌 해결까지 만들어야 하는데, 그 부분을 SDK가 가져간다.

Supabase에서 같은 경험을 만들려면 클라이언트 쪽 캐시와 동기화를 별도로 설계해야 한다.
웹 서비스나 서버를 거치는 구조라면 큰 차이가 아니지만, 오프라인이 요구사항인 모바일 앱에서는 부담이 된다.

요금 구조를 나란히 놓으면

Supabase는 조직 단위 구독이다.
무료 플랜은 프로젝트 2개, 데이터베이스 500MB, 월 활성 사용자 5만 명, 이그레스 5GB까지이고 1주일 비활성이면 프로젝트가 멈춘다.
Pro는 월 $25부터이고 첫 프로젝트가 포함되며, 월 활성 사용자 10만 명과 프로젝트당 디스크 8GB, 이그레스 250GB가 들어간다.
초과분은 항목별 단가로 계산된다.

Firebase는 무료 Spark 플랜과 종량 Blaze 플랜 두 층이다.
Spark는 결제 수단 없이 시작할 수 있고, Blaze로 올리면 더 많은 서비스와 높은 한도가 열리면서 구글 클라우드 요금 체계로 넘어간다.
조건이 맞으면 $300 크레딧을 받는다.

Firebase 무료 한도를 항목별로 보면 성격이 드러난다.
인증은 월 활성 사용자 5만 명까지, Firestore는 저장 데이터 1GiB와 하루 문서 쓰기 2만 건, 읽기 5만 건, 월 네트워크 이그레스 10GiB까지 무료다.
스토리지는 5GB까지, 앱 호스팅 송신 대역폭은 월 10GiB까지 무료이고 그 위로는 GiB당 $0.20, 캐시된 트래픽은 $0.15다.

두 요금표의 성격 차이가 여기서 보인다.
Supabase는 월 고정액을 먼저 정하고 사용량이 붙는 구조라 예측이 쉽다.
Firebase는 사용하지 않으면 청구가 없지만, 읽기와 쓰기 건수로 계산되기 때문에 트래픽이 튀면 청구액도 함께 튄다.
요금 항목별 자세한 계산은 Supabase 가격에 따로 정리해뒀다.

벤더 종속과 이전 가능성

Supabase는 오픈소스다.
핵심 구성 요소가 Postgres와 공개 인증 서버 위에 올라가 있어서, 로컬에서 돌리거나 도커, 쿠버네티스, 테라폼으로 직접 호스팅할 수 있다.
관리형을 쓰다가 자체 호스팅으로 옮기는 경로가 열려 있고, 데이터도 Postgres 덤프로 나온다.

Firebase는 구글이 운영하는 관리형 서비스다.
자체 호스팅 경로가 없다.
데이터를 내보낼 수는 있지만 Firestore의 문서 구조를 관계형으로 옮기려면 변환 작업이 필요하다.

이 항목의 무게는 조직마다 다르다.
스타트업 초기에는 종속보다 속도가 중요하고, 규제나 조달 요건이 있는 조직에서는 자체 호스팅 가능 여부가 결정적이다.

어느 쪽을 고를지 판단하는 기준

Supabase 쪽이 맞는 경우.

• 데이터에 관계가 뚜렷하고 조인이나 집계 질의가 많다.
• SQL에 익숙한 팀이다.
• 자체 호스팅 선택지를 열어두고 싶다.
• 벡터 검색처럼 데이터베이스 확장 기능을 같은 곳에서 쓰고 싶다.

Firebase 쪽이 맞는 경우.

• 모바일 앱이 주 무대이고 오프라인 동작이 필요하다.
• 크래시 리포팅, 원격 설정, 앱 배포 같은 운영 도구를 함께 쓰고 싶다.
• 데이터 구조가 문서 단위로 자연스럽고 복잡한 조인이 없다.
• 이미 구글 클라우드를 쓰고 있어 결제와 권한을 한곳에서 관리하고 싶다.

실행 체크리스트

1. 저장할 데이터의 관계를 종이에 그려봅니다. 조인이 많으면 관계형이 유리합니다.
2. 오프라인 동작이 요구사항인지 확인합니다. 모바일 앱이면 비중이 커집니다.
3. 예상 월 활성 사용자와 읽기·쓰기 건수를 각각 추정합니다.
4. 두 요금표에 그 숫자를 대입해 월 비용을 계산합니다.
5. 트래픽이 튈 가능성이 있으면 상한 설정 방법을 각각 확인합니다.
6. 자체 호스팅이나 이전 가능성이 요구되는지 조직 규정을 봅니다.
7. 크래시 리포팅이나 원격 설정 같은 운영 도구가 필요한지 정리합니다.
8. 두 서비스 무료 구간에서 같은 화면 하나를 만들어 개발 속도를 비교합니다.

실시간 기능이 필요한 경우

채팅이나 공동 편집처럼 화면이 즉시 갱신돼야 하는 기능이라면 두 서비스가 접근하는 방식이 다르다.

Firestore는 클라이언트가 문서나 컬렉션을 구독하고, 변경이 생기면 SDK가 화면에 반영한다.
오프라인 캐시와 같은 층에서 동작하므로 연결이 끊겼다 붙어도 흐름이 이어진다.

Supabase는 데이터베이스 변경을 구독하는 방식이다.
테이블에 행이 들어오면 구독 중인 클라이언트로 전달된다.
여기에 채널로 데이터를 뿌리거나 사용자 상태를 동기화하는 기능이 함께 있다.

차이는 읽기 요금과 이어진다.
Firestore는 문서 읽기 건수로 과금되므로 구독이 많아지면 읽기 수가 늘어난다.
Supabase는 이그레스와 구독 연결 수 쪽에서 사용량이 계산된다.
실시간 기능의 비중이 크다면 예상 동시 접속자 수를 두 요금 체계에 각각 대입해보는 편이 정확하다.

인증을 붙이는 방식의 차이

두 서비스 모두 이메일과 비밀번호, 소셜 로그인, 전화번호 인증을 제공한다.
붙이는 감각이 다르다.

Firebase는 클라이언트 SDK가 인증 상태를 들고 있고, 그 상태로 데이터베이스 규칙이 평가된다.
규칙은 별도 문법으로 작성한다.
모바일 앱에서는 로그인 흐름과 오프라인 캐시가 같은 SDK 안에서 맞물린다.

Supabase는 인증된 사용자 정보가 데이터베이스 세션에 실리고, 접근 제어를 SQL 정책으로 쓴다. “이 행은 소유자만 읽는다” 같은 규칙을 테이블 옆에 두는 셈이라, 데이터 모델을 아는 사람이 그대로 작성할 수 있다.

전화번호 인증은 요금 항목이 따로 있다는 점도 확인할 대목이다.
Firebase 요금표에서는 SMS 발송 건당 과금으로 표기돼 있어, 전화 인증을 주 수단으로 쓰는 서비스라면 사용자 수와 별개로 계산해야 한다.

마이그레이션을 염두에 둘 때

지금 고른 서비스에서 나중에 옮길 가능성을 계산에 넣는다면, 애플리케이션 코드가 특정 SDK에 얼마나 깊이 묶이는지가 관건이다.

데이터 접근을 한 층으로 감싸두면 나중에 바꿀 때 그 층만 고치면 된다.
화면 곳곳에서 SDK를 직접 부르면 전환 비용이 그만큼 커진다.
어느 쪽을 고르든 이 습관은 값이 있다.

자주 묻는 질문

Supabase와 Firebase 중 어느 쪽이 저렴한가요

사용 패턴에 달렸습니다.
Supabase는 월 $25부터의 고정 구독에 사용량이 붙어 예측이 쉽고, Firebase는 무료 한도 안에서는 비용이 없지만 읽기와 쓰기 건수로 계산돼 트래픽에 따라 변동이 큽니다.

Firebase에서 Supabase로 옮길 수 있나요

데이터를 옮기는 것은 가능하지만 문서형 구조를 관계형 스키마로 다시 설계해야 합니다.
클라이언트 SDK 호출부도 함께 고쳐야 하므로 단순한 이관 작업은 아닙니다.

오프라인 지원이 필요하면 어느 쪽인가요

Firestore SDK가 문서를 기기에 캐시해 오프라인 읽기와 쓰기를 지원하고 재연결 시 동기화합니다.
Supabase에서 같은 동작을 만들려면 클라이언트 쪽 캐시를 직접 설계해야 합니다.

자체 호스팅이 가능한 쪽은 어디인가요

Supabase는 오픈소스라 도커나 쿠버네티스 같은 도구로 직접 호스팅할 수 있습니다.
Firebase는 관리형 서비스로만 제공됩니다.

참고한 곳

• Supabase vs Firebase
• Supabase Pricing
• Firebase 공식 홈
• Firebase 가격 책정