템플릿 고르기

두 템플릿 한눈에 보기

flowchart LR
  subgraph NEON["prokit-next-neon"]
    direction LR
    N1["로컬 개발<br/>compose Postgres<br/>localhost:5432"] -->|병합 전| N2["Neon 개발 브랜치<br/>작업마다 생성<br/>db:migrate"]
    N2 -->|병합 · 배포| N3["Neon 운영 브랜치"]
  end
  subgraph SUPA["prokit-next-supabase"]
    direction LR
    S1["로컬 개발<br/>Supabase 스택 DB만<br/>127.0.0.1:54322"] -->|병합 전| S2["Supabase 스테이징<br/>db:migrate + advisors"]
    S2 -->|병합 · 배포| S3["Supabase 운영<br/>앱은 pooler 6543"]
  end

무엇으로 고르나요

• PR(변경 제안)마다 DB 브랜치(테스트용 복사본)를 만들어 확인하고 싶으면 → neon

• 이미 Supabase를 쓰고 있으면 → supabase

• 화면만 만들면(DB 없이) → 묻지 않고 neon으로 만들어요. 나중에 실제 서비스로 바꿀 때 로컬 DB를 더해요(빠른 시작: 화면만 만들기).

요청에 DB 종류가 없으면 에이전트가 추측하지 않고 이 비교표로 차이를 설명한 뒤 물어요.

자세히

• 같은 앱 구조: 두 템플릿 모두 Next.js + oRPC + Better Auth + Drizzle 모노레포에 설치돼요(앱 구조). 둘 다 일반 Postgres 드라이버(pg)를 써서 로컬 DB와 원격 DB에 같은 코드로 붙어요.

• neon이 --db-setup neon을 쓰지 않는 이유: --db-setup neon은 Neon 전용 HTTP 드라이버를 만들어 로컬 Postgres에 붙지 않아요. 그래서 --db-setup docker로 만들어요.

• supabase의 RLS: 앱은 Supabase를 Postgres로만 쓰고, public의 모든 테이블에 정책 없는 RLS를 켜서 Data API로 들어오는 접근(anon, authenticated)을 막아요. 앱은 테이블 소유자 역할로 접속하므로 영향이 없고, 사용자별 데이터 격리는 RLS가 아니라 API의 소유권 검사가 해요. 첫 마이그레이션에 enable_rls_auth를 더하고 supabase db advisors로 확인해요.

• 검증 기록: neon(새 탭) · supabase(새 탭)

관련 문서

• 템플릿이 더하는 것

• 준비물

• 빠른 시작: 서비스 만들기

• 공식 스킬과 연결