2026년 Supabase vs Firebase: 프로덕션에서 둘 다 써본 사람의 솔직한 비교

2026년에 SaaS, 모바일 앱, 사이드 프로젝트를 만들고 있다면 결국 이 갈림길에 서게 돼요. Supabase냐 Firebase냐?

인터넷엔 가벼운 비교 글이 넘쳐나죠. "Supabase는 오픈소스 Firebase!" "Firebase가 실시간은 더 좋다!" "Supabase는 그냥 Postgres잖아!" 이런 한 줄짜리 요약은 도움이 안 될 뿐 아니라 오히려 오해를 만들어요. 현실은 훨씬 복잡하고, 잘못된 선택은 몇 달의 마이그레이션 작업이나 수십만 원의 예상치 못한 요금으로 돌아올 수 있거든요.

이 글은 좀 달라요. 두 플랫폼 모두 프로덕션에서 써봤어요. 토이 프로젝트가 아니라 실제 서비스, 실제 유저, 실제 청구서가 있는 환경에서요. 진짜 중요한 것들만 비교할 거예요: 데이터베이스 아키텍처, 인증, 실시간, 파일 스토리지, 엣지 함수, 규모별 요금, 벤더 락인, 개발 경험.

스폰서 없고 제휴 링크도 없어요. 각 플랫폼이 진짜 잘하는 것과 진짜 아픈 곳을 솔직하게 풀어볼게요.

근본적인 차이: SQL vs NoSQL

다른 건 다 제쳐두고, 이것부터 이해해야 해요: 데이터베이스 선택이 모든 걸 결정해요. 기능 비교가 아니라 세계관의 차이예요.

Firebase는 Firestore 위에 만들어졌어요. 서버리스 NoSQL 문서 데이터베이스로, 데이터를 중첩된 JSON 같은 문서(Document)로 컬렉션에 저장해요. 조인도 없고, 외래 키도 없고, 스키마 강제도 없어요. 데이터를 읽는 방식에 맞춰 모델링하는 거예요.

Supabase는 PostgreSQL 위에 만들어졌어요. 세계에서 가장 인기 있는 오픈소스 관계형 데이터베이스죠. 테이블, 컨럼, 외래 키, 조인, 제약 조건, 뷰, 스토어드 프로시저 등 관계형 모델의 모든 것이 있어요. 데이터가 어떻게 관계되는지로 모델링하고, 필요한 대로 쿼리하는 거예요.

이 하나의 차이가 나머지 전부에 파급돼요:

항목	Firebase (Firestore)	Supabase (PostgreSQL)
데이터 모델	문서 & 컬렉션	테이블 & 관계
쿼리 언어	Firestore SDK 메서드	SQL (+ SDK 헬퍼)
조인	미지원 (비정규화 필요)	네이티브 지원
스키마 강제	없음 (스키마리스)	완전 지원 (마이그레이션)
집계 함수	제한적 (count, sum, avg)	SQL 집계 완전 지원
전문 검색	미지원	내장 (`tsvector`)
트랜잭션	멀티 문서, 제한적	완전한 ACID
데이터 무결성	앱 레벨 강제	DB 레벨 제약 조건

이게 왜 생각보다 중요하냐면: 데이터가 관계형이면(유저 → 주문 → 상품 → 리뷰) Firestore에서는 비정규화를 해야 해요. 조인이 없으니 문서 여기저기에 데이터를 복제하게 되죠. 문제는 유저 이름 하나 바꿀 때예요. 그 이름이 복사된 모든 곳을 찾아서 업데이트해야 하거든요. Postgres에서는 한 행만 고치면 끝이에요.

반대로, 데이터가 계층적이면(채팅 메시지, 소셜 피드, IoT 센서 데이터) Firestore의 문서 모델이 진짜 더 심플할 수 있어요. ORM 필요 없고, 마이그레이션 필요 없고, 스키마 파일도 없으니까요.

2026년의 반전: Firebase Data Connect. Google이 Firebase Data Connect를 출시했어요(2025년 4월 GA). Cloud SQL을 통해 PostgreSQL을 Firebase 생태계에 통합한 거예요. NoSQL만으로는 부족했다는 걸 사실상 인정한 셈이죠. Firestore를 대체하는 건 아니지만, Firebase에 항상 부족했던 관계형 데이터의 빈자리를 채워줘요.

