Supabase vs Firebase (2026): AI 앱 백엔드로 무엇을 선택해야 할까

앱이 데이터 중심이고 SQL을 쓰고 싶으며 언젠가 떠날 가능성이 있다면 Supabase를 선택하십시오. 실시간 모바일 앱을 출시하는 중이고 첫날부터 결제 설정에 시간을 쓰고 싶지 않다면 Firebase를 선택하십시오. 나머지는 전부 비용 계산과, 두 서비스가 각각 부딪히는 두 개의 벽에 관한 이야기입니다.

둘 다 "backend-as-a-service"입니다. 데이터베이스, 인증, 파일 저장소, API를 대신 관리해 주기 때문에 서버를 직접 띄울 일이 없습니다. 공통점은 거기까지입니다. 두 서비스는 데이터를 근본적으로 다른 형태로 저장하고, 정반대의 모델로 요금을 매기며, 한쪽은 언제든 떠날 수 있지만 다른 한쪽은 사실상 떠날 수 없습니다. 2026년의 AI 앱에서는 이 세 가지 차이가 어떤 기능 체크리스트보다 더 큰 결정을 좌우합니다.

먼저 짧은 결론을 보고, 그다음에 그 결론을 뒷받침하는 계산을 살펴보겠습니다.

무엇을 만드느냐에 따른 결론

앱이 대부분 서로 연결된 테이블(사용자, 주문, 게시글, 댓글)로 이루어져 있고 SQL을 쓰거나 읽을 수 있다면 Supabase 위에 만드십시오. 진짜 PostgreSQL 데이터베이스를 받게 되므로 조인, 트랜잭션, 그리고 잘못된 데이터를 입구에서 막아 주는 스키마를 쓸 수 있습니다. 게다가 오픈소스이기 때문에, 호스팅 플랜이 감당이 안 되는 날이 오면 데이터베이스 전체를 그대로 들고 나가 어디서든 돌릴 수 있습니다. 그 비상구의 가치는 대부분의 창업자가 실제로 필요해지기 전까지는 잘 실감하지 못합니다.

앱의 핵심 기능이 기기 간에 살아 있는 상태를 동기화하는 것이라면(채팅 앱, 협업 도구, 오프라인에서도 즉각적으로 느껴져야 하는 모든 것) Firebase 위에 만드십시오. Firestore의 실시간 동기화와 오프라인 지속성은 여전히 업계 기준이며, 신용카드를 입력하지 않고도 출시할 수 있습니다. 대가는 구글의 조건으로 구글에게서 빌려 쓴다는 점, 그리고 요금이 작업 단위로 측정된다는 점입니다. 팀들이 바로 여기서 예상치 못한 상황을 맞습니다.

아래 내용은 이 두 가지 판단이 실제 가격, 실제 AI 기능, 그리고 프로덕션에 들어간 뒤 승부를 가르는 함정들 앞에서 어떻게 버티는지에 대한 것입니다.

실제로 선택을 가르는 단 하나의 기준

기능 목록을 걷어내면 두 서비스를 가르는 질문은 하나뿐입니다. 떠날 수 있는 데이터베이스를 소유하는가, 아니면 떠날 수 없는 서비스를 빌리는가?

Supabase는 대시보드를 얹은 PostgreSQL입니다. PostgreSQL은 지구상에서 가장 널리 배포된 오픈소스 관계형 데이터베이스이며, Supabase는 이를 포크하지도 감추지도 않습니다. 원본 연결 문자열을 그대로 받습니다. 언젠가 직접 운영하는 서버로, AWS로, 또는 다른 호스팅으로 옮기고 싶다면 표준 pg_dump를 실행하고 떠나면 됩니다. 당신의 데이터에는 독점적인 부분이 하나도 없습니다.

Firebase는 Firestore입니다. 구글 안에서만 존재하는 NoSQL 문서형 데이터베이스입니다. NoSQL이란 고정된 스키마가 없다는 뜻입니다. JSON에 가까운 문서를 저장하고, 데이터베이스는 문서들 사이의 관계를 강제하지 않습니다. 덕분에 초기 프로토타이핑이 빠릅니다. 테이블을 설계하려고 멈춰 설 일이 없기 때문입니다. 그러나 동시에 SQL이 없고, 진짜 조인이 없으며, 나중에 데이터를 다른 시스템으로 깔끔하게 내보낼 방법도 없다는 뜻입니다. 데이터 모델과 벤더가 같은 하나의 결정입니다. Firestore는 들고 나갈 수 없습니다.

