✍️ 필사 모드: 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"라고 부르지만, 실은 결이 다르다.

이 글의 핵심 비교는 위 표의 굵게 표시된 도구들 — 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다. 스키마가 없고, 클라이언트에서 직접 읽고 쓰는 모델이 표준이다.

import { getFirestore, collection, addDoc } from 'firebase/firestore'

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
import { query } from './_generated/server'

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(트리플 스토어) 모델 위에 그래프 쿼리를 얹은 구조다.

import { useQuery } from '@instantdb/react'

// 'todos를 가져오는데, 그 안의 owner도 함께'
const { data } = useQuery({ todos: { owner: {} } })

스키마는 선택적 — 처음에는 스키마 없이 시작하고, 점진적으로 강화할 수 있다.

3장 · 실시간 — "푸시"가 기본인가 옵션인가

2026년의 BaaS에서 실시간은 선택이 아니라 기본이다. 다만 구현 모델이 다르다.

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가 얼마나 귀찮은지.

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 기능이다.

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"라면 핵심

셀프호스트는 단순한 비용 절감이 아니라, 벤더 락인을 끊는 보험이다.

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가 가장 낮은 이유

Supabase의 진정한 강점은 **"데이터는 그냥 Postgres"**라는 점이다. pg_dump로 옮기면 다른 Postgres에 그대로 들어간다. SDK도 PostgREST·GoTrue 같은 표준 위에 있어, 갈아타기 비용이 낮다.

Firebase가 가장 높은 이유

Firestore export → 다른 DB는 자동이 아니다. 모델이 다르고(도큐먼트 → 관계형 매핑 필요), Security Rules·트리거·Functions는 Google Cloud에 박혀 있다. 락인이 본질적이다.

8장 · 가격·스케일 — "에지 케이스"가 결정한다

가격 비교는 단순한 표가 아니다. **"무엇이 청구 단위인가"**가 핵심이다.

가격 함정

가장 흔한 실수는 **"무료 티어가 후하다"**만 보고 결정하는 것.

• 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 핵심 매트릭스

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 — 공식
• Supabase Docs
• Supabase GitHub
• Supabase Branching
• Supabase pgvector
• Firebase — 공식
• Firebase App Hosting
• Firebase Genkit
• Firebase Data Connect
• Firestore Security Rules
• Pocketbase — 공식
• Pocketbase GitHub
• Pocketbase Docs
• Appwrite — 공식
• Appwrite GitHub
• Appwrite Cloud
• Convex — 공식
• Convex Docs
• Convex GitHub
• Convex Self-Hosting
• InstantDB — 공식
• InstantDB Docs
• InstantDB GitHub
• Clerk — Auth
• PlanetScale
• Neon — Serverless Postgres
• Inngest — Background Jobs
• Liveblocks — Realtime
• Vercel AI SDK