인증: 둘 다 훌륭하지만 미묘한 차이가 있어요

인증은 두 플랫폼 다 진짜 잘해요. 근데 디테일에서 갈려요.

Firebase Auth

Firebase Auth는 이미 충분히 검증된 서비스예요. 복잡한 인증 시나리오도 잘 소화해요:

// Firebase Auth — 소셜 로그인
import { getAuth, signInWithPopup, GoogleAuthProvider } from 'firebase/auth';

const auth = getAuth();
const provider = new GoogleAuthProvider();

const result = await signInWithPopup(auth, provider);
const user = result.user;
// user.uid, user.email, user.displayName — 바로 사용 가능

강점:

20개 이상의 인증 제공자 기본 지원 (Google, Apple, Facebook, GitHub, Microsoft, 전화 등)
익명 인증 (온보딩 플로우에 유용)
이메일 링크(비밀번호 없는) 인증
Firebase UI — 드롭인 방식의 인증 UI 컴포넌트
다른 Firebase 서비스와의 깊은 통합

주의할 점:

커스텀 클레임이 제한적이고 설정하려면 Admin SDK가 필요
내장 RBAC 없음 — 커스텀 클레임 + Security Rules로 직접 구현해야 해요
멀티테넌시는 Identity Platform(유료)이 필요
유저 메타데이터가 제한적이라 프로필은 별도 Firestore 문서로 관리해야 해요

Supabase Auth (GoTrue)

Supabase Auth도 크게 성장해서 이제 Firebase에 맞먹어요:

// Supabase Auth — 소셜 로그인
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(SUPABASE_URL, SUPABASE_ANON_KEY);

const { data, error } = await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: { redirectTo: 'https://yourapp.com/callback' },
});
// 리디렉트 후, 세션이 자동으로 관리됨

강점:

OAuth 제공자 (Google, Apple, GitHub, Discord, Slack 등)
Row Level Security(RLS) 내장 — 인증이 DB 권한과 직접 연동
유저 데이터가 auth.users 테이블에 있어서 SQL로 쿼리 가능
매직 링크, 전화 OTP, SAML, SSO (Team/Enterprise)
RLS 정책에서 auth.uid()를 직접 참조 가능 — 미들웨어 불필요

주의할 점:

Firebase보다 기본 제공자 수가 적어요 (~15개 vs 20+개)
익명 인증에 해당하는 기능이 없어요 (우회는 가능하지만 네이티브가 아님)
리디렉트 기반 OAuth 플로우가 Firebase의 팝업 방식보다 살짝 불편할 수 있어요
SAML/SSO는 Team($599/월) 이상에서만 가능

진짜 차이: 인가(Authorization)

여기서 진짜 갈리기 시작해요. 인증(너 누구?)은 거의 동급인데, **인가(뭘 할 수 있어?)**에서 확 벌어져요.

Firebase는 Security Rules라는 커스텀 DSL을 써요:

// Firestore Security Rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /posts/{postId} {
      allow read: if true;
      allow create: if request.auth != null;
      allow update, delete: if request.auth.uid == resource.data.authorId;
    }

    match /users/{userId}/private/{doc} {
      allow read, write: if request.auth.uid == userId;
    }
  }
}

Supabase는 **Row Level Security(RLS)**라는 PostgreSQL 네이티브 정책을 써요:

-- Supabase RLS 정책
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

-- 누구나 읽기 가능
CREATE POLICY "누구나 포스트 읽기 가능"
  ON posts FOR SELECT
  USING (true);

-- 인증된 유저만 작성 가능
CREATE POLICY "인증 유저만 작성 가능"
  ON posts FOR INSERT
  WITH CHECK (auth.uid() = author_id);

-- 작성자만 수정/삭제 가능
CREATE POLICY "작성자만 수정 가능"
  ON posts FOR UPDATE USING (auth.uid() = author_id)
  WITH CHECK (auth.uid() = author_id);

CREATE POLICY "작성자만 삭제 가능"
  ON posts FOR DELETE
  USING (auth.uid() = author_id);