대부분의 AI 앱에서는 답이 Supabase 쪽으로 기웁니다. AI 기능은 구조화되고 질의 가능한 데이터에 기대기 때문입니다. 사용자 테이블, 문서 테이블, 필터링하고 조인할 수 있는 임베딩 컬럼 같은 것들입니다. NoSQL로도 할 수는 있지만, SQL이 공짜로 주는 것을 애플리케이션 코드에서 다시 만들게 됩니다. 예외는 "기기 간 즉시 동기화" 자체가 제품일 때이며, 그것이 Firestore가 누구보다 잘하는 단 하나입니다.

:::callout{variant="note" title=""관계형"이 실무에서 주는 것"}
사용자가 계정을 삭제했고, 그 사용자가 만든 모든 댓글, 좋아요, 파일이 함께 사라져야 한다고 해봅시다. PostgreSQL에서는 한 번만 정의하는 규칙(연쇄 삭제가 걸린 외래 키)이면 되고, 데이터베이스가 그 규칙을 영원히 지켜 줍니다. Firestore에서는 관련 문서를 하나씩 찾아 지우는 코드를 직접 작성해야 하고, 경로 하나라도 빠뜨리면 고아 데이터가 쌓입니다. 관계형 데이터베이스는 "함께 속한 데이터는 일관성을 유지한다"를 당신의 일이 아니라 데이터베이스의 일로 만듭니다.
:::

가격, 거의 모두가 잘못 이해하는 부분

핵심은 월 요금이 아닙니다. 과금 모델입니다. Supabase는 고정 요금에 예측 가능한 초과 요금을 더해 청구하고, Firebase는 작업당 청구하므로 요금이 트래픽을 따라, 때로는 하룻밤 사이에 움직입니다.

Supabase: 계획을 세울 수 있는 고정된 숫자

Supabase Free는 $0이며 실제 서비스가 가능한 수준을 제공합니다. 월간 활성 사용자 50,000명, 500 MB 데이터베이스, 5 GB 아웃바운드 트래픽, 1 GB 파일 저장소입니다. 모두가 걸려 넘어지는 함정은 이것입니다. 무료 프로젝트는 1주일간 활동이 없으면 일시 중지되고, 활성 프로젝트는 2개로 제한됩니다. 일시 중지된 프로젝트란 클릭해서 복구할 때까지 데모가 멈춰 있다는 뜻입니다. 사이드 프로젝트라면 괜찮지만, 고객이 예고 없이 열어 볼 수 있는 것이라면 문제입니다.

Supabase Pro는 월 $25이며 첫 프로젝트가 포함되고, 추가 프로젝트는 월 $10부터입니다. 이 $25에는 100,000 MAU(초과분은 MAU당 $0.00325), 프로젝트당 8 GB 디스크(초과분은 $0.125/GB), 250 GB 아웃바운드 트래픽(초과분은 $0.09/GB), 100 GB 파일 저장소(초과분은 $0.0213/GB)가 포함됩니다. 월 $10의 컴퓨트 크레딧도 포함되는데, 작은 상시 가동 인스턴스 하나를 돌리기에 충분합니다. Team 플랜은 월 $599로 뛰며 주로 컴플라이언스(SOC2, ISO, SSO)를 추가합니다. 그 아래 단계라면 필요하지 않습니다.

개발자들이 이 모델을 좋아하는 이유는 이렇습니다. 사용자 수를 보면 요금을 알 수 있습니다. $25짜리 Pro는 실제 프로덕션 앱을 감당하고, 초과 요율이 충분히 낮아서 활성 사용자 10,000명에 데이터 몇 기가바이트 정도면 여전히 $25에서 $50 사이에 머뭅니다.

Firebase: 무료였다가 어느 순간부터 종량제

Firebase Spark는 진짜로 무료인 플랜이며, 가장 큰 장점은 결제 수단이 아예 필요 없다는 것입니다. Firestore는 저장 용량 1 GiB, 하루 읽기 50K회, 하루 쓰기 20K회, 하루 삭제 20K회, 월 10 GiB 아웃바운드 트래픽을 제공합니다. Authentication은 월간 활성 사용자 50K명, Realtime Database는 저장 용량 1 GB와 월 10 GB 다운로드를 제공합니다. 프로토타입이나 트래픽이 적은 앱이라면 카드 등록 없이 무기한 Spark에 머물면서 한 푼도 내지 않을 수 있습니다.

