이 글은 2026년 6월 기준 최신 정보로 다듬었다. 핵심 변경점만 먼저 짚자면, 무료 플랜은 데이터베이스 500MB와 월 활성 사용자(MAU) 50,000명, Edge Function 호출 50만 회를 제공하지만 7일간 활동이 없으면 프로젝트가 자동 일시중지되어 상시 운영 서비스에는 부적합하다. Pro 플랜은 월 25달러부터 시작하며 데이터베이스 8GB, MAU 10만 명, 스토리지 100GB가 포함되고 초과분은 사용량 과금이다. 셀프호스팅 Docker 기본 이미지는 PostgreSQL 15에서 17로 올라갔고, OAuth 토큰 엔드포인트 성공 응답은 2026년 5월 22일부로 201 Created에서 200 OK로 변경되어 OAuth 2.1 호환성이 강화됐다.
Supabase란 무엇인가?
Firebase의 오픈소스 대안
Supabase는 한마디로 "오픈소스 Firebase 대안"이다. 하지만 단순한 클론이 아니다. Firebase가 NoSQL 기반의 Firestore를 중심으로 돌아간다면, Supabase는 세계에서 가장 검증된 관계형 데이터베이스인 PostgreSQL을 기반으로 작동한다. 이게 정말 큰 차이다. 관계형 데이터가 필요한 프로젝트에서 Firebase의 문서형 구조에 억지로 데이터를 끼워 맞추던 경험이 있다면, Supabase가 얼마나 반가운 존재인지 바로 체감할 것이다. 데이터는 표준 SQL로 질의할 수 있고, 언제든 덤프로 내보낼 수 있으며, Docker로 로컬에서 동일하게 돌려볼 수 있다. 특정 벤더에 종속되는 락인(lock-in) 부담이 그만큼 덜하다는 의미다.
BaaS가 개발자에게 주는 가치
BaaS(Backend as a Service)의 본질은 "백엔드를 직접 구축하지 않아도 된다"는 것이다. 인증, 데이터베이스, 스토리지, 실시간 구독까지 백엔드에서 반복적으로 만들어야 하는 기능들을 Supabase가 이미 제공한다. 솔직히 사이드 프로젝트나 MVP를 만들 때 백엔드 서버 세팅부터 시작하면 며칠이 훌쩍 지나간다. PostgreSQL BaaS인 Supabase를 쓰면 그 시간을 프론트엔드 개발과 비즈니스 로직에 집중할 수 있다. 2026년 현재 Supabase는 단순한 백엔드 대체재를 넘어, pgvector 기반의 벡터 검색과 Edge Functions 내장 추론까지 갖춘 AI 친화 플랫폼으로 자리를 넓혔다.
Supabase 핵심 기능 파헤치기
데이터베이스와 자동 생성 REST API
Supabase에서 테이블을 하나 만들면, 그 즉시 PostgREST 기반의 REST API가 자동으로 생성된다. 별도의 API 서버를 작성할 필요가 없다는 뜻이다. 테이블 스키마를 변경하면 API도 자동으로 반영된다. 여기에 Row Level Security(RLS) 정책을 설정하면, API 수준에서 권한 제어까지 한 번에 해결된다. PostgreSQL의 강력한 기능을 그대로 활용할 수 있다는 점이 다른 BaaS와 확실히 차별화되는 부분이다. 조인, 뷰, 트리거, 함수 등 RDBMS의 모든 무기를 쓸 수 있다.
인증(Auth) 시스템
Supabase Auth는 이메일/비밀번호, 매직 링크, OAuth(Google, GitHub, Kakao 등)를 기본 지원한다. 특히 한국 개발자에게 반가운 건 Kakao OAuth가 공식 지원된다는 점이다. JWT 기반 인증이라 토큰 관리도 표준적이고, auth.users 테이블과 커스텀 테이블을 외래키로 연결해서 사용자별 데이터 관리를 깔끔하게 할 수 있다. 2026년 5월 22일부로 OAuth 토큰 엔드포인트의 성공 응답이 201 Created에서 200 OK로 바뀌어 OAuth 2.1 표준을 더 엄격하게 따르게 됐으니, 토큰 응답 코드를 직접 검사하던 코드가 있다면 한 번 점검해 두는 편이 좋다.
실시간 구독과 스토리지
Supabase Realtime은 PostgreSQL의 변경 사항을 WebSocket으로 실시간 전달한다. 채팅 앱, 실시간 대시보드, 협업 툴 같은 기능을 별도 인프라 없이 구현할 수 있다. 유료 플랜은 월 500만 건의 메시지를 포함하며, 초과분은 100만 건당 2.50달러로 과금된다. 동시 접속(peak connection)은 500개까지 무료이고 그 이상은 1,000개당 10달러다. 또한 Supabase Storage는 S3 호환 오브젝트 스토리지를 제공하며, 이미지 리사이징과 변환 기능까지 내장하고 있어 파일 업로드 관련 백엔드 코드를 거의 작성할 필요가 없다.
Edge Functions와 Vector/AI
Edge Functions는 Deno 런타임 위에서 도는 서버리스 TypeScript 함수로, 모든 플랜에 기본 포함된다. 무료 플랜도 월 50만 회 호출을 제공하며, 초과분은 컴퓨트 사용량 기준으로 과금된다. 결제 웹훅 처리, 외부 API 연동, 임베딩 생성처럼 클라이언트에 두기 곤란한 로직을 여기에 올리면 된다. AI 쪽도 탄탄해졌는데, pgvector 확장으로 벡터 임베딩을 저장하고 유사도 검색을 돌릴 수 있다. pgvector 0.7 이상은 최대 16,000차원 벡터 컬럼을 지원하고, 2026년 기준 권장 인덱스는 HNSW다. Edge Runtime v1.36.0부터는 gte-small(384차원) 모델이 함수 내부에서 네이티브로 돌아가 외부 API 호출 없이 임베딩을 생성할 수 있어, RAG나 시맨틱 검색을 한 플랫폼 안에서 끝낼 수 있다.
실전 활용 팁
RLS는 처음부터 켜고 시작하라
Supabase에서 가장 흔한 실수는 RLS(Row Level Security)를 끈 채로 개발하다가 그대로 배포하는 것이다. anon 키는 클라이언트에 노출되는 공개 키이므로, RLS가 없으면 테이블 전체가 사실상 외부에 열린 상태가 된다. 새 테이블을 만들면 곧바로 RLS를 켜고, "본인 행만 읽고 쓸 수 있다" 같은 최소 정책부터 정의하는 습관을 들이는 게 안전하다.
무료 플랜 자동 일시중지를 염두에 둘 것
무료 플랜 프로젝트는 7일간 활동이 없으면 자동으로 일시중지된다. 사이드 프로젝트나 데모는 괜찮지만, 24시간 떠 있어야 하는 실서비스라면 Pro 플랜(월 25달러)으로 올려 가동을 보장받아야 한다. 대략 MAU 4만 명을 넘기거나, 데이터베이스가 무료 한도에 가까워지거나, 이메일 지원이 필요해지는 시점이 업그레이드를 고민할 신호다.
Supabase vs Firebase 장단점 비교
2026년 기준으로 두 플랫폼의 가장 큰 차이는 과금 모델에 있다. Supabase는 데이터베이스 용량, 스토리지, MAU 같은 자원 기준으로 과금하는 반면, Firebase는 읽기/쓰기/삭제 같은 작업(operation) 단위로 과금한다. 그래서 Supabase 쪽이 비용 예측이 훨씬 쉽고, 규모가 커질수록 대체로 30~50% 저렴한 편이다. 예를 들어 MAU 5만, DB 20GB, 스토리지 80GB 조건에서 Supabase Pro는 월 약 104달러인데, 비슷한 Firebase 사용량은 월 150~250달러로 추정된다.
| 항목 | Supabase | Firebase |
|---|---|---|
| 데이터 모델 | PostgreSQL (관계형) | Firestore (문서형 NoSQL) |
| 과금 방식 | 자원 기준 (예측 용이) | 작업 기준 (스파이크 주의) |
| 쿼리 | 표준 SQL, 조인/뷰/함수 | 제한적 쿼리, 조인 약함 |
| 벤더 락인 | 낮음 (오픈소스, 셀프호스팅 가능) | 높음 (구글 종속) |
| 벡터/AI | pgvector 내장 | 별도 연동 필요 |
관계형 데이터 모델, SQL 활용, 비용 예측 가능성, 락인 회피가 중요하다면 Supabase가 유리하다. 반대로 구글 생태계(분석, 클라우드 메시징, ML Kit 등)와의 긴밀한 통합이 핵심이라면 Firebase도 여전히 합리적인 선택이다.
마무리
Supabase는 "PostgreSQL을 그대로 쓰면서 백엔드의 반복 작업을 덜어주는 플랫폼"이라는 정체성을 2026년에도 일관되게 지키고 있다. 자동 REST API, 표준적인 JWT 인증, WebSocket 실시간 구독, S3 호환 스토리지라는 기본기에 더해, pgvector 벡터 검색과 Edge Functions 내장 추론까지 갖추면서 AI 애플리케이션 백엔드로서의 무게감도 커졌다. 비용 구조가 투명해 배포 전에 미리 가늠할 수 있다는 점, 오픈소스라 언제든 셀프호스팅으로 빠져나올 수 있다는 점은 장기 운영 관점에서 분명한 강점이다. 사이드 프로젝트의 MVP부터 본격적인 프로덕션 서비스까지, 관계형 데이터가 필요한 프로젝트라면 한 번쯤 진지하게 검토할 가치가 충분하다.