결과적으로 같은 걸 하는데, Supabase 쪽이 구조적으로 유리해요. RLS 정책은 데이터베이스 레벨에서 강제되거든요. 앱에서 쿼리하든, 크론잡에서 돌리든, 마이그레이션 스크립트에서 접근하든, 직접 SQL 연결하든 전부 같은 보안 검사를 통과해야 해요. Firebase Security Rules는 Firestore SDK 접근만 보호하고, Admin SDK로 Cloud Function에서 접근하면 규칙이 그냥 우회돼요.

2026년에는 여기서 한발 더 나갔어요. 새 테이블은 RLS가 기본 활성화고, RLS 없는 테이블에는 대시보드에 보안 경고가 뜨고요. 퍼블리셔블 키(스코프 지정, 로테이션, GitHub 유출 시 자동 폐기)가 포함된 새 API 키 시스템도 나왔어요.

실시간: Firebase의 왕관

솔직하게 말할게요: 실시간은 Firebase가 여전히 압도적이에요.

Firebase 실시간

Firestore의 실시간 리스너는 매끄럽고 깊이 통합돼 있어요:

// Firebase — 실시간 리스너
import { onSnapshot, collection, query, where, orderBy } from 'firebase/firestore';

const q = query(
  collection(db, 'messages'),
  where('roomId', '==', currentRoomId),
  orderBy('createdAt', 'desc')
);

const unsubscribe = onSnapshot(q, (snapshot) => {
  snapshot.docChanges().forEach((change) => {
    if (change.type === 'added') {
      console.log('새 메시지:', change.doc.data());
    }
    if (change.type === 'modified') {
      console.log('수정됨:', change.doc.data());
    }
    if (change.type === 'removed') {
      console.log('삭제됨:', change.doc.id);
    }
  });
});

왜 좋냐면:

오프라인 퍼스트가 기본 — 인터넷 없이도 작동하고, 재연결되면 자동 동기화
자동 충돌 해소
세밀한 변경 타입 (added, modified, removed)
웹, iOS, Android, Flutter 전부 네이티브 SDK 지원
낙관적 UI 업데이트 내장

이게 Firebase의 킬러 피처예요. 채팅, 협업 도구, 라이브 대시보드, 멀티플레이어 경험에서 Firebase의 실시간은 진짜 넘기 힘든 장벽이에요.

Supabase 실시간

Supabase Realtime은 PostgreSQL의 논리적 리플리케이션 위에 있어요:

// Supabase — 실시간 리스너
const channel = supabase
  .channel('messages-room')
  .on(
    'postgres_changes',
    {
      event: '*',
      schema: 'public',
      table: 'messages',
      filter: `room_id=eq.${currentRoomId}`,
    },
    (payload) => {
      console.log('변경 수신:', payload);
    }
  )
  .subscribe();

Firebase 대비 부족한 점:

오프라인 퍼스트 없음. 연결 끊기면 이벤트를 놓쳐요. 재연결 + 따라잡기 로직을 직접 구현해야 해요.
자동 충돌 해소 없음. 두 유저가 같은 행을 동시에 수정하면 마지막 쓰기가 이김.
낙관적 UI 없음. 앱 로직에서 직접 구현해야 해요.

Supabase가 따라잡는 점:

Broadcast(Pub/Sub)와 Presence(접속 상태) 채널도 지원
RLS가 실시간 구독에도 적용 — 보안 이점
크론잡이나 마이그레이션에서 데이터 변경해도 실시간 이벤트가 발생

정리하면: 실시간이 앱의 핵심 기능이면(채팅, 협업, 라이브 게이밍) Firebase가 아직도 나은 선택이에요. 실시간이 있으면 좋은 부가 기능이면(알림, 대시보드 라이브 업데이트) Supabase로 충분해요.

파일 스토리지

Firebase Cloud Storage

import { getStorage, ref, uploadBytes, getDownloadURL } from 'firebase/storage';

const storage = getStorage();
const storageRef = ref(storage, `avatars/${userId}/profile.jpg`);

await uploadBytes(storageRef, file);
const url = await getDownloadURL(storageRef);

대용량 파일 이어올리기 지원
Security Rules로 접근 제어
Google Cloud Storage 기반 (사실상 무한 확장)
CDN 기반 다운로드 URL

Supabase Storage

const { data, error } = await supabase.storage
  .from('avatars')
  .upload(`${userId}/profile.jpg`, file, {
    cacheControl: '3600',
    upsert: true,
  });