더 필요해지는 순간 종량제 플랜인 Blaze로 전환합니다(자격이 되면 구글이 $300의 무료 크레딧을 제공합니다). Blaze는 Spark의 무료 한도를 그대로 유지한 뒤 그 이상을 전부 측정합니다. Cloud Functions는 월 2M 호출까지 무료이고 이후 100만 건당 $0.40, Cloud Storage는 5 GB 초과분에 대해 저장 $0.026/GB, 하루 1 GB 초과 다운로드에 대해 $0.12/GB입니다. 일일 무료 한도를 넘긴 Firestore 읽기, 쓰기, 삭제는 Google Cloud 요금 체계에 따라 작업당 청구됩니다. Firebase는 이제 SQL Connect를 통한 관리형 PostgreSQL도 제공하는데, 3개월 무료 체험 후 월 $9.37 안팎에서 시작합니다. 결국 많은 사람이 SQL을 원한다는 조용한 인정인 셈입니다.

무료 플랜 정면 비교

둘 다 월간 활성 사용자 50,000명을 무료로 제공하며, 이는 거의 무엇이든 검증하기에 충분한 규모입니다. 차이는 두 개의 함정에 있습니다.

Supabase의 함정은 일시 중지입니다. 무료 프로젝트를 1주일간 놀려 두면 깨울 때까지 잠듭니다. 데모에는 성가시고, 실제 트래픽이 생겼거나 Pro로 옮긴 뒤에는 무의미해집니다.

Firebase의 함정은 업그레이드 절벽입니다. Spark는 카드 없이 진짜로 무료지만, 한도를 넘는 순간 종량제 과금으로 넘어가며 종량제는 설계상 예측이 불가능합니다. "고정 요금으로 조금만 더 달라"는 $25짜리 중간 단계가 없습니다. 무료에서 사용량 과금으로 한 번에 건너뜁니다.

그래서 무료 플랜에 대한 솔직한 결론은 이렇습니다. 끝내 수익화하지 않을 수도 있는, 부담 없는 프로토타입이라면 Firebase가 이깁니다. 카드도 없고 일시 중지도 없기 때문입니다. 프로젝트가 진짜가 되는 순간에는 Supabase가 이깁니다. 고정 $25가 "사용량을 재고 나서 보자"보다 낫기 때문입니다.

AI 앱을 만든다면: Supabase vs Firebase

바로 이 지점에서 2026년이 2022년과 실제로 달라지고, 대부분의 개발자에게 Supabase가 앞서 나갑니다. AI 앱은 보통 임베딩(텍스트의 수치 지문)을 저장하고 질의에 가장 가까운 항목을 찾아야 합니다. 그것이 벡터 검색이며, 검색(retrieval), 시맨틱 검색, 그리고 RAG(retrieval-augmented generation, 자신의 문서를 LLM에 먹이는 방식) 뒤에 있는 엔진입니다.

Supabase는 이를 pgvector로 네이티브 제공합니다. 벡터를 일반 데이터 바로 옆에 저장하고 인덱싱하는 PostgreSQL 확장입니다. 하나의 데이터베이스이기 때문에, 사용자 ID로 필터링하면서 동시에 벡터 유사도로 정렬하는 단일 쿼리를 실행할 수 있습니다. 두 번째 시스템도, 동기화도 필요 없습니다. Supabase의 AI 툴킷은 OpenAI와 Hugging Face 임베딩에도 곧바로 연결됩니다.

Firebase는 findNearest 쿼리를 통한 Firestore 벡터 검색으로 답합니다. 문서에 임베딩을 저장하고 Firestore를 벗어나지 않은 채 최근접 이웃을 가져올 수 있습니다. 작동합니다. 이미 Firestore에 깊이 들어가 있다면 두 번째 데이터베이스를 아껴 줍니다. 하지만 애초에 벡터를 염두에 두고 설계되지 않은 문서 저장소에서 벡터 연산을 하는 것이고, pgvector 쿼리를 그토록 깔끔하게 만들어 주는 SQL 필터링을 잃게 됩니다. AI 우선 앱이라면 pgvector가 더 자연스러운 집입니다.

1. 1

   Supabase에 임베딩 저장하기

   create extension vector;로 확장을 활성화하고, 테이블에 embedding vector(1536) 같은 컬럼을 추가한 뒤, 행의 일반 데이터 옆에 임베딩 배열을 넣습니다. 하나의 테이블이 콘텐츠와 그 벡터를 함께 담습니다.

2. 2

   가장 가까운 항목 질의하기

   벡터 거리 연산자(embedding <=> query_embedding)로 정렬하고 limit을 붙인 평범한 select를 실행합니다. 같은 쿼리 안에 일반적인 where user_id = ...를 넣을 수 있으므로, 유사도 검색과 접근 제어가 한 번의 왕복에서 처리됩니다.

