수파베이스 vs 파이어베이스: 데이터 모델·가격·보안 비교
수파베이스 vs 파이어베이스는 데이터 모델에서 갈립니다. 수파베이스는 Postgres 관계형, 파이어베이스는 Firestore 문서형입니다.

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.
오늘의 인사이트 요약
수파베이스 vs 파이어베이스는 데이터 모델에서 갈립니다. 수파베이스는 Postgres 관계형, 파이어베이스는 Firestore 문서형입니다.
2026년 10월 기준 수파베이스 무료는 DB 500MB, Pro는 월 $25부터이고 파이어베이스는 무료 Spark와 종량제 Blaze로 나뉩니다.
클라이언트의 데이터 접근에는 RLS·Firestore 보안 규칙을, 서버 접근에는 별도의 권한 설정을 적용합니다.
BaaS는 인증·데이터베이스·파일 저장 같은 백엔드 기능을 관리형 서비스로 제공하는 방식입니다. 수파베이스와 파이어베이스가 대표적인 비교 대상입니다. 이 글은 Supabase의 PostgreSQL과 Firebase의 Cloud Firestore를 중심으로 살펴봅니다. Firebase에는 PostgreSQL 기반 SQL Connect 등 다른 데이터 제품도 있습니다.
수파베이스 vs 파이어베이스, 데이터를 저장하고 조회하는 방식이 다릅니다

수파베이스는 Postgres 위에 인증과 스토리지를 얹었습니다.
인증 정보도 프로젝트 Postgres 안의 별도 스키마에 저장됩니다. 주문과 상품처럼 표로 정리되는 데이터를 SQL로 묶어 조회하는 서비스에 맞고, 셀프 호스팅 때는 백업과 보안을 직접 맡습니다.
파이어베이스는 Firestore를 중심으로 앱 도구를 묶었습니다.
컬렉션과 문서로 저장하는 NoSQL이라 화면 구조대로 쌓는 앱에 빠르게 붙습니다. PostgreSQL 기반 SQL Connect도 제공하므로, Firebase를 고른다고 반드시 문서형 데이터베이스만 써야 하는 것은 아닙니다.
수파베이스 가격과 파이어베이스 가격, 무료는 어디까지일까요
수파베이스 무료는 프로젝트 2개이고 일주일 안 쓰면 멈춥니다.
수파베이스 공식 요금 페이지(2026년 10월 확인)상 Free 한도는 프로젝트당 DB 500MB, 파일 1GB, 데이터 전송 5GB, 월간 활성 사용자 5만 명, Edge Function 호출 50만 회입니다. 활성 프로젝트는 2개까지이고 일주일간 활동이 없으면 중지됩니다.
수파베이스 Pro는 월 $25부터 시작합니다.
디스크 8GB, 파일 100GB, 데이터 전송 250GB, 월간 활성 사용자 10만 명에 월 $10 컴퓨트 크레딧이 붙습니다. 지출 상한(spend cap)은 기본으로 켜져 있지만 모든 비용의 총액을 고정하는 기능은 아닙니다. 컴퓨트 크기·추가 프로젝트·애드온 등은 별도 과금 조건을 확인합니다. Supabase 요금표

파이어베이스는 무료 Spark와 종량제 Blaze로 나뉩니다.
파이어베이스 공식 요금 페이지(2026년 10월 확인)상 Spark의 Firestore 무료분은 저장 1GiB, 하루 읽기 5만 건, 쓰기 2만 건, 삭제 2만 건입니다. 읽기 횟수로 세니 목록 화면 하나가 사용자 수만큼 곱해집니다. Cloud Functions는 Spark 표에 해당 없음이고 Blaze에서 월 200만 회까지 무료라서, 해당 서버 함수를 사용하려면 결제 계정을 연결한 Blaze 플랜이 필요합니다. 무료 호출분이 있어도 컴퓨트·네트워크 등 다른 비용은 발생할 수 있습니다. Firebase 요금표
항목 | 수파베이스 Free | 파이어베이스 Spark |
|---|---|---|
데이터베이스 | 프로젝트당 500MB | Firestore 총 1GiB |
사용량 기준 | 데이터 전송 5GB | 하루 읽기 5만·쓰기 2만 |
인증 | 월간 활성 사용자 5만 명 | 인증 방식·Identity Platform 적용에 따라 무료 범위 확인 |
서버 함수 | Edge Function 월 50만 회 | Blaze 전환 후 월 200만 회 |
수파베이스 사용법은 프로젝트 생성부터 첫 쿼리까지 네 단계입니다