const { data: { publicUrl } } = supabase.storage
  .from('avatars')
  .getPublicUrl(`${userId}/profile.jpg`);

이미지 변환 내장 — 리사이즈, 크롭, 포맷 변환을 별도 서비스 없이 바로 가능
RLS 정책으로 접근 제어 (DB와 동일한 보안 모델)
S3 호환 API — 이탈이 쉬움
TUS 프로토콜로 이어올리기 지원

이점: Supabase. 내장 이미지 변환만으로도 Cloudinary나 Imgix 같은 서비스를 안 붙여도 돼요. Firebase에서 변환하려면 Extensions(Cloud Functions)가 필요해요.

엣지 함수 / 서버리스

Firebase Cloud Functions

// Firebase Cloud Function (2세대)
import { onDocumentCreated } from 'firebase-functions/v2/firestore';
import { onRequest } from 'firebase-functions/v2/https';

export const onNewPost = onDocumentCreated('posts/{postId}', async (event) => {
  const data = event.data?.data();
  // 알림 전송, 카운터 업데이트 등
});

export const api = onRequest(async (req, res) => {
  res.json({ status: 'ok' });
});

트리거: Firestore, Auth, Storage, Pub/Sub, Scheduler, HTTP
2세대 함수는 Cloud Run 기반
Node.js, Python 런타임
콜드 스타트: ~500ms-2s (min instances로 개선 가능)
Firebase AI Logic — 2026년 신기능, Gemini 모델 직접 통합

Supabase Edge Functions

// Supabase Edge Function
import { serve } from 'https://deno.land/std/http/server.ts';
import { createClient } from 'https://esm.sh/@supabase/supabase-js';

serve(async (req) => {
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!,
  );

  const { data } = await supabase.from('users').select('*').limit(10);

  return new Response(JSON.stringify(data), {
    headers: { 'Content-Type': 'application/json' },
  });
});

글로벌 분산, 엣지에서 실행돼서 유저와 가까움
Deno 런타임 (TypeScript 네이티브, 빌드 스텝 없음)
콜드 스타트: 평균 ~42ms (Deno 2 업그레이드 이후 97% 단축, Firebase보다 훨씬 빠름)
무료 tier에서 월 500K 호출
Firestore 스타일 트리거 없음 (DB 웹훅이나 pg_notify 사용)

핵심 차이: Firebase Cloud Functions는 네이티브 트리거가 더 풍부하고, Supabase Edge Functions는 속도에서 이기지만(엣지 배포, Deno 런타임) 이벤트 기반 패턴을 직접 연결해줘야 해요.

요금: 꿈이 깨지는 곳

여기서부터 비교가 아파지기 시작해요. 두 플랫폼 다 겉보기엔 심플한데 속에 복잡성이 숨어 있어요.

Firebase 요금

Firebase는 프로덕션용으로 Blaze 플랜(종량제)을 사용해요:

Firebase Blaze — 주요 비용:

Firestore:
  읽기:   10만 문서당 $0.06   (100만당 $0.60)
  쓰기:   10만 문서당 $0.18   (100만당 $1.80)
  삭제:   10만 문서당 $0.02   (100만당 $0.20)
  저장:   GB당 월 $0.108

Cloud Functions:
  호출:    100만당 $0.40
  컴퓨팅:  GB-second당 $0.00001667
  네트워크: 아웃바운드 GB당 $0.12

Cloud Storage:
  저장:    GB당 월 $0.026
  다운로드: GB당 $0.12

인증:
  대부분 무료
  전화 인증: SMS당 $0.01-0.06

요금 함정 — 읽기 증폭(Read Amplification):

Firebase 개발자를 가장 놀라게 하는 거예요. 페이지 로드 한 번에 수백 건의 문서 읽기가 발생할 수 있어요:

유저가 대시보드를 열면:
  - 유저 프로필 가져오기:          1 읽기
  - 최근 포스트 20개 가져오기:     20 읽기
  - 각 포스트 작성자 정보:         20 읽기 (조인이 없으니까!)
  - 좋아요 수:                    20 읽기
  - 댓글 수:                      20 읽기
  - 유저 알림:                    10 읽기
  ---
  합계: 페이지 로드 하나에 91 읽기