3. 3

   빠른 속도를 유지하도록 인덱싱하기

   벡터 컬럼에 HNSW 인덱스를 추가합니다. 일반 인덱스가 일반 컬럼을 빠르게 만들어 주는 것과 똑같이, 테이블이 커져도 최근접 이웃 조회를 빠르게 유지해 줍니다.

인증, 실시간 동기화, 그리고 나머지

인증은 둘 다 잘 지원합니다. Firebase Auth가 더 성숙하며, 제공하는 공급자 목록이 길고 모바일 SDK가 가장 매끄럽습니다. "사용자를 로그인시키는 일"이 iOS와 Android에서 그냥 잘 돌아가야 한다면 훌륭한 선택입니다. Supabase Auth는 당신의 Postgres 데이터베이스 위에 구축되며 RLS(row-level security, 각 사용자가 자기 행만 읽고 쓸 수 있도록 데이터베이스 자체가 강제하는 기능)와 짝을 이룹니다. RLS는 Supabase에서 가장 먼저 익혀야 할 개념입니다. 모든 API 호출마다 권한 검사를 작성하지 않고도 다중 사용자 앱을 안전하게 만들어 주는 것이 바로 RLS이기 때문입니다.

실시간 동기화는 Firebase의 안방입니다. Firestore와 Realtime Database는 기기 간 상태를 동기화하고 오프라인을 우아하게 처리하며, 쓰기를 큐에 넣었다가 연결이 돌아오면 다시 재생합니다. Supabase에도 Postgres의 변경 피드 위에 구축된 Realtime이 있고 실시간 대시보드나 접속 상태 표시에는 충분히 좋지만, Firebase 모바일 앱이 기대는 오프라인 우선 경험은 아닙니다. 제품이 협업형이거나 오프라인 비중이 큰 모바일 앱이라면, 이 항목에 크게 가중치를 두어 Firebase 쪽으로 기울이십시오.

당신이 누구냐에 따른 선택 규칙

Supabase와 Firebase 중 무엇이 더 낫습니까?

어느 쪽도 무조건 낫지는 않습니다. Supabase는 SQL, AI 기능, 그리고 나중에 옮겨 갈 자유를 원하는 데이터 중심 앱에 더 낫습니다. Firebase는 실시간·오프라인 우선 모바일 앱과, 신용카드가 필요 없는 부담 없는 프로토타입에 더 낫습니다. 핵심 기능이 구조화된 데이터인지 실시간 동기화인지에 맞춰 도구를 고르십시오.

구글이 Firebase를 종료한다는 말은 사실입니까?

구글은 Firebase를 종료하지 않습니다. 혼란은 일부 레거시 제품이 지원 종료된 데서(예를 들어 Firebase Dynamic Links는 2025년 8월에 종료되었습니다), 그리고 구글이 일부 기능을 Google Cloud로 편입시킨 데서 비롯됩니다. 핵심 플랫폼은 활발히 개발되고 있으며, Firebase Studio, AI Logic, SQL Connect를 통한 관리형 PostgreSQL 같은 최신 기능이 추가되었습니다.

Supabase는 Firebase의 일부입니까?

아닙니다. Supabase는 별개의 독립 회사이며, 흔히 오픈소스 Firebase 대안으로 소개됩니다. 같은 종류의 올인원 백엔드(데이터베이스, 인증, 스토리지, API)를 제공하지만, 구글의 독점 Firestore가 아니라 PostgreSQL 위에 구축되어 있습니다.

Supabase의 단점은 무엇입니까?

크게 두 가지입니다. 무료 프로젝트가 1주일간 활동이 없으면 일시 중지되어 데모가 끊깁니다. 그리고 실시간·오프라인 동기화 경험이 탄탄하기는 해도 Firebase보다 덜 성숙해서, 오프라인 비중이 큰 모바일 앱에서는 여전히 Firebase가 앞섭니다. 또한 다중 사용자 앱을 안전하게 유지하려면 RLS를 익혀야 합니다.

Supabase와 Firebase 중 어느 쪽이 더 저렴합니까?

트래픽이 정말 없는 프로토타입이라면 Firebase Spark가 더 저렴합니다. 카드 없이 무료이기 때문입니다. 실제 사용량이 생기면 대개 Supabase가 더 저렴하고 훨씬 예측 가능합니다. 월 $25 고정의 Pro 플랜과, 트래픽에 따라 올라가는 Firebase의 작업당 종량 과금을 비교하면 그렇습니다. 앱이 많이 읽고 많이 쓸수록 Supabase의 고정 모델이 유리해집니다.

백엔드를 고르고, 나머지 스택을 거기에 맞추십시오. 저는 매주 이런 빌더 해부를 하나씩 보냅니다. 실제 비용과 벽까지 포함해서 말입니다. 메일로 받아 보기.