Supabase vs Firebase: 프로젝트별 선택 기준

BaaS 양대 산맥

Backend as a Service 시장에서 Firebase는 오랜 강자입니다. 그런데 최근 Supabase가 빠르게 치고 올라오고 있죠. 둘 다 인증, 데이터베이스, 스토리지를 제공하지만, 철학이 다릅니다.

Firebase는 NoSQL(Firestore) + 독자 생태계, Supabase는 PostgreSQL + 오픈소스입니다. 이 차이가 프로젝트 선택에 결정적예요.

데이터베이스: NoSQL vs SQL

Firestore는 문서 기반 NoSQL예요. 데이터를 읽는 패턴이 정해져 있다면 빠릅니다. 하지만 복잡한 JOIN이나 집계 쿼리가 필요하면 곤란해집니다.

Supabase는 PostgreSQL입니다. SQL의 모든 기능을 쓸 수 있어요. JOIN, 서브쿼리, 윈도우 함수, 트리거까지. 데이터 간 관계가 복잡한 프로젝트에는 Supabase가 압도적으로 유리합니다.

sql

-- Supabase: SQL로 복잡한 쿼리 가능
SELECT 
  u.name,
  COUNT(o.id) as order_count,
  SUM(o.amount) as total_spent
FROM users u
JOIN orders o ON u.id = o.user_id
WHERE o.created_at > NOW() - INTERVAL '30 days'
GROUP BY u.id
HAVING SUM(o.amount) > 100000
ORDER BY total_spent DESC;

이런 쿼리를 Firestore에서 하려면 클라이언트에서 여러 번 조회하고 직접 합쳐야 합니다. 비용도 문제지만 코드 복잡도가 크게 올라갑니다.

인증 비교

인증은 둘 다 잘 되어 있죠. Google, Apple, GitHub 소셜 로그인, 이메일/비밀번호, 매직 링크 모두 지원합니다.
차이가 나는 건 커스터마이징예요. Firebase는 Custom Claims로 역할을 넣을 수 있고, Supabase는 RLS(Row Level Security)와 직접 연동됩니다. Supabase의 RLS는 DB 레벨 보안이라 API를 우회해도 안전합니다.

실시간 기능

Firebase의 실시간 리스닝은 네이티브 수준입니다. Firestore snapshot listener를 달면 데이터 변경이 즉시 푸시돼요. 이 부분은 Firebase가 확실히 앞서 있어요.

Supabase도 Realtime을 지원하지만 PostgreSQL의 LISTEN/NOTIFY 기반이라 Firebase만큼 매끄럽지는 않습니다. 채팅, 협업 에디터 같은 실시간 앱이라면 Firebase가 더 적합합니다.

비용 구조

Firebase는 읽기/쓰기 횟수 기반 과금예요. 트래픽이 예측 불가능하면 비용이 급증 가능하죠. 특히 Firestore의 문서 읽기 비용이 누적되면 놀랄 수 있겠죠.

Supabase는 스토리지 + 대역폭 기반입니다. 프리 티어가 넉넉하고(500MB DB, 1GB 스토리지), 유료 플랜도 예측 가능한 월정액 구조입니다. 소규모 프로젝트에서는 Supabase가 비용 효율적입니다.

선택 기준 정리

Firebase를 선택하세요:
- 실시간 기능이 핵심인 앱 (채팅, 협업)
- Firebase 생태계(FCM, Crashlytics, Analytics)를 이미 쓰고 있을 때
- 빠른 프로토타이핑이 목적일 때

Supabase를 선택하세요:
- 데이터 관계가 복잡한 서비스 (e-commerce, CMS)
- SQL이 익숙하거나, 복잡한 쿼리가 필요할 때
- 벤더 종속을 피하고 싶을 때 (오픈소스, 셀프 호스팅 가능)
- 비용 예측이 중요할 때

결론은 '프로젝트 성격에 따라 다르다'입니다. 둘 다 훌륭한 BaaS이고, 어느 쪽을 선택해도 프로덕션 수준의 백엔드를 빠르게 구축할 수 있죠. 중요한 건 자기 프로젝트의 데이터 구조와 쿼리 패턴을 먼저 파악하는 겁니다.