Firestore에는 조인이 없으니, SQL 하나로 될 걸 여러 쿼리로 쪼개야 해요. 100만 읽기당 $0.60이니까 빠르게 불어나요. DAU 10,000명이 하루 10 페이지씩 열면 **~910만 읽기/일**, **~2.73억 읽기/월**이에요. **읽기만으로 월 ~$ 164**이라는 뜻.

Supabase 요금

Supabase Plans:

Free:     월 $0
  - 프로젝트 2개 (7일 비활성시 일시정지)
  - DB 500MB, 파일 스토리지 1GB
  - MAU 50K, Edge Function 500K 호출
  - 이그레스 2GB

Pro:      월 $25 + 사용량
  - DB 8GB, 파일 스토리지 100GB
  - MAU 100K
  - Edge Function 무제한
  - 월 $10 컴퓨트 크레딧 포함
  - 프로젝트 일시정지 없음

Team:     월 $599
  - SSO, 감사 로그, 우선 지원

Enterprise: 커스텀
  - HIPAA, SLA, 전용 인프라

Supabase 요금 함정 — 컴퓨트 애드온:

Pro $25/월이 좋아 보이는데, 가장 작은 컴퓨트 인스턴스가 딸려와요. 프로덕션 워크로드에는 컴퓨트를 추가해야 해요:

컴퓨트 애드온 (월, $10 크레딧 적용 전):
  Micro  (공유 CPU, 1GB RAM):             ~$10 (크레딧으로 커버)
  Small  (2코어 ARM, 2GB RAM):            ~월 $15
  Medium (2코어 ARM, 4GB RAM):            ~월 $60
  Large  (2코어 ARM 전용, 8GB RAM):       ~월 $110
  XL     (4코어 ARM 전용, 16GB RAM):      ~월 $210

현실적인 프로덕션 세팅은 Pro( $25) + Medium 컴퓨트(~$ 60) = **~월 $85**.$ 10 크레딧이 작은 인스턴스를 커버해주긴 하지만, 실 워크로드에서는 Medium 이상이 필요할 거예요.

MAU 함정: Pro에서 MAU 10만 명을 넘기면 **1,000명당 $3.25**의 초과 요금이 발생해요. MAU 20만 명이면 인증만으로 월$ 325가 추가돼요.

규모별 요금 비교

DAU 50,000명짜리 현실적인 SaaS를 모델링해 보면:

시나리오: SaaS — DAU 50,000, MAU ~150K

Firebase (Blaze):
  Firestore 읽기:  ~1.5억/월      = ~$90
  Firestore 쓰기:  ~1,500만/월    = ~$27
  Firestore 저장:  10GB           = ~$1.08
  Cloud Functions: 500만 호출     = ~$2
  Cloud Storage:   50GB + 200GB   = ~$25.30
  Auth:            무료 (이메일)
  ─────────────────────────────────
  예상 합계:                       ~$145/월

Supabase (Pro):
  기본 플랜:                       = $25
  컴퓨트 (Medium):                 = ~$60
  DB 저장: 10GB (포함)             = $0
  파일 스토리지: 50GB (포함)       = $0
  이그레스: ~200GB (250GB 이내)    = $0
  MAU: 150K (50K 초과 × $3.25)    = ~$162.50
  ─────────────────────────────────
  예상 합계:                       ~$247.50/월

생각보다 차이가 크지 않죠? 이 시나리오에서는 Firebase가 아직 더 싸긴 해요. Supabase의 MAU 기반 인증 요금이 크게 작용하거든요. 근데 페이지당 읽기 수를 늘리거나(비정규화하면 흔한 일) 복잡한 쿼리를 몇 개만 추가하면 숫자가 금방 뒤집혀요.

솔직한 답: 어느 쪽이 일관되게 싸지는 않아요. 읽기/쓰기 패턴, 유저 수, 사용 기능에 따라 완전히 달라져요. 반드시 본인의 워크로드를 모델링해 봐야 해요.

벤더 락인: 탈출구

비교 글들이 대충 넘어가는데, 사실 가장 중요한 주제 중 하나예요.

Firebase 락인

직설적으로 말할게요: Firebase 락인은 상당해요.