대시보드에서 프로젝트와 테이블을 만듭니다.
SQL Editor에서 instruments 테이블을 만들고 RLS를 켠 다음 읽기 정책을 추가하는 순서가 공식 빠른 시작 가이드에 나옵니다.
Next.js 템플릿으로 앱을 만들고 환경 변수를 채웁니다.
npx create-next-app@latest my-app -e with-supabase
그다음 .env.local에 NEXT_PUBLIC_SUPABASE_URL과 NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY를 넣습니다.
쿼리 한 줄로 데이터를 읽습니다.
템플릿의 서버용 클라이언트를 만든 뒤 await supabase.from("instruments").select()로 조회합니다. RLS 읽기 정책이 해당 사용자에게 허용되어 있어야 결과를 받을 수 있습니다.
RLS와 Firestore 보안 규칙은 접근 권한을 정하는 설정입니다

수파베이스는 RLS를 켜고 정책을 써야 합니다.
공식 문서는 노출된 스키마의 모든 테이블에 RLS를 요구합니다. RLS가 없으면 권한이 있는 역할은 읽고 쓸 수 있고, 켜면 정책을 만들 때까지 publishable key로는 데이터가 나오지 않습니다. RLS를 우회하는 secret key는 브라우저에 넣으면 안 됩니다.
파이어베이스는 Firestore 보안 규칙을 직접 관리합니다.
모바일·웹 클라이언트의 접근은 Firestore 보안 규칙으로 제어합니다. 서버 클라이언트 라이브러리는 이 규칙을 거치지 않고 IAM 권한을 사용합니다. 위 도식은 두 정책의 차이를 요약한 것으로, 규칙을 작성하지 않았다고 모든 프로젝트가 자동으로 공개된다는 뜻은 아닙니다. 실제 기본 설정과 배포된 정책을 확인합니다.
수파베이스 vs 파이어베이스, 우리 서비스에는 어느 쪽일까요
주문·상품·예약의 관계를 SQL로 조회한다면 Supabase가 익숙할 수 있습니다. Firestore의 문서 모델과 Firebase의 모바일 도구를 활용한다면 Firebase가 편할 수 있습니다. 가격은 두 서비스 모두 저장 공간, 네트워크, 인증·함수 사용량 등 여러 항목에 영향을 받으므로 예상 트래픽을 넣어 비교합니다. 한쪽이 항상 더 저렴하거나 빠른 것은 아닙니다.

데이터 구조부터 우리 서비스에 맞춰봅니다
어떤 백엔드를 고를지는 만들고 싶은 서비스와 운영 방식에 따라 달라집니다. 똑똑한개발자는 웹·앱의 데이터와 화면 흐름을 함께 설계하는 팀입니다.

주문이나 예약처럼 관리하려는 데이터, 필요한 기능을 편하게 들려주세요. 기술 이름부터 결정하기보다 서비스에 어울리는 구성을 함께 살펴보겠습니다.
감사합니다. :)
프로젝트에 필요한 내용을 함께 살펴봅니다.
https://www.toktokhan.dev/contact?utm_source=landing&utm_campaign=supabase-firebase&utm_medium=supabase-firebase&utm_term=%EC%88%98%ED%8C%8C%EB%B2%A0%EC%9D%B4%EC%8A%A4-%ED%8C%8C%EC%9D%B4%EC%96%B4%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EB%B9%84%EA%B5%90