필사 모드: Backend-as-a-Service 2026 — Supabase·Firebase·Pocketbase·Appwrite·Convex·InstantDB 심층 비교 (1인 SaaS의 등뼈)
한국어프롤로그 — "1인 SaaS"의 등뼈를 무엇으로 짤 것인가
2026년 5월. 새 프로젝트를 시작하는 첫 회의 풍경은 2020년과 묘하게 비슷하면서도 다르다.
> "백엔드, 직접 짤 거예요? 아니면 BaaS 쓸 거예요?"
차이는 이제 **"BaaS를 안 쓰는 팀이 거의 없다"**는 점이다. 1인 SaaS, 인디 게임, 사이드 프로젝트, 심지어 시드 단계 스타트업까지. 풀스택 백엔드를 처음부터 짜는 일은 비용이 너무 크다. 인증·스토리지·실시간·벡터·DB·엣지 함수까지 모두 직접 짜는 건, "AI로 한 명이 SaaS를 만든다"는 2026년의 흐름과 정면으로 어긋난다.
BaaS의 풍경도 5년 전과 다르다.
- **Firebase 일변도가 끝났다.** Google이 만든 거대한 도구는 여전히 큰 시장 점유율을 가지지만, **Postgres 기반 오픈소스 대안 — Supabase**가 진짜 2군이 됐다.
- **셀프호스트 BaaS가 한 카테고리로 굳었다.** Appwrite와 Pocketbase가 각자의 자리에서 살아남았고, 둘 다 v1.x 시리즈로 안정기에 진입했다.
- **'Reactive 백엔드' 같은 새 모델이 등장했다.** Convex는 함수 결과를 클라이언트가 구독하는 식의 React-native 서버 모델로 한 자리를 차지했다.
- **InstantDB는 'Firebase + Linear'의 길을 택했다.** Tagged template + 실시간 그래프 쿼리로, "Firebase가 Vercel 시대에 다시 태어나면 이렇게 생겼을 것"이라는 평가를 받는다.
이 글은 2026년 5월 기준 BaaS 시장을 7개 도구로 직접 비교한다.
- **Supabase** — Postgres 기반 오픈소스 BaaS의 사실상 표준
- **Firebase** — 여전히 가장 큰 BaaS, Google Cloud 통합과 Genkit으로 AI 시대 진입
- **Pocketbase** — SQLite 단일 바이너리, 인디 프로젝트의 첫 선택지
- **Appwrite** — 멀티 기능 풀스택 BaaS, 셀프호스트 친화
- **Convex** — Reactive 백엔드, TypeScript-native 함수
- **InstantDB** — 실시간 TS-first 쿼리, "Vercel 시대의 Firebase"
- **PlanetScale + Clerk + 커스텀** — BaaS를 거부하고 직접 조립하는 길
비교 축은 7개. 데이터 모델·실시간·인증·벡터/AI·셀프호스트·벤더 락인·스케일 시 가격. 그리고 마지막에는 시나리오별 추천을 정직하게 정리한다.
1장 · 풍경 — 무엇이 BaaS인가, 누가 누구의 친구인가
먼저 분류부터. 모두 "BaaS"라고 부르지만, 실은 결이 다르다.
| 분류 | 도구 | 한 줄 요약 |
| --- | --- | --- |
| 풀 BaaS (호스티드) | Firebase·Supabase·Appwrite Cloud | 인증·DB·스토리지·함수·실시간을 한 자리에서 |
| 셀프호스트 풀 BaaS | Appwrite·Supabase(self-host) | Docker·Kubernetes 위에 직접 운영 |
| 단일 바이너리 BaaS | Pocketbase | SQLite + Go 바이너리 하나, 1인 SaaS 친화 |
| Reactive 백엔드 | Convex | 함수 + 구독 + 자동 캐시, React/TS-first |
| 실시간 DB | InstantDB·Firestore | 클라이언트가 데이터를 그래프로 구독 |
| 빌드-유어-온 | PlanetScale + Clerk + Inngest + Resend 등 | BaaS 거부, 각 책임을 별도 서비스로 |
이 글의 핵심 비교는 위 표의 굵게 표시된 도구들 — Supabase·Firebase·Pocketbase·Appwrite·Convex·InstantDB. 마지막의 "빌드-유어-온"은 비교 끝에 짧게 다룬다.
**왜 이 6개인가**
- **Supabase** — 2026년 BaaS 시장의 2위. GitHub 스타 **78k+**, 오픈소스 풀 BaaS의 사실상 표준. DataLab·SQL Editor v2·Branching이 최근 1년의 큰 변화.
- **Firebase** — Google의 거대한 BaaS, 모바일 친화. App Hosting과 Genkit으로 AI 시대로 들어왔다. Firestore는 여전히 압도적인 도큐먼트 DB 점유율.
- **Pocketbase** — Go 단일 바이너리, SQLite 기반. v0.22 시리즈에서 안정기에 들어왔고 1인 인디 프로젝트 사실상 1순위. GitHub 스타 **42k+**.
- **Appwrite** — 셀프호스트 친화의 풀 BaaS. v1.6 ~ v1.7에서 Functions·Realtime·Storage가 모두 안정화. Appwrite Cloud는 호스티드 옵션으로 GA 진입.
- **Convex** — TypeScript-native reactive 백엔드. 함수 + 자동 캐시 + WebSocket 구독을 묶어, "Next.js 같은 서버 컴포넌트와 동거하는 백엔드"를 표방.
- **InstantDB** — 2024년 베타 이후 2025~2026년 빠르게 성장한 실시간 그래프 DB. TS-first 쿼리(`useQuery({ todos: {} })`)와 강한 권한 모델이 핵심.
2장 · 데이터 모델 — SQL인가 도큐먼트인가 그래프인가
BaaS 선택의 첫 갈래는 **데이터 모델**이다. 잘못 고르면 6개월 뒤에 후회한다.
관계형 (SQL) 도큐먼트 그래프/리액티브
| | |
Supabase Appwrite(SQL) Firebase(Firestore) InstantDB Convex
Pocketbase(SQLite) Appwrite(Docs) Firestore Datastore
2.1 Supabase — Postgres 그 자체
Supabase의 본질은 **"Postgres에 BaaS 옷을 입혔다"**이다. 모든 데이터는 진짜 Postgres 테이블에 들어가고, JOIN·트리거·MV·CTE 같은 Postgres 기능을 다 쓸 수 있다.
-- Supabase는 진짜 Postgres이므로 그대로 동작한다
CREATE TABLE posts (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
author_id uuid REFERENCES auth.users (id),
title text NOT NULL,
body text,
created_at timestamptz DEFAULT now()
);
-- Row Level Security가 권한 모델의 핵심
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;
CREATE POLICY "own_posts" ON posts
USING (author_id = auth.uid());
**강점**
- 관계가 분명한 SaaS·B2B·CRUD-heavy 앱에 자연스럽다.
- 운영 노하우가 곧 일반 Postgres 지식이다 (export·튜닝·인덱스).
- pgvector 확장으로 벡터 검색이 빌트인. AI 앱 친화.
**약점**
- 도큐먼트/임베디드 그래프 데이터 모델이 자연스럽지 않다.
- 트랜잭션 + 실시간 + RLS의 상호작용이 처음엔 헷갈린다.
2.2 Firebase Firestore — 도큐먼트의 황제
Firestore는 **컬렉션 + 도큐먼트 + 서브컬렉션**의 NoSQL 도큐먼트 DB다. 스키마가 없고, 클라이언트에서 직접 읽고 쓰는 모델이 표준이다.
const db = getFirestore()
await addDoc(collection(db, 'posts'), {
authorId: 'user_123',
title: 'Hello',
createdAt: serverTimestamp(),
})
**강점**
- 모바일·오프라인 동기화의 사실상 표준.
- 권한은 Security Rules로 선언적으로.
- 자동 스케일링, 트래픽 급증에도 거의 안 죽는다.
**약점**
- JOIN이 없다. 관계 데이터는 비정규화·복제로 풀어야 한다.
- 쿼리 표현력이 제한적 (인덱스 사전 정의, OR 제약 등).
- 비용이 "도큐먼트 읽기 회수"에 비례 — 스케일 시 비용 모델링이 어렵다.
2.3 Pocketbase — SQLite 기반의 깔끔한 관계형
Pocketbase는 SQLite 위에 컬렉션 모델을 얹은 형태다. "도큐먼트 같지만 실은 관계형"인 하이브리드.
- 컬렉션 = SQLite 테이블 (스키마 있음).
- 레코드 간 관계는 `relation` 필드 타입으로 표현.
- 어드민 UI에서 스키마·레코드를 시각적으로 관리.
**강점**
- 단일 바이너리. `./pocketbase serve` 한 줄로 시작.
- SQLite의 단순함 — 백업은 파일 복사, 운영 비용 0에 가까움.
**약점**
- 단일 노드. 수평 확장은 본질적으로 어렵다 (LiteFS 같은 우회는 있음).
- SQLite 한계 — 동시 쓰기·복잡 쿼리·확장 모듈에서는 Postgres에 못 미친다.
2.4 Appwrite — 도큐먼트형, 다중 DB
Appwrite는 도큐먼트 컬렉션 모델이지만 내부적으로 MariaDB·MySQL·MongoDB 백엔드를 고를 수 있다. 운영자가 자기 인프라에 맞춰 고를 수 있는 게 강점이자 복잡함이다.
2.5 Convex — 도큐먼트 + reactive view
Convex의 데이터 모델은 **도큐먼트 + 인덱스 + 함수**다. 데이터를 직접 노출하지 않고, 항상 **TypeScript 함수**를 통해서 본다.
// convex/posts.ts
export const list = query(async (ctx) => {
return await ctx.db.query('posts').order('desc').take(20)
})
// 클라이언트는 함수 결과를 구독한다 — 자동 실시간
const posts = useQuery(api.posts.list)
2.6 InstantDB — 트리플 스토어 + 그래프 쿼리
InstantDB는 **entity-attribute-value(트리플 스토어)** 모델 위에 그래프 쿼리를 얹은 구조다.
// 'todos를 가져오는데, 그 안의 owner도 함께'
const { data } = useQuery({ todos: { owner: {} } })
스키마는 선택적 — 처음에는 스키마 없이 시작하고, 점진적으로 강화할 수 있다.
3장 · 실시간 — "푸시"가 기본인가 옵션인가
2026년의 BaaS에서 실시간은 **선택이 아니라 기본**이다. 다만 구현 모델이 다르다.
| 도구 | 실시간 모델 | 비고 |
| --- | --- | --- |
| Supabase Realtime | Postgres logical replication → WebSocket | RLS 적용 |
| Firebase Firestore | snapshot listener | 자동, 오프라인 친화 |
| Firebase RTDB | WebSocket 기반 트리/노드 구독 | 가장 오래된 실시간 NoSQL |
| Pocketbase Realtime | SSE 기반 컬렉션 구독 | 단순, 단일 노드 |
| Appwrite Realtime | WebSocket 채널 구독 | 컬렉션/도큐먼트별 채널 |
| Convex | WebSocket — 함수 결과 자동 무효화 | 가장 매끄러운 reactive |
| InstantDB | WebSocket — 쿼리 그래프 구독 | 변경 분 전체 푸시 |
3.1 Supabase — RLS와 실시간의 만남
Supabase Realtime은 Postgres의 logical replication을 듣고 있다가, RLS 정책을 만족하는 변경만 클라이언트로 푸시한다.
const channel = supabase
.channel('posts')
.on('postgres_changes',
{ event: '*', schema: 'public', table: 'posts' },
(payload) => { /* ... */ })
.subscribe()
RLS가 실시간에도 적용된다는 게 핵심이다 — 한 곳에서 정책을 짜면 read·write·realtime 셋 다 같은 정책으로 보호된다.
3.2 Firestore — 가장 매끄러운 모바일 실시간
`onSnapshot`은 모바일 친화 실시간의 사실상 표준이다. 오프라인 큐, 자동 재연결, 컬렉션 인덱스까지 묶여 있다.
3.3 Convex — 함수 결과가 곧 구독 대상
Convex의 차별점은 **"쿼리 함수의 결과 그 자체가 구독 단위"**라는 점이다. 함수가 읽은 데이터를 자동으로 추적해서, 그 데이터가 바뀌면 함수를 다시 실행하고 클라이언트에 새 결과를 푸시한다.
이 모델은 "어떤 채널을 구독해야 하나?" 같은 고민을 없앤다. 그러나 비용 모델·함수 작성 방식이 일반 BaaS와 다르므로 학습 곡선이 있다.
3.4 InstantDB — 그래프 변경 그대로 푸시
InstantDB는 클라이언트가 짠 그래프 쿼리(`{ todos: { owner: {} } }`)를 그대로 구독한다. 어떤 attribute가 바뀌었는지 서버가 안다.
4장 · 인증·권한 — 진짜 운영 가능한가
BaaS의 진짜 가치는 인증·권한 시스템에 있다. 직접 짜본 사람은 안다 — 토큰 회전·OAuth 콜백·이메일 인증·MFA·RLS가 얼마나 귀찮은지.
| 도구 | 인증 방식 | 권한 모델 |
| --- | --- | --- |
| Supabase Auth | 이메일·OAuth·매직링크·SAML·MFA | Postgres RLS |
| Firebase Auth | 이메일·OAuth·매직링크·SAML·MFA | Security Rules |
| Pocketbase Auth | 이메일·OAuth | 컬렉션 API 규칙 |
| Appwrite Auth | 이메일·OAuth·매직링크·SMS·MFA | Teams + Permissions |
| Convex Auth | Clerk·Auth0·NextAuth 어댑터 | 함수 내 검사 |
| InstantDB Auth | 매직링크 + Clerk | Rules (Datalog 비슷) |
4.1 Supabase Auth + RLS
Supabase의 핵심은 **JWT + Postgres RLS**다. JWT의 `sub`가 `auth.uid()` 함수로 모든 쿼리에서 사용 가능하다.
CREATE POLICY "select_own" ON posts FOR SELECT
USING (author_id = auth.uid());
CREATE POLICY "insert_own" ON posts FOR INSERT
WITH CHECK (author_id = auth.uid());
RLS는 **데이터 자체에 권한이 박힌다**는 점에서 강력하지만, 디버그 난이도가 있다 — 정책이 잘못 짜이면 "원인 없이 빈 결과"가 난다.
4.2 Firebase Security Rules
선언적 DSL로 권한을 짠다.
match /posts/{postId} {
allow read: if true;
allow write: if request.auth.uid == resource.data.authorId;
}
학습 곡선은 있지만, 한 번 익히면 매우 강력하다.
4.3 Convex — 함수 내 검사
Convex는 RLS 같은 DB 레벨 권한이 없다. 모든 권한 검사는 함수 안에서 이뤄진다.
export const updatePost = mutation(async (ctx, { id, body }) => {
const identity = await ctx.auth.getUserIdentity()
if (!identity) throw new Error('unauthorized')
const post = await ctx.db.get(id)
if (post.authorId !== identity.subject) throw new Error('forbidden')
await ctx.db.patch(id, { body })
})
장점은 명시성 — 권한이 코드에 분명히 보인다. 단점은 일관성 — 모든 함수에 직접 짜야 한다.
4.4 InstantDB Rules
InstantDB는 Datalog과 비슷한 룰 DSL을 쓴다. 데이터 모델이 트리플 스토어이므로 룰도 그쪽 표현에 맞다.
5장 · AI·벡터 — 2026년의 BaaS 차별점
2026년 BaaS에서 가장 빠르게 진화한 영역이 **벡터·임베딩·AI 기능**이다.
| 도구 | 벡터 검색 | AI 통합 |
| --- | --- | --- |
| Supabase | pgvector + HNSW | Edge Functions + AI SDK 통합 |
| Firebase | Vertex AI Vector Search 통합 | Genkit (정식 GA) |
| Pocketbase | 빌트인 X (외부 통합) | 별도 |
| Appwrite | v1.7~ 벡터 컬렉션 베타 | Functions에서 직접 |
| Convex | 벡터 인덱스 빌트인 | 함수 내 OpenAI 호출 표준 |
| InstantDB | 벡터 검색 베타 | 트리거 + 외부 |
5.1 Supabase — pgvector의 본진
Supabase의 AI 친화도가 가장 높다고 평가받는 이유는 **pgvector를 1급으로 다룬다**는 점이다.
CREATE EXTENSION vector;
CREATE TABLE documents (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536)
);
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);
RAG·임베딩 검색·시맨틱 검색이 일반 Postgres 쿼리로 표현된다. AI 앱을 짤 때 BaaS와 벡터 DB를 분리할 필요가 없다.
5.2 Firebase Genkit — Google의 응답
Genkit은 Firebase 진영의 AI 프레임워크로 정식 GA 됐다. Vertex AI 통합, Gemini 모델, retrieval, flow definition, 평가까지 묶인다. Firebase 백엔드 + Genkit AI 흐름을 같이 짜고 싶은 팀에 자연스럽다.
5.3 Convex — 함수 안에서 LLM 호출이 기본 스타일
Convex 함수 안에서 OpenAI·Anthropic API를 직접 호출하는 패턴이 표준화돼 있다. 벡터 인덱스가 빌트인이라 RAG 파이프라인이 짧다.
// convex/rag.ts
export const search = query(async (ctx, { q }) => {
const embedding = await embed(q)
const docs = await ctx.db
.query('docs')
.withIndex('by_embedding', q => q.vectorSearch('embedding', embedding))
.take(5)
return docs
})
6장 · 셀프호스트 스토리 — "1인 SaaS"라면 핵심
셀프호스트는 단순한 비용 절감이 아니라, **벤더 락인을 끊는 보험**이다.
| 도구 | 셀프호스트 | 난이도 |
| --- | --- | --- |
| Supabase | 공식 Docker compose / Kubernetes Helm | 중 (Postgres + 마이크로서비스 다수) |
| Firebase | 불가 (에뮬레이터만) | 해당 없음 |
| Pocketbase | 단일 바이너리 | 매우 낮음 (1분) |
| Appwrite | 공식 Docker compose | 낮음~중 (모놀리식, Docker 한 줄) |
| Convex | OSS 셀프호스트 출시(2025) | 중 |
| InstantDB | 베타 단계 셀프호스트 옵션 | 중~높음 |
6.1 Pocketbase — 가장 단순한 셀프호스트
Pocketbase의 셀프호스트는 1분이다.
다운로드 후
./pocketbase serve --http=0.0.0.0:8090
Fly.io·Railway·VPS 어디든 단일 바이너리 + SQLite 파일이면 끝. 백업은 그 파일을 복사.
6.2 Supabase — 강력하지만 운영비
Supabase의 자체 호스팅은 가능하지만, **여러 서비스(Postgres + GoTrue + Realtime + Storage + Studio + ...)를 한꺼번에 운영**해야 한다. Docker compose 한 줄로 시작은 가능하지만, 프로덕션은 진지한 운영 노력이 든다.
6.3 Appwrite — Docker 친화
Appwrite는 셀프호스트가 1급 시민이다. `docker-compose up -d` 한 줄로 풀스택이 뜬다. 인디 + 작은 팀에 자연스럽다.
6.4 Convex — OSS 등장
2025년 후반 Convex가 OSS 셀프호스트 버전을 공개했다. 호스티드와 100% 동등하진 않지만, 락인을 진지하게 줄였다.
6.5 Firebase — 불가능
Firebase는 셀프호스트 옵션이 없다. 로컬 에뮬레이터는 개발용. **이게 Firebase의 가장 큰 약점**이다.
7장 · 벤더 락인 — 빠져나갈 수 있는가
셀프호스트와 별개로, **데이터·코드·운영 지식의 이식성**이 락인의 본질이다.
| 도구 | 데이터 락인 | 코드 락인 |
| --- | --- | --- |
| Supabase | 낮음 (Postgres) | 낮음 (SDK는 얇음) |
| Firebase | 높음 (Firestore export 복잡) | 높음 (Security Rules·트리거·Hosting) |
| Pocketbase | 매우 낮음 (SQLite 파일) | 낮음 |
| Appwrite | 중 (도큐먼트 export) | 중 |
| Convex | 중 (함수 + 인덱스 묶음) | 중~높음 |
| InstantDB | 중 (트리플 스토어) | 중 |
Supabase가 가장 낮은 이유
Supabase의 진정한 강점은 **"데이터는 그냥 Postgres"**라는 점이다. `pg_dump`로 옮기면 다른 Postgres에 그대로 들어간다. SDK도 PostgREST·GoTrue 같은 표준 위에 있어, 갈아타기 비용이 낮다.
Firebase가 가장 높은 이유
Firestore export → 다른 DB는 자동이 아니다. 모델이 다르고(도큐먼트 → 관계형 매핑 필요), Security Rules·트리거·Functions는 Google Cloud에 박혀 있다. 락인이 본질적이다.
8장 · 가격·스케일 — "에지 케이스"가 결정한다
가격 비교는 단순한 표가 아니다. **"무엇이 청구 단위인가"**가 핵심이다.
| 도구 | 청구 단위 |
| --- | --- |
| Supabase | DB 크기 + Egress + 활성 사용자 + 함수 호출 |
| Firebase | 도큐먼트 read/write/delete + 저장 + Egress + 함수 호출 |
| Pocketbase | 셀프호스트(VPS 비용) — 호스티드 없음 |
| Appwrite | Project + 함수 실행 + 스토리지 (Cloud) / 셀프호스트는 무료 |
| Convex | 함수 호출 + 스토리지 + WebSocket 시간 |
| InstantDB | 활성 사용자 + 트랜잭션 |
가격 함정
가장 흔한 실수는 **"무료 티어가 후하다"**만 보고 결정하는 것.
- **Firebase**는 "도큐먼트 read"가 청구 단위이므로, "한 페이지에서 50개 도큐먼트를 보여주는 앱"은 사용자 1명당 페이지뷰마다 50회 read. 트래픽이 늘면 곡선이 가파르다.
- **Supabase**는 Postgres + Egress 중심이라, 큰 페이로드(이미지·JSON 덩어리)가 Egress를 폭증시킨다.
- **Convex**는 함수 호출 + WebSocket 연결 시간. 항상 떠 있는 모바일 앱이 많아지면 가파르다.
1인 SaaS 시나리오 (월 1000 사용자)
대략 (정확한 숫자는 항상 최신 페이지 확인 필수).
- Supabase Pro — **$25/월 시작** + 사용량 + Egress.
- Firebase — **무료 티어 + Spark 초과 시 Blaze 사용량**. read 회수 의존.
- Pocketbase — **VPS $5~$10/월**. 그 외 비용 사실상 0.
- Appwrite Cloud — **무료 + 사용량**. 셀프호스트면 0.
- Convex — **$25/월 시작** + 사용량.
- InstantDB — **무료 + 사용량 기반**.
이 단계에서는 **Pocketbase·Appwrite 셀프호스트가 압도적으로 싸다**. 다만 운영 부담은 본인 몫.
시드 SaaS 시나리오 (월 5만 사용자)
- 셀프호스트 1인 운영은 슬슬 부담된다. VPS 모니터링·백업·업그레이드.
- Supabase Pro / Convex / Firebase Blaze가 자연스러운 선택.
- Firebase는 read 회수 모델링이 잘 안 되면 가파르게 비싸진다.
- Supabase는 일관된 Postgres 운영 + Egress 관리가 핵심.
9장 · 7축 비교 — 한눈에
9.1 핵심 매트릭스
| 축 | Supabase | Firebase | Pocketbase | Appwrite | Convex | InstantDB |
| --- | --- | --- | --- | --- | --- | --- |
| 데이터 모델 | SQL(Postgres) | 도큐먼트 | SQL(SQLite) | 도큐먼트 | 도큐먼트 | 트리플/그래프 |
| 실시간 | RLS + LR | snapshot | SSE | WS | reactive | 그래프 푸시 |
| 인증 | RLS | Rules | API rules | Teams | 어댑터 | Magic + Rules |
| 벡터·AI | pgvector 1급 | Genkit/Vertex | 외부 | 베타 | 빌트인 | 베타 |
| 셀프호스트 | O (Docker/K8s) | X | O (바이너리) | O (Docker) | O (OSS) | 베타 |
| 락인 | 매우 낮음 | 매우 높음 | 매우 낮음 | 낮음 | 중 | 중 |
| 1인 비용 | 중 | 낮음(무료) | 매우 낮음 | 낮음 | 중 | 낮음 |
9.2 시나리오별 추천
**AI 앱 (RAG·임베딩·LLM 흐름)**
1. **Supabase** — pgvector + Edge Functions, 가장 매끄러움.
2. **Convex** — 함수 + 벡터 빌트인, TS-first.
3. **Firebase + Genkit** — Google 진영을 이미 쓰는 경우.
**B2B SaaS (관계 데이터·복잡 쿼리)**
1. **Supabase** — Postgres가 1순위.
2. PlanetScale·Neon + Clerk + 자체 백엔드 — 빌드-유어-온 진영.
3. **Convex** — TS-first 팀이고 reactive를 원할 때.
**모바일 퍼스트 (오프라인·푸시·푸시 알림)**
1. **Firebase** — 여전히 사실상 표준. 오프라인 동기화 성숙.
2. **Supabase** — 모바일 SDK 진화 중, 단 오프라인은 아직 Firebase 수준 아님.
3. **InstantDB** — 실시간 그래프가 모바일 UX와 잘 맞음.
**1인 SaaS·인디·사이드 프로젝트**
1. **Pocketbase** — 단순함이 압도적인 가치.
2. **Supabase** — 무료 티어 + Postgres 운영 지식 재사용.
3. **InstantDB** — 작은 팀 + 실시간 친화.
**셀프호스트 우선 (규제·보안·비용)**
1. **Appwrite** — Docker 한 줄, 풀스택.
2. **Supabase 셀프호스트** — 강력하나 운영 부담.
3. **Pocketbase** — 가장 단순.
10장 · 빌드-유어-온 — BaaS를 거부하는 길
마지막 카드. 어떤 팀은 BaaS를 의식적으로 거부하고, 각 책임을 별도 서비스로 조립한다.
Auth Clerk / WorkOS / Auth.js
DB PlanetScale / Neon / Supabase Postgres (만)
Realtime Liveblocks / Ably / 자체 WS
Storage S3 / R2 / UploadThing
Functions Inngest / Cloudflare Workers
Email Resend
Vector Pinecone / Turbopuffer / pgvector
**장점**
- 각 책임의 최고 도구를 골라 쓴다.
- 한 서비스의 사고가 전체를 멈추지 않는다.
- 가격 곡선을 세밀히 제어 가능.
**약점**
- 통합 비용. 인증·DB·실시간 사이를 코드로 직접 짜야 함.
- 장애 시 디버깅 표면이 넓다.
- 신규 팀원 온보딩에 도구 N개를 가르쳐야.
**언제 좋은가**
- Series A 이후 팀, 10명 이상 엔지니어.
- 특정 도구의 한계를 분명히 본 후.
- 규제·SLA·온프레미스 요구가 강할 때.
11장 · 최근 1년 동안 무엇이 바뀌었나
각 도구의 2025~2026년 핵심 변경.
Supabase
- **DataLab** — 노트북 스타일의 SQL 분석 도구. Postgres + AI 어시스턴트로 데이터 탐색.
- **SQL Editor v2** — 더 빠르고 AI 자동완성이 강화된 쿼리 에디터.
- **Branching** — DB 브랜치 기능이 GA. PR마다 isolated DB.
- pgvector + HNSW 인덱스 안정화.
- Edge Functions 콜드 스타트 개선.
Firebase
- **App Hosting GA** — Next.js·Angular 호스팅이 1급으로.
- **Genkit GA** — AI 흐름 프레임워크 정식 출시.
- **Data Connect** — 관계형 데이터(Postgres) 통합이 빌트인으로.
- Firestore 가격 모델 일부 조정.
Pocketbase
- v0.22 시리즈 안정화.
- Realtime SSE 성능 개선.
- 외부 OAuth 프로바이더 확대.
- Go API 깔끔한 정리.
Appwrite
- v1.6 → v1.7 시리즈로 Functions·Realtime·Sites 안정화.
- Appwrite Cloud GA.
- Sites — 정적 사이트 호스팅이 빌트인으로.
Convex
- 셀프호스트 OSS 출시.
- 벡터 검색 정식 GA.
- HTTP Actions, Crons, Scheduling 안정화.
- Next.js·Tanstack Start 통합.
InstantDB
- 베타 → 정식 GA (단계적).
- 권한 룰 시스템 강화.
- 셀프호스트 베타 옵션.
- Clerk·Auth.js 통합.
에필로그 — "1인이 SaaS를 만든다"는 시대의 도구 선택
BaaS 선택은 **"무엇을 청구 단위로 받아들일 것인가"의 결정**이기도 하다. 1년 후의 청구서를 미리 머릿속에서 그려보는 게 가격표 외우는 것보다 중요하다.
2026년 5월의 결론을 정리한다.
- **Postgres에 비빌 수 있다면 Supabase** — 락인 낮고, 운영 지식이 일반 Postgres와 같다.
- **모바일·오프라인이 핵심이면 Firebase** — 락인은 비싸지만 성숙도가 압도.
- **1인·인디·작은 팀은 Pocketbase가 정답일 때가 많다** — 단순함이 곧 속도.
- **셀프호스트 풀스택은 Appwrite** — Docker 친화, 자기 인프라에서 결정.
- **TS-first reactive 백엔드는 Convex** — 함수 + 구독 모델이 익숙해지면 매력적.
- **실시간 그래프 + 작은 코드는 InstantDB** — 빠르게 성장 중.
- **본인이 무엇을 짓는지 분명하면 빌드-유어-온** — 단, 통합 비용은 진짜로 든다.
결정 체크리스트
- 데이터 모델은 관계형인가 도큐먼트인가? — Yes 관계형이면 Supabase·Pocketbase, 도큐먼트면 Firebase·Appwrite·Convex·InstantDB.
- 실시간이 본질인가? — Yes면 Convex·InstantDB·Supabase·Firestore.
- 모바일 + 오프라인 동기화? — Yes면 Firebase 1순위.
- AI·벡터·RAG가 핵심? — Supabase·Convex.
- 셀프호스트 필수? — Pocketbase·Appwrite·Supabase·Convex.
- 락인 최소화? — Supabase·Pocketbase.
- 가장 빠르게 MVP? — Firebase·Pocketbase·Convex.
안티 패턴
1. **무료 티어만 보고 결정** — 1년 뒤 청구서가 곡선이다. 청구 단위를 보라.
2. **"트렌드"만 보고 갈아타기** — Convex가 멋있어 보여서 옮겼는데 RLS-style 권한이 그리워지는 경우 많음.
3. **셀프호스트를 1인 운영하는 SLA 계산 없이** — 백업·모니터·업그레이드 시간은 본인 시간.
4. **Firebase에서 30만 도큐먼트 read/일을 무료 티어 안에서 한다고 가정** — 청구 모델을 먼저 모델링하라.
5. **BaaS A와 B를 동시에 쓰기** — "Auth는 Firebase, DB는 Supabase". 통합 비용으로 한 시즌 날릴 수 있음.
6. **벤더 락인 0을 추구하다가 아무것도 못 만듦** — 락인은 트레이드오프, 0은 불가능.
7. **AI 앱인데 벡터 빌트인 없는 도구 선택** — 그러면 BaaS의 가치 절반이 빠진다.
다음 글 예고
다음 글 후보: **Supabase Branching + Drizzle ORM 1년 회고 — PR마다 isolated DB가 실제로 어떤지**, **Firebase Genkit vs Vercel AI SDK 실전 비교 — RAG 흐름 동일 시나리오**, **Pocketbase 단일 바이너리로 6개월 SaaS 운영한 솔직한 후기**, **Convex 셀프호스트 OSS — 호스티드와 실제로 무엇이 다른가**.
> "BaaS는 백엔드를 짜는 일이 아니다. 백엔드를 짜지 않는 결정을 짜는 일이다."
— BaaS 2026, 끝.
참고 / References
- [Supabase — 공식](https://supabase.com/)
- [Supabase Docs](https://supabase.com/docs)
- [Supabase GitHub](https://github.com/supabase/supabase)
- [Supabase Branching](https://supabase.com/docs/guides/deployment/branching)
- [Supabase pgvector](https://supabase.com/docs/guides/ai/vector-columns)
- [Firebase — 공식](https://firebase.google.com/)
- [Firebase App Hosting](https://firebase.google.com/docs/app-hosting)
- [Firebase Genkit](https://firebase.google.com/docs/genkit)
- [Firebase Data Connect](https://firebase.google.com/docs/data-connect)
- [Firestore Security Rules](https://firebase.google.com/docs/firestore/security/get-started)
- [Pocketbase — 공식](https://pocketbase.io/)
- [Pocketbase GitHub](https://github.com/pocketbase/pocketbase)
- [Pocketbase Docs](https://pocketbase.io/docs/)
- [Appwrite — 공식](https://appwrite.io/)
- [Appwrite GitHub](https://github.com/appwrite/appwrite)
- [Appwrite Cloud](https://cloud.appwrite.io/)
- [Convex — 공식](https://www.convex.dev/)
- [Convex Docs](https://docs.convex.dev/)
- [Convex GitHub](https://github.com/get-convex/convex-backend)
- [Convex Self-Hosting](https://docs.convex.dev/self-hosting)
- [InstantDB — 공식](https://www.instantdb.com/)
- [InstantDB Docs](https://www.instantdb.com/docs)
- [InstantDB GitHub](https://github.com/instantdb/instant)
- [Clerk — Auth](https://clerk.com/)
- [PlanetScale](https://planetscale.com/)
- [Neon — Serverless Postgres](https://neon.tech/)
- [Inngest — Background Jobs](https://www.inngest.com/)
- [Liveblocks — Realtime](https://liveblocks.io/)
- [Vercel AI SDK](https://sdk.vercel.ai/)
현재 단락 (1/357)
2026년 5월. 새 프로젝트를 시작하는 첫 회의 풍경은 2020년과 묘하게 비슷하면서도 다르다.