Firestore는 표준 쿼리 언어가 없어요. Firebase SDK 메서드로 쿼리하니까, Postgres나 MongoDB로 옮기려면 모든 데이터 접근 코드를 다시 써야 해요.
Firestore 데이터 모델(문서/컬렉션)이 테이블 구조로 깔끔하게 매핑이 안 돼요. 마이그레이션에 데이터 재구조화가 필요해요.
Security Rules는 독점적이에요. 다른 플랫폼으로 가면 인가 로직 전체를 새로 만들어야 해요.
Cloud Functions 트리거(onDocumentCreated 등)는 Firebase 전용이에요. AWS Lambda나 Cloudflare Workers로 옮기면 이벤트 로직 재작성이 필요해요.

Firebase에서 나오는 건 중간 복잡도 앱 기준 보통 3-6개월 프로젝트예요.

Supabase 락인

Supabase의 락인 상황은 근본적으로 달라요:

PostgreSQL이 데이터베이스예요. 데이터, 스키마, 함수, 트리거, RLS 정책 전부 표준 Postgres예요. pg_dump로 추출해서 아무 Postgres 호스트에 복원할 수 있어요(AWS RDS, Neon, Railway, 자체 서버 등).
Edge Functions는 Deno 위에서 돌아가고, 표준 런타임이라 코드가 대체로 이식 가능해요.
**Auth(GoTrue)**가 오픈소스예요. 직접 호스팅할 수도 있어요.

정리: Supabase의 락인은 회복 가능(몇 주 작업). Firebase의 락인은 구조적(몇 달 작업). 탈출 전략이 중요하다면, 이건 결정적인 차이예요.

2026년 개발 경험

Firebase DX

Firebase Console — 깔끔하고 탐색하기 쉬움, 비개발 팀원도 사용 가능
Emulator Suite — Firestore, Auth, Functions 로컬 에뮬레이션
Firebase Extensions — Stripe, Algolia, SendGrid 등 사전 구축 통합
Firebase AI Logic — 2026년 신기능, Gemini 클라이언트-사이드 AI
FlutterFire — 퍼스트 클래스 Flutter 지원

아쉬운 점: Firestore 쿼리 제한 때문에 데이터 모델링을 다시 생각해야 하고, Security Rules 문법이 처음엔 좀 어렵고, SQL 직접 접근 불가 (Data Connect가 PostgreSQL을 지원하긴 하지만 별도 제품)

Supabase DX

SQL 에디터 — 대시보드에서 바로 쿼리, RLS 관리, 실시간 인스펙터
CLI — 로컬 개발, 마이그레이션, 타입 제너레이션, 시드 데이터
자동 TypeScript 타입 — DB 스키마에서 타입을 생성, 모든 쿼리가 타입 체크됨
데이터베이스 브랜칭 — PR용 프리뷰 DB 생성 (Team/Enterprise)
Claude 연결 — 자연어로 DB 관리

아쉬운 점: SQL/Postgres 학습 곡선이 더 가파름, Edge Functions가 Deno 기반이라 Node.js 라이브러리 호환성 이슈, 실시간에 오프라인 지원 없음

TypeScript 체험 차이

Firebase:

// 수동으로 타입 정의 필요
interface Post {
  title: string;
  content: string;
  authorId: string;
  createdAt: Timestamp;
}

const postRef = doc(db, 'posts', postId) as DocumentReference<Post>;
const postSnap = await getDoc(postRef);
const post = postSnap.data(); // Post | undefined

Supabase:

// CLI가 자동 생성한 타입
import { Database } from './database.types';

const supabase = createClient<Database>(url, key);

const { data } = await supabase
  .from('posts')
  .select('*, author:users(name, avatar)')
  .eq('published', true);
// data는 완전히 타입됨: { title: string, content: string, author: { name: string, avatar: string } }[]

supabase gen types typescript 한 번이면 DB 스키마 전체가 TypeScript 타입이 돼요. Select, insert, update 전부 실제 스키마 기반으로 타입 체크돼요.

언제 뭘 고를까

Firebase를 고를 때:

실시간 동기화가 핵심 기능일 때. 채팅, 협업 에디터, 라이브 게이밍 — Firebase의 오프라인 퍼스트 실시간은 진짜 뛰어나요.
모바일 퍼스트 앱일 때. iOS, Android, Flutter 네이티브 SDK가 더 성숙하고 깊이 통합돼 있어요.
팀이 SQL에 익숙하지 않을 때. Firestore 문서 모델이 프론트엔드 개발자한테 더 쉬워요.
Google 생태계를 쓰고 있을 때. GCP, BigQuery, Vertex AI 등과 매끄럽게 통합돼요.
데이터가 계층적일 때. IoT 센서, 채팅 스레드, 소셜 피드 — 자연스럽게 중첩되는 데이터라면 Firestore가 더 심플할 수 있어요.

Supabase를 고를 때:

데이터가 관계형일 때. 유저, 주문, 상품, 리뷰 — 엔티티 간 참조가 있으면 PostgreSQL이 네이티브로 깔끔하게 처리해요.
SQL의 파워가 필요할 때. 복잡한 집계, 윈도우 함수, CTE, 전문 검색, JSONB, 물리화 뷰 — Postgres의 풀 도구상자를 쓸 수 있어요.
타입 안전성이 중요할 때. 스키마에서 자동 생성되는 TypeScript 타입으로 버그를 한 카테고리 통째로 없앨 수 있어요.
탈출 전략이 중요할 때. Postgres니까 언제든 떠날 수 있어요.
이미지 변환이 필요할 때. 서드파티 서비스 없이 리사이즈, 크롭, 포맷 변환이 내장돼 있어요.

하이브리드 접근법

아무도 잘 얘기 안 하는 건데, 둘 다 쓰는 팀도 있어요.

Supabase로 관계형 코어 (유저, 주문, 상품, 비즈니스 데이터)
Firebase로 실시간 기능 (채팅, 알림, 라이브 업데이트)

운영 복잡성이 늘어나지만, 맞는 유스케이스에서는 양쪽의 장점을 다 가져갈 수 있어요.

비교 글이 안 다루는 것: 지속 가능성

Firebase는 Google이 뒤에 있어요. GCP 개발자 유입 전략의 일부예요. 안정적이지만, Google 특유의 제품 중단 역사(GCM, Firebase Predictions, Fabric 등)를 기억해야 해요.

Supabase는 VC 투자를 받았어요 (~$116M+). 오픈소스 코어가 성장 엔진이고 유료 플랜이 수익 모델이에요. 리스크는 있지만 오픈소스이므로, 회사가 방향을 바꿔도 데이터가 갇히지는 않아요.

앞으로의 전망: 수렴

Firebase는 Data Connect로 SQL 쪽으로 움직이고, AI Logic으로 Gemini를 통합하며, Firestore Enterprise Edition에 파이프라인 연산을 추가하고 있어요.

Supabase는 더 나은 실시간, AI 통합(pgvector 기반 벡터 검색, Claude 연결), 플랫폼 완성도(Stripe Sync, 인증 개선, DB 브랜칭)를 향해 가고 있어요.

둘 다 상대의 강점을 향해 수렴하고 있어요. 5년 후에는 격차가 더 줄어 있을 거예요. 하지만 지금은 아직 차이가 충분히 중요해요.

결론

불편한 진실 하나: 어느 쪽을 골라도 나쁜 선택은 아니에요. Firebase든 Supabase든 프로덕션 준비된 플랫폼이고 각자의 진짜 강점이 있어요.

한 문장으로 정리하면:

Firebase는 작동하는 앱까지의 가장 빠른 길. Supabase는 유지보수 가능한 앱까지의 가장 강력한 길.

Firebase는 특히 실시간이나 모바일 퍼스트 앱에서 제로부터 배포까지가 빨라요. 배우기 쉽고 생태계도 잘 갖춰져 있어요. 다만 데이터가 복잡해지면 SQL이 없는 게 아쉬워지기 시작해요.

Supabase는 초기 투자가 더 많이 들어요(스키마, SQL, RLS 정책). 근데 그 투자가 복리로 돌아와요. 타입 안전한 쿼리, 외래 키, 마이그레이션으로 관리되는 스키마가 앱이 커지면서 빛을 발해요. 그리고 떠나야 할 때, 떠날 수 있고요.

진짜 조언? 팀이 아는 데이터베이스로 시작하세요. SQL을 아는 팀이면 Supabase. 문서를 아는 팀이면 Firebase. BaaS 레이어보다 데이터 모델이 더 오래 남으니까요.

좋은 거 만들고, 빨리 배포하고, 진짜 문제를 풀어가